How MCP Becomes a Deep Extension Point for Agent Platforms: Architecture Design and Practice

Introduction: From Local Tools to Platform-Level Extensions

With the proliferation of autonomous Agent solutions like OpenAI Codex, more and more developers are realizing that a fully managed, autonomously running Agent has tremendous potential. However, existing solutions often fall short of expectations in terms of applicability and capability. Agent platformization offers a more engineering-oriented possibility, and MCP (Model Context Protocol) has gained renewed vitality in this process.

MCP is an open standard protocol proposed by Anthropic in late 2024, designed to address the fragmentation of integration between AI models and external tools/data sources. Before MCP, every AI application needed to write separate integration code for each tool, creating a massive "N×M" integration matrix—where N AI applications each connect to M tools, with every combination requiring independent maintenance. MCP simplifies this to an "N+M" plugin-style architecture by defining a unified Client-Server communication specification: tool developers only need to implement an MCP Server once, and all MCP-compatible Agent platforms can directly connect. This design philosophy mirrors how the USB standard unified peripheral connections.

This article is the third installment in the Agent Platform series, with the core topic being: How to use MCP as a platform extension point to achieve capabilities like permission integration and UI extensions that skill-based approaches struggle to replicate.

Differences Between MCP in Local Agents vs. Platform Agents

Local Agents: The Natural Advantage of stdio

For local Agents, stdio-type MCP Servers are the most natural choice. stdio (standard input/output) is the most fundamental inter-process communication mechanism provided by the operating system—the parent process sends requests by writing to the child process's standard input (stdin) and receives responses by reading from the child process's standard output (stdout). This approach requires no network connection, and communication latency is only affected by CPU scheduling, typically at the microsecond level. MCP Servers run as processes in the same environment as the Agent Core, offering the following advantages:

• Near-zero latency: Inter-process communication with no network overhead
• Direct local file access: MCP Servers can directly read the local file system
• Simple management: No additional service deployment required

In this mode, when you say "help me process a code file" in an Agent conversation, the MCP Server can directly read that file, bypassing the upload restrictions of remote scenarios. Most MCP Servers on the market also started with the stdio type.

Platform Agents: New Challenges from Multi-Tenancy

When MCP needs to run in a multi-tenant, multi-user general-purpose Agent platform, things become entirely different. Multi-tenancy is a core architectural pattern for SaaS platforms, where the same software infrastructure simultaneously serves multiple independent users or organizations. In the Agent platform context, multi-tenancy introduces core challenges around resource isolation and permission management—each user's tool invocation credentials and data access scope must be strictly isolated without interference. This creates fundamental architectural obstacles for the stdio mode that originally ran locally:

• Permission control: stdio-type MCP Servers typically require users to complete authentication via command-line operations locally, but platform users may have no command-line experience whatsoever
• Login complexity: Each Agent needs to complete a separate login, which is extremely tedious
• Transport protocol selection: In platform scenarios, HTTP Streamable is more friendly than stdio, supporting remote access and unified management

HTTP Streamable is another major transport protocol supported by MCP, based on HTTP combined with Server-Sent Events (SSE) for streaming responses. SSE is a unidirectional server push technology that allows the server to continuously send data to the client over a persistent HTTP connection, making it ideal for scenarios where AI models generate responses token by token. Compared to WebSocket's bidirectional full-duplex communication, SSE is simpler to implement and naturally penetrates most enterprise firewalls and reverse proxies, making it the preferred transport layer for platform-level MCP deployments.

Therefore, for Agent platforms, migrating from stdio to HTTP Streamable transport protocol is an inevitable choice.

Architectural Practices for Platform-MCP Integration

Core Pipeline Design

In Agent platform architecture, MCP integration has two key extensible pipelines:

Pipeline 1: Configuration Rewriting During Delivery

MCP configurations from the management plane can be rewritten and supplemented when delivered to Agents. This means the platform can inject additional contextual information for Agents, making tool invocations more intelligent. For example, the platform can automatically inject the current user's tenant ID, permission scope, or environment identifier into the configuration, enabling MCP Servers to make correct access control decisions without additional identity queries.

Pipeline 2: MCP Proxy Layer

Calls from Agent Core to external MCP Servers are no longer direct connections but first pass through the platform's internal MCP Proxy (a network proxy, not an AI Agent). The MCP Proxy is essentially a reverse proxy service that borrows mature design patterns from API Gateways, decoupling cross-cutting concerns like authentication, rate limiting, and auditing from business logic for unified handling. This proxy layer can accomplish:

• Automatic credential injection: Dynamically appending OAuth Tokens or API Keys managed centrally by the platform during request forwarding
• Automatic token refresh: Monitoring credential validity and silently completing refresh before expiration, completely transparent to Agent Core
• Security auditing and access control: Recording complete logs of all tool invocations, supporting compliance reviews and anomaly detection

This makes usage both secure and simple for users, who don't need to worry about underlying authentication details.

Tool Invocation Linking Agents and Humans

This is the most compelling design concept for MCP in platform scenarios, and represents the concrete implementation of the Human-in-the-Loop (HITL) collaboration paradigm in Agent engineering: linking Agents and humans together for collaborative work through tool invocations and their return results.

HITL is an important paradigm in AI system design, referring to introducing human judgment and intervention at critical nodes in automated workflows. This concept originates from cybernetics and early expert system design, and has been given new engineering significance in the era of large language models—especially in scenarios involving high-risk operations, subjective judgment requirements, or legal compliance demands, where HITL becomes a key mechanism for ensuring AI system reliability. MCP's tool invocation mechanism naturally provides standardized "pause points" for HITL: after an Agent invokes a tool and waits for results, the platform hands control to humans during this interval, and once humans finish processing, the results are injected back into the Agent's context.

Using a Code Review scenario as an example, the complete collaboration flow is:

1. The Agent executes the Code Review workflow in a conversation, calling the create_review MCP tool
2. The platform detects the tool invocation result and automatically displays the Review interface in the customized UI area
3. Humans complete the Review operation in the embedded UI and click Submit
4. The platform automatically submits the result back to the Agent as a prompt, and the conversation continues

The entire process never leaves the Agent platform, achieving truly seamless collaboration. Compared to the traditional skill mode—where the Agent gives you a link, you open a new page to handle things, then come back to tell the Agent—the experience improvement is a quantum leap.

Core Value of MCP as a Product Extension Point

Why Not Skills?

In Agent architecture, Skills typically refer to predefined, encapsulated functional modules that Agents invoke to complete specific tasks, with interaction results returned to the conversation context as plain text. This mode is simple and efficient, and combined with the Agent's programming capabilities, can indeed solve most scenarios. However, Skills' text-return mechanism inherently lacks deep integration with the platform's UI layer—it can tell the Agent "the task is complete" but cannot directly render an interactive operation panel on the platform interface. MCP, through its standardized tool invocation protocol, allows tools to return structured data that triggers UI rendering logic at the platform layer, achieving the leap from "text interaction" to "interface collaboration." Specifically, MCP demonstrates irreplaceable advantages in the following areas:

• UI extension capability: MCP tool invocation results can trigger platform-level UI rendering, which is difficult to achieve with pure-text skills
• Permission integration: The MCP protocol natively supports standardized authentication and authorization workflows
• Cross-Agent Core portability: Regardless of whether the underlying runtime is Codex, Claude Code, or a custom-built runtime, as long as it connects to a unified MCP Client-Server architecture, configurations can be migrated

The Essence of the Collaboration Model

The core value of MCP in platforms can be summarized as: Agents create "collaboration nodes" through tool invocations