MCP: The Standard for Agent Communication

TL;DR. MCP has become the standard for agent communication. Transferred to the Linux Foundation's Agentic AI Foundation (AAIF) in December 2025, adopted by Anthropic, OpenAI, Google, and Microsoft by March 2026, with public servers crossing 10,000. It solves the M×N integration explosion with three primitives over JSON-RPC — Tools, Resources, and Prompts — but where it breaks in operation is not the protocol; it's when the number of connected servers grows.

MCP

MCP (Model Context Protocol) is an open protocol that standardizes communication between agents and external tools or data sources. Anthropic announced it in November 2024, and in December 2025 it was transferred to the Linux Foundation's Agentic AI Foundation (AAIF). The AAIF was co-founded by Anthropic, Block, and OpenAI, and is backed by Google, Microsoft, AWS, and Cloudflare. By March 2026, all four major providers (Anthropic, OpenAI, Google, Microsoft) had adopted it, and public MCP servers crossed 10,000.

The problem MCP sets out to solve

Before MCP, integrating agents with external tools and data was stuck in an M×N explosion. For M agents (Claude Code, ChatGPT, Cursor, Cline, …) to each reach N tools and data sources (GitHub, Slack, DB, filesystem, …), you had to write fresh glue code between every pair. Concretely, four things were unstandardized.

1. Tool-definition format — Claude's function-calling spec, OpenAI's tools, the Cursor plugin API, and Cline's tool interface were all different. Reusing a tool written for one on another meant rewriting it.
2. Tool-discovery mechanism — there was no consistent way for a model to query which tools are available. Each agent required separate registration in its own plugin system.
3. Permission / trust boundaries — what the model calls autonomously, what only runs on user command, and what is read-only weren't separated at the protocol level.
4. Data-source access — apart from tool calls, there was no standard channel for pulling context data like documents, schemas, and files toward the model.

Components

MCP consists of four things.

1. Transport layer. It runs over JSON-RPC 2.0 messages. Local uses stdio (child-process standard I/O); remote uses Streamable HTTP (the successor to the earlier SSE). Both use the same message set.

2. Client-server model. A client (an agent harness: Claude Code, ChatGPT, Cursor, etc.) connects to one or more servers (tool/data providers). A server runs as an external process and exposes defined capabilities.

3. Three primitives. The three types of resource a server exposes.

4. Standard message set. initialize (handshake), tools/list · resources/list · prompts/list (discovery), tools/call · resources/read · prompts/get (execution). It's bidirectional, and reverse RPC — a server requesting sampling from the client — is also possible.

How the components solve the problem

Each of the four problems in §1.1 is resolved by a component in §1.2. The key is that the MCP server sits as an adapter layer, separating and standardizing the two interfaces.

flowchart LR
    AI["AI / agent<br/>(Claude · ChatGPT · Cursor)"]
    MCP["MCP server<br/>(adapter)"]
    EXT["External channels<br/>(GitHub · DB · files · …)"]

    AI <-->|"JSON-RPC 2.0<br/>(standard wire)"| MCP
    MCP <-->|"each channel's protocol<br/>(HTTP · SQL · files · gRPC · …)"| EXT

    classDef box fill:#161821,stroke:#2a2d38,color:#e7e9ec;
    class AI,MCP,EXT box;

The left is JSON-RPC, common to all clients; the right is each external channel's own protocol. The MCP server takes one side and translates it into the other.

• M×N → M+N. JSON-RPC + the standard message set is the common wire format. Write a server once and every MCP client calls it with the same messages. A single GitHub MCP server works in Claude, ChatGPT, and Cursor at the same time.
• A unified tool-definition schema. Tools carry a JSON-Schema-based input definition. The model decides on a call from name, description, and input schema alone, and the implementation is encapsulated inside the server. The same tool definition holds across all clients verbatim.
• Deterministic discovery. When a client issues tools/list and the like at session start, the server returns all available resources as metadata. They're discovered automatically without separate registration, and that catalog becomes context. Thanks to the metadata/body split (metadata at session start, execution at call time), context cost stays controlled.
• Protocol-level permission boundaries. The three primitives pin down who triggers. Tools are called autonomously by the model (side effects possible), Resources are loaded as context by the client (read-only), and Prompts are called only by the user (templates). This separation is the starting point for prompt-injection defense and the permission model.

The core point is that a tool's description is itself the routing signal. The model doesn't know the body (the server's internal implementation) — it decides which tool to call from name, description, and input schema alone. So description quality is call accuracy. This mechanism directly explains many of the operational conflict patterns in §2.

The difference from skills

If you've read the agent-skill piece, a question comes to mind — aren't skills and MCP the same thing? The mechanisms are alike. Both load metadata at session start and keep the body and execution lazy. Description quality drives call accuracy in both. But the unit differs.

The operational division comes down to one line.

• MCP decides: which tools are available
• Skills / policy decide: when and how to call them

When running them together, the priority order is:

1. Explicit user instruction (CLAUDE.md, AGENTS.md) — top priority
2. Skill-body rules — procedure decisions
3. MCP tool catalog — which tools are available
4. Base system prompt — lowest

And here's one key anti-pattern — don't bake procedure into a homemade MCP server. A server should be a bundle of stateless, deterministic tools, with procedure and policy kept on the skill side. Neither works alone — tools without procedure get called wrong by the model, and procedure without tools can't reach the outside world.

Where It Collides by Design

Not observed from running it, but read off the spec and its components to mark the friction that's structurally inevitable.

1. Tool-name collisions — when two servers expose a tool of the same name, the model routes wrong. Some clients dodge this by adding a prefix.
2. Context explosion — past 10 servers, the tool list alone consumes thousands of tokens. Disabling unused servers helps both cost and accuracy.
3. Permission / trust boundaries — when a third-party MCP demands OS permissions or tokens, that server's responses flow straight into the model's context. Inducing tool calls via prompt injection is a real attack vector.
4. Description noise — a description that's too generic ("processes it") drops call accuracy. A description must be specific enough that the model can judge when to call it.
5. Version / protocol drift — a server adopts a new protocol version the client can't keep up with. You have to look at the initialize response to debug it.

Synthesis

MCP is simple as a protocol in itself. The Linux Foundation transfer plus full adoption by the four major providers has effectively removed any chance of the protocol wobbling. Where it breaks is always after the number of connected servers grows, and there the whole of operation comes down to two axes: description quality and a policy that narrows tool selection.

References

• modelcontextprotocol.io
• modelcontextprotocol/specification
• modelcontextprotocol/servers
• modelcontextprotocol/python-sdk
• modelcontextprotocol/typescript-sdk
• A Year of MCP: From Internal Experiment to Industry Standard (Pento, 2026)
• The 2026 MCP Roadmap