Model Context Protocol (MCP) Explained: The USB-C for AI Agents

What is the Model Context Protocol (MCP)?

MCP is an open protocol that defines how AI applications discover and call external tools, read resources, and request prompts using JSON-RPC 2.0 messages over a standard transport. Think of it as USB-C for AI: one cable shape that fits every model and every tool.

Before MCP, every AI app had to write custom glue code for every tool it integrated with. With N models and M tools, you needed N x M integrations. MCP collapses that into N + M: each model speaks MCP once, each tool exposes MCP once, and the matrix becomes a bus.

The protocol defines five primitives, per the official specification:

• Tools -- actions the model can invoke (e.g. search_jira, send_email).
• Resources -- read-only context the model can pull in (e.g. files, database rows).
• Prompts -- reusable templates the user or model can select.
• Sampling -- the server asking the client to run an LLM call on its behalf.
• Roots -- filesystem or URI scopes the server is allowed to operate within.

Every primitive travels as a JSON-RPC 2.0 message. That single design decision is what makes MCP portable across Claude, ChatGPT, Gemini, Cursor, and any future client.

Why was MCP created and who maintains it?

MCP was created by Anthropic in November 2024 to solve the N x M integration problem and to give models a standard way to access live, private context. It is now maintained by the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation.

Anthropic open-sourced the specification on November 25, 2024, alongside SDKs in Python and TypeScript and reference servers for GitHub, Slack, Postgres, and the local filesystem. The goal was explicit: stop forcing every AI product team to rebuild the same connectors.

On December 9, 2025, Anthropic transferred stewardship to the AAIF. According to The New Stack's coverage and the Linux Foundation press release, the AAIF is co-founded by Anthropic, Block, and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg. MCP joined two other founding projects: Block's goose agent runtime and OpenAI's AGENTS.md convention.

The practical effect: no single vendor can fork or break the protocol. Spec changes go through Spec Enhancement Proposals (SEPs) reviewed by working groups. Anthropic still pays core maintainers but no longer owns the trademark or the roadmap.

How does the MCP architecture actually work?

MCP uses a three-part architecture: a host application runs one or more MCP clients, each client maintains a 1:1 connection to an MCP server, and the server exposes tools, resources, and prompts. All messages on the wire are JSON-RPC 2.0.

Here is the message flow for a typical tool call:

1. Initialize -- The client opens the transport and sends initialize with its protocol version and capabilities. The server responds with its capabilities and metadata.
2. Discover -- The client calls tools/list, resources/list, and prompts/list to learn what is available.
3. Inject -- The host serializes the tool list into the LLM's system prompt or native tool schema.
4. Invoke -- When the model decides to call a tool, the client sends tools/call with the tool name and arguments.
5. Execute -- The server runs the tool and returns the result, which the client passes back into the model's context.

   +--------------------+
   |  Host (Claude,     |
   |  ChatGPT, Cursor)  |
   |                    |
   |  +--------------+  |     stdio or          +-----------------+
   |  | MCP Client A |<-+---- Streamable HTTP ->| MCP Server      |
   |  +--------------+  |     (JSON-RPC 2.0)    | (Postgres, Jira)|
   |  +--------------+  |                       +-----------------+
   |  | MCP Client B |<-+----------------------> MCP Server (Git)
   |  +--------------+  |
   +--------------------+

There are two transports defined by the March 2025 transport spec: stdio for local subprocesses and Streamable HTTP for remote servers. The original Server-Sent Events transport was deprecated in favor of Streamable HTTP, which uses a single bidirectional HTTP endpoint with OAuth 2.1.

How does MCP differ from function calling?

Function calling embeds tool definitions inside each LLM request and is vendor-specific. MCP runs tools as separate processes that any vendor's model can discover and invoke through a shared JSON-RPC schema. They are complements, not competitors: most production agents use function calling under the hood to surface MCP tools to the model.

The practical differences:

Dimension	Function Calling	Model Context Protocol
Wire format	Vendor JSON schema in API request	JSON-RPC 2.0 over stdio / HTTP
Tool location	Inline in your app code	Separate server process
Cross-model	Rewrite per provider	Same server, any client
Discovery	Static at call time	Dynamic via tools/list
Auth	Handled by your app	OAuth 2.1 with PKCE built in
Best for	Prototypes, single model	Production, multi-vendor stacks

As the Descope team puts it, "function calling answers what to do; MCP answers how to plug it in." Use function calling for a one-off script. Use MCP the moment you need the same tool to work from Claude Desktop, Cursor, and your own agent at the same time.

Which AI providers support MCP in 2026?

As of May 2026, every major LLM vendor and coding agent supports MCP. The protocol moved from Anthropic-only to industry default in roughly 13 months.

The adoption timeline, from the Pento year-in-review and official MCP blog:

• Nov 2024 -- Anthropic ships MCP with Claude Desktop and SDKs.
• Mar 2025 -- OpenAI adopts MCP across Agents SDK, Responses API, and ChatGPT desktop after Sam Altman's public endorsement.
• Apr 2025 -- Demis Hassabis confirms Gemini support.
• Jun 2025 -- Microsoft ships MCP in Copilot Studio and Visual Studio Code.
• Q4 2025 -- Cursor, Windsurf, Zed, JetBrains, and Cloudflare all ship native MCP.
• Dec 2025 -- Anthropic donates MCP to the AAIF; the Salesforce Agentforce stack adds MCP.
• Q1 2026 -- Google ships MCP in the Gemini API and Vertex AI Agent Builder.

The usage numbers, from DigitalApplied's MCP adoption report:

• 97 million monthly SDK downloads (March 2026), up from 100,000 at launch.
• 18,000+ public MCP servers indexed across registries.
• 78% of enterprise AI teams have at least one MCP-backed agent in production.
• 67% of CTOs name MCP their default agent integration standard.

This is the fastest enterprise protocol adoption since gRPC.

What does a minimal MCP server look like?

A working MCP server is roughly 20 lines of Python. The official mcp SDK provides FastMCP, which uses Python type hints and docstrings to auto-generate the JSON Schema the client needs.

Below is a complete server that exposes a single add tool over stdio. Save as server.py and add it to your Claude Desktop or Cursor config.

# server.py -- minimal MCP server, ~20 lines
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("calculator")

@mcp.tool()
def add(a: float, b: float) -> float:
    """Return the sum of two numbers."""
    return a + b

@mcp.tool()
def multiply(a: float, b: float) -> float:
    """Return the product of two numbers."""
    return a * b

@mcp.resource("config://units")
def units() -> str:
    """Default units used by the calculator."""
    return "metric"

if __name__ == "__main__":
    mcp.run(transport="stdio")

What is happening:

• FastMCP("calculator") registers the server with a name the client will display.
• @mcp.tool() decorators turn ordinary Python functions into MCP tools. Type hints become the JSON Schema; docstrings become the tool description the model sees.
• @mcp.resource(...) exposes read-only context at a URI the client can fetch.
• mcp.run(transport="stdio") starts the JSON-RPC loop on stdin/stdout.

For remote servers, swap the last line for transport="streamable-http" and add OAuth via the mcp.server.auth module. The same tool functions work unchanged. See the official build-server guide for the full walkthrough.

What changes with the 2026 stateless HTTP transport?

The 2026 roadmap finalizes a stateless Streamable HTTP transport so MCP servers can scale horizontally behind load balancers without sticky sessions or shared session stores. This is the headline change in the 2026 MCP roadmap, with the spec release tentatively slated for June 2026.

What stateless HTTP unlocks:

• No sticky sessions -- any server instance can serve any request, so Kubernetes deployments and serverless platforms work natively.
• No distributed session store -- session state moves into signed tokens or external resources the client already holds.
• Server Cards -- a metadata file served at a .well-known URL lets registries and crawlers discover what a server does without opening a live connection. This is the foundation of the public MCP server directory.
• Resumable streams -- the spec defines how a client can reconnect mid-stream after a network blip without losing tool output.

Per Zylos Research benchmarks, the v2.1 Streamable HTTP transport delivers a 95% latency reduction over the deprecated SSE transport with a 100% success rate on stateless session handling under load.

If you are building a server today, the recommendation from the Transports Working Group is unambiguous: design for stateless from day one, store any session data externally, and ship Streamable HTTP with OAuth 2.1 PKCE. Bolting statelessness on later is harder than starting that way.

Dimension	Function Calling	Model Context Protocol (MCP)
Wire format	Vendor-specific JSON schema in API request	JSON-RPC 2.0 over stdio or Streamable HTTP
Coupling	Tool definitions live inside your app code	Tools live in a separate server process
Cross-model portability	Rewrite per provider (OpenAI, Anthropic, Google)	Same server works for any MCP-compatible client
Discovery	Static -- you list functions at call time	Dynamic -- client queries `tools/list` at runtime
State and resources	Tools only	Tools + resources + prompts + sampling + roots
Auth	Handled inside your app	OAuth 2.1 with PKCE built into Streamable HTTP
Best for	Single-model prototypes, one or two tools	Production agents, many tools, multi-vendor stacks