---

theme: arknights

Models can write their own code, so why can't your Agent connect to a calendar? — A thorough explanation of MCP, the AI world's 'USB-C'

This article starts from an integration scene you've probably experienced—the kind that makes you want to smash your keyboard at midnight—breaks it down into 5 progressive questions, and solves each one with facts and the spec.

---

Look at this scene

You built a super-powerful Agent: it can write code, reason, and break complex tasks into steps. Now you want it to "actually do some work"—read the company database, check your calendar, send a Slack message, call an internal API.

So you start connecting. For every external system you integrate, you have to write a whole set of things yourself:

• Authentication: OAuth, API Keys, Token refresh;
• Data formats: the other side returns JSON, XML, or weird CSV;
• Error retries, rate limiting, polling: all the dirty work of the networked world;
• Stuffing the results back into the model's prompt.

After connecting 3 tools, you've already written a pile of glue code. When you want to connect the 7th, you stare at the screen and think: "Models can write their own operating systems, so why am I still hand-soldering interfaces?"

What stings even more: tomorrow you want to swap the underlying model from Claude to Gemini, and you find this whole set of integration code has to be rewritten entirely—because each vendor's function-calling format and context conventions are different.

If your current guess is "the model isn't strong enough," "the prompt isn't written well," or "just tweak the prompt a bit more"—this article is here to overturn those three intuitions. We'll break it apart and solve them one by one.

Figure 1 · Integration Explosion: Without a standard protocol, N Agents × M external systems = N×M sets of bespoke adapter code; swap the model or framework, and you rewrite it all again—the bottleneck isn't the model's intelligence, it's the "connection" itself.

---

Question 1: Is the model not good enough?

When an Agent "understands everything but can't connect to any external system," the first suspect shouldn't be model capability—it's the lack of a standard interface between it and the outside world.

In 2025–2026, the static capability of frontier models is no longer the main cause of production failures; in post-mortems by organizations like METR, roughly 65% of enterprise AI failures are attributable to "context drift / memory loss." And "can't connect to external systems" is another equally common sticking point—it has nothing to do with model intelligence, it's purely integration cost.

This is like a CPU with monstrous computing power, but every peripheral requires soldering a proprietary cable: the problem isn't the chip, it's the interface standard. No matter how strong your carefully trained model is, as long as every pair between it and external databases, calendars, and APIs requires hand-writing a set of glue code, it will forever be an "isolated island brain." So, first cross out the "model isn't good enough" guess—your Agent isn't dumb, it just hasn't been plugged into a "USB."

---

Question 2: What exactly is MCP?

What MCP (Model Context Protocol) aims to solve is standardizing the connection of "AI application ↔ external systems (data / tools / workflows)," letting developers go from "hand-solder every pair" to "build once, integrate everywhere."

MCP was formally proposed by Anthropic on November 25, 2024, as an open protocol. The official analogy is very direct:

MCP is like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.

Its architecture is the classic client–host–server three-layer model (from the official spec):

Figure 2 · Three-Role Architecture (official spec): The Host is the AI application that carries the model; each Host creates multiple Clients, each Client maintains a 1:1 stateful session with one Server; the Server is a program that exposes capabilities, which can be local or remote.

• Host: The AI application that carries the language model, such as Claude Desktop, various IDE assistants, Agent runtimes. It is responsible for creating and managing multiple Clients, handling permissions and lifecycle control, and aggregating context.
• Client: The connector inside the Host, one Client per Server, maintaining an independent stateful session and bidirectionally routing protocol messages.
• Server: A program that exposes "tools / resources / prompts" via MCP primitives, which can be a local subprocess or a remote service.

Note a key design principle (spec's own words): Servers should not be able to read the whole conversation, nor "see into" other Servers; each Server connection is isolated, and the complete conversation history always stays in the Host's hands. This is precisely the "USB mindset"—peripherals are plug-and-play, but mutually invisible, with the security boundary uniformly controlled by the host.

---

Question 3: How does it slash N×M sets of code down to O(N+M)?

The reason MCP can eliminate the pain of "hand-soldering interfaces" relies on three mechanistic designs, not some magical model. They each kill one root cause of the "connection explosion."

Mechanism One: Unified interface, eliminating bespoke integration

Without a standard, N Agents × M external systems = N×M sets of bespoke adapter code. The same applies between Agents: N Agents collaborating originally required N×(N−1) adapters; after MCP-ification, each Agent only needs to implement the protocol once, reducing complexity to O(N) (public analysis from the MCP technical community).

This is like before USB existed, printers, mice, and hard drives each used their own interfaces; after USB unified them, any device just needs to make "one USB port" to plug into any computer. MCP compresses "connection" from O(N×M) down to O(N+M) plug-and-play.

Mechanism Two: Capability Discovery (Capability Negotiation), turning "hard-coded" into "plug-and-play"

MCP is a stateful, per-session protocol. During the initialization phase, the Server "self-reports capabilities"—declaring what tools, resources, and prompts it has; the Client automatically completes capability negotiation at session start, and only then enters normal invocation.

This step is the essence: tools are no longer hard-coded at compile time in the code, but discovered at runtime. You add a new Server, the Host automatically "sees" its capabilities at startup, and the model can use them immediately—without changing a single line of integration code. This exactly explains why that earlier scene of "wanting to smash the keyboard when connecting the 7th tool" becomes "just add a config" under MCP.

Mechanism Three: Transport and protocol separation (Transport-agnostic)

MCP's data layer is based on JSON-RPC 2.0 (defining message structure and semantics, lifecycle management, three primitives); the transport layer is independent, providing two mechanisms: stdio (local subprocess, zero network overhead) and Streamable HTTP (remote service, replacing the old HTTP+SSE as the recommended remote path since the 2025-11-25 revision, supporting OAuth authentication).

The same set of JSON-RPC message formats can run both between local processes and over cloud HTTP. Developers only write "protocol logic" and don't touch network details—this is also why it can simultaneously cover "local filesystem Servers" and "remote SaaS API Servers."

Figure 3 · Handshake and Invocation Flow: Initialization → Capability Negotiation (Server self-reports tools/resources/prompts) → Active Communication (Client proxies calls during model inference) → Session Management (stateful, cancellable, with progress notifications).

---

Question 4: What exactly is the relationship between MCP and Tool Calling?

Many people think "MCP = Tool Calling / function calling"—this is the single most important misconception to clarify in this entire article. The two are not on the same layer.

The official spec's definition of Tools is very precise:

Tools are model-invoked functions... analogous to function calling, but over a standard transport.

Let's break it down:

• Tool Calling (function calling) is a model-side capability: the model decides "which function to call, how to fill in the parameters." This is a characteristic of the LLM itself.
• MCP is a system-side protocol: it defines "where this function runs, how to connect, how it is discovered, how permissions are managed." It lifts "function calling" from "hard-coded in the application" to "plug-and-play over standard transport."

A deeper principle is captured in one sentence from the spec: what an MCP Server exposes is far more than just Tools—there are also Resources (read-only context data, such as file contents, database rows, API responses, which the Host decides whether to attach to the model) and Prompts (server-curated prompt templates). The spec particularly emphasizes: conflating Tools / Resources / Prompts will make Agent behavior worse, because the model cannot reason about "permissions and side effects." —This exactly echoes what the previous issue said about "every extra category of noise in the context makes it harder for the model to read."

So, the correct layering is:

Figure 4 · MCP vs Tool Calling Layering: Tool Calling is at the "model decision layer" (whether to call, how to fill parameters); MCP is at the "system transport and discovery layer" (where it runs, how to connect, who can see it). MCP additionally manages Resources / Prompts / permission isolation—it is much broader than "function calling."

A counter-intuitive anchor point along the way: precisely because MCP standardizes the exposure of "capabilities," the more Servers hung on a Host, the more tools the model has to choose from—the previous issue cited a community observation: when tools exceed 20, the accuracy of picking the right tool drops noticeably. MCP cures "connectability," but "how to choose and how to manage context after connecting"—that's the job of context engineering.

---

Question 5: Why is this even more important in 2026?

Because two trends of 2026 happen to push MCP from a "geek toy" to an "ecosystem must-answer question."

[The ecosystem is already a de facto standard]

As of 2026, the list of interoperating via MCP is already long: Claude (Desktop and API), OpenAI (Agents SDK and ChatGPT Desktop), Google (Gemini Code Assist), Microsoft (Copilot Studio), and mainstream Agent frameworks LangGraph, CrewAI, AWS Strands, Amazon Bedrock AgentCore Gateway have all connected; the official MCP Registry (public Server registry) went live in preview in September 2025. Meanwhile, the Juejin hot list has been dominated for consecutive weeks by "Multi-Agent collaboration / MCP protocol / Spec-First programming workflows"—this is not a coincidence, it's the same wave of "standardizing integration."

[It is an upstream-downstream sibling with 'Context Engineering']

MCP itself draws a very clear boundary of responsibility. The official spec's own words:

MCP focuses solely on the protocol for context exchange—it does not dictate how AI applications use LLMs or manage the provided context.

This sentence is the key to understanding the whole thing: MCP is responsible for "bringing external capabilities and data in, pulling them in" (transport + discovery), but "after pulling them in, which ones should stay, be compressed, be isolated"—that's the set of principles covered in the previous issue on Context Engineering. One manages "connectability," the other manages "usability." Only when the two are pieced together do you get the complete foundation for an Agent to move from Demo to production.

[It incidentally solves Agents "speaking different languages" among themselves]

In the multi-agent era, just unifying "Agent↔Tool" isn't enough. Looking at it in layers makes it clear: A2A (Agent-to-Agent, released by Google in 2025) manages "how multiple Agents collaborate," MCP manages "how an Agent calls tools / fetches data"—each has its own job. Thus, the original N×(N−1) adapters between N Agents drop to O(N) after MCP-ification; layer A2A on top, and the Tower of Babel for collaboration is also dismantled. Microsoft merging AutoGen into the Microsoft Agent Framework in 2026 is also a footnote to this main thread of "framework convergence, protocol unification."

Figure 5 · MCP's Position in the Agent Tech Stack: Lower layer STDIO/Streamable HTTP transport → Middle layer MCP (Tools/Resources/Prompts + capability discovery + permission isolation) → Upper layer collaborates with A2A (inter-Agent collaboration), Context Engineering (governance after data comes in), and Harness (runtime encapsulation). MCP does not dictate how the upper layer uses it, but it is the common "socket" for everyone.

---

From "solder a cable for every tool" to "one USB-C for everything"

Writing this far, three things to take away:

1. The Law of Bottleneck Shift (sequel). Last issue we said "what limits you is no longer model intelligence, but information architecture"; this issue adds a line: when both the model and information architecture are solved, what limits you will be the 'connection standard'—whoever can plug-and-play connect the outside world in is the one who can truly get work done.
2. MCP ≠ Tool Calling. The former is the system-side "transport + discovery + isolation" layer, the latter is the model-side "decision" layer. Treating function calling as the entirety of MCP is like treating USB as "the computer can do arithmetic"—you've reversed the layers.
3. MCP cures 'connectability,' not 'usability.' It solves the integration explosion, but "hanging too many tools makes selection inaccurate" and "how to govern the data pulled in" still rely on context engineering. The two brothers are indispensable: without MCP, data is an isolated island; without context engineering, data coming in is also a disaster.

Returning to Harrison Chase's quote from last issue, this issue can add a line:

"Agents fail because they don't have the right context; they succeed because they have the right context."

And what MCP does is first reliably, standardly, plug-and-play transport the 'right context' in to take a look—as for how to manage it after it's transported in, that's last issue's classroom.

---

Interaction Time

Back to the opening scene: when you wanted to smash the keyboard connecting the 7th tool, was it because the model wasn't strong enough, or because "every external system requires hand-soldering a bespoke adapter"?

How many sets of bespoke integrations have you hand-rolled? Are you still soldering cables, or have you already adopted MCP to make tools 'plug-and-play'? Welcome to chat in the comments about the integration pitfalls you've stepped into—you can also talk about: are you still stuck at "hand-writing function calling," or have you already standardized this whole set with Host + Server?

If this was useful to you, give it a like or bookmark, so more colleagues still "hand-soldering interfaces" can see: the model is already strong enough, what's blocking you isn't intelligence, it's that not-yet-unified "USB-C."

---

Reference Sources

• Model Context Protocol official site and architecture documentation (modelcontextprotocol.io): MCP = "USB-C port for AI applications"; client–host–server architecture, Host manages multiple Clients, each Client maintains a 1:1 stateful session with 1 Server; Servers cannot read the whole conversation, mutually isolated; data layer JSON-RPC 2.0, transport layer stdio / Streamable HTTP (Streamable HTTP replaces HTTP+SSE since the 2025-11-25 revision); "MCP focuses solely on the protocol for context exchange—it does not dictate how AI applications use LLMs…"
• MCP specification architecture page (specification/2024-11-05/architecture, latest stable version 2025-11-25): Three message types (Requests / Responses / Notifications), Capability Negotiation mechanism, design principle "Servers should not be able to read the whole conversation, nor see into other servers"
• AI Solutions Wiki "Model Context Protocol" entry: Proposed by Anthropic on 2024-11-25; Tools = "analogous to function calling, but over a standard transport"; the significance of separating Resources / Prompts / Tools (mixing them makes Agent behavior worse); 2026 ecosystem adoption list (Claude, OpenAI Agents SDK, Google Gemini Code Assist, Microsoft Copilot Studio, LangGraph, CrewAI, AWS Strands, Amazon Bedrock AgentCore Gateway); MCP Registry preview launched 2025-09
• WISeAgent "MCP Complete Guide": Three-component architecture, Tools/Resources/Prompts definitions and JSON examples, communication flow, lifecycle (initialization→capability negotiation→active communication→session management)
• Juejin "2026 AI Agent Development Practical Guide: From MCP Protocol to Multi-Agent Collaboration" (juejin.cn/post/7671966587106689043): MCP solves "how an Agent calls external tools," A2A solves "how multiple Agents collaborate"; Google released A2A in 2025; Microsoft merged AutoGen into Microsoft Agent Framework in 2026
• CSDN / MCP technical community "2026 Multi-Agent Tech Stack Panorama" "Multi-Agent Breakout Year": N Agents N×(N−1) adapters → O(N) after MCP-ification; Juejin hot list dominated for consecutive weeks by multi-Agent collaboration / MCP protocol / Spec-First; MIIT promoting unified interoperability
• Juejin AI Programming "Multi-Agent Collaboration Patterns and Engineering Practices" (aicoding.juejin.cn/post/7668220205333790729): When a single Agent's tools exceed 20, the accuracy of picking the right tool drops noticeably