If you have wired an AI assistant into a database, a ticketing system, and a code repository, you already know the tax: every integration is bespoke. Each one needs its own glue code, its own auth handling, its own way of describing what the tool does. Add a new model or a new app and you start over. This is the "M×N problem" — M applications times N data sources, each pairing hand-built.
The Model Context Protocol (MCP) exists to collapse that grid into M+N. It is an open standard, created by Anthropic and launched on November 25, 2024, that defines one uniform way for AI applications to connect to external tools, data, and prompts. Write a server once, and any MCP-compatible host can use it. Build a host once, and it can talk to any MCP server. The official framing is deliberately mundane: MCP is "USB-C for AI integrations." Before USB-C you kept a drawer of proprietary cables; after it, one connector shape carries power, data, and video to anything. MCP does the same for the connection between a model and the outside world.
The design was explicitly inspired by the Language Server Protocol (LSP), which solved the identical M×N problem for code editors and programming languages — one protocol, and any editor gets smart features for any language. MCP applies that lesson to AI applications and their tools.
The host / client / server architecture
MCP defines three roles. Getting these straight is the whole game.
- Host — the LLM application that initiates connections and manages clients. Your IDE, a chat app, or an autonomous agent.
- Client — a connector that lives inside the host and maintains a 1:1 stateful connection to exactly one server. A host with five servers runs five clients.
- Server — a service that exposes context and capabilities to the client. It might wrap a database, a filesystem, the GitHub API, or anything else.
The connection is stateful, and both sides perform explicit capability negotiation at initialization — the client and server announce what they support before any real work happens. The diagram below shows the shape.
For a deeper look at what lives on the right-hand side of that diagram — how you actually build and run a server — see MCP Server Explained.
The primitives: what a server actually exposes
MCP organizes capabilities into a small set of primitives. Three flow from server to client (these are what a server offers); three flow the other way (these are what a server can ask of the client). Knowing which is which tells you who is in control of each interaction.
| Primitive | Direction | Controlled by | What it is |
|---|---|---|---|
| Tools | Server → client | Model | Functions the AI model can invoke to take actions or compute results. |
| Resources | Server → client | App / user | Contextual data and content the host or model can read (files, records, documents). |
| Prompts | Server → client | User | Reusable templated messages and workflows, typically user-initiated. |
| Sampling | Client → server | User-approved | The server requests a completion from the client's LLM — enables server-initiated, agentic recursion. Requires user approval. |
| Roots | Client → server | App | The server inquires about the URI/filesystem boundaries it is allowed to operate within. |
| Elicitation | Client → server | User | The server requests additional structured input from the user mid-interaction. |
The split matters for safety and design. Tools are model-controlled — the model decides when to call them — which is exactly why tool descriptions and outputs need to be treated as untrusted (more on that below). Resources are application-controlled, and prompts are user-controlled. On top of the primitives, MCP also defines utilities for progress reporting, cancellation, logging, error reporting, and configuration.
Sampling, roots, and elicitation are the most often overlooked. They let a server be more than a passive endpoint: a server can ask the host's model to think (sampling), ask what filesystem boundaries it may touch (roots), or ask the human a follow-up question (elicitation). Sampling in particular is what makes recursive, agent-like behavior possible — and because it spends the host's tokens and acts on the user's behalf, the spec requires user approval.
JSON-RPC 2.0: the wire format
Underneath the architecture, every message between a client and server is JSON-RPC 2.0 over UTF-8. That is the entire wire format — request/response objects with a method, params, and an id. Here is a minimal tools/call request and its result:
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": { "city": "Dublin" }
}
}
{
"jsonrpc": "2.0",
"id": 7,
"result": {
"content": [
{ "type": "text", "text": "Dublin: 14°C, light rain." }
],
"isError": false
}
}
Because the format is plain JSON-RPC, MCP is transport-agnostic — the same messages can travel over a local pipe or an HTTP connection, which brings us to transports.
Transports: stdio vs. Streamable HTTP
MCP standardizes two transports, and the choice comes down to where the server runs.
| Transport | Use case | How it works | Status |
|---|---|---|---|
| stdio | Local servers | Client launches the server as a subprocess; newline-delimited JSON-RPC over stdin/stdout, with stderr reserved for logs. Clients SHOULD support it whenever possible. | Current |
| Streamable HTTP | Remote servers | Single HTTP endpoint supporting POST and GET; optional Server-Sent Events for streaming and server→client messages; optional MCP-Session-Id header for stateful sessions; MCP-Protocol-Version header required on requests. | Current |
| HTTP+SSE (original) | — | The two-endpoint transport from the 2024-11-05 revision. | Deprecated — replaced by Streamable HTTP in the 2025-03-26 revision; spec retains backwards-compatibility handling. |
For local tools — a filesystem server, a database client running on your laptop — stdio is the default. For hosted or remote services, Streamable HTTP is the modern choice. A common trap: the older HTTP+SSE transport (introduced in the very first 2024-11-05 spec) is deprecated. It was superseded by Streamable HTTP in 2025-03-26. The specification still documents how to interoperate with legacy HTTP+SSE clients and servers, and transports remain pluggable — custom transports are allowed — but you should not reach for HTTP+SSE in anything new.
When you connect a remote server, authorization comes into play. It is optional and HTTP-transport-based: the MCP server acts as an OAuth 2.1 resource server and the client as an OAuth 2.1 client. The current spec mandates RFC 9728 (OAuth 2.0 Protected Resource Metadata), so servers must publish where their authorization server lives, with discovery via a WWW-Authenticate header on a 401 or a well-known URI. This was introduced in 2025-03-26 and significantly tightened in 2025-06-18.
If you want to wire a server into your own CLI rather than read about it, our walkthrough on adding an MCP server to any AI coding CLI covers Claude Code, Codex, Gemini, and Qwen — and our config generators (Claude Code, Codex CLI, Gemini CLI, Qwen Code) produce the mcpServers block for you.
MCP vs. function calling
This is the comparison people get tangled in, so be precise. They are related but not the same, and MCP does not replace function calling — it feeds it.
Function calling (Anthropic calls it "tool use") is a model-level capability. A single application defines a tool's JSON Schema, passes it to the model, the model emits a structured call when it decides one is needed, and the application's own bespoke code executes it and returns the result. The model never runs code — it only requests a call. This is powerful, but it is per-application and ad hoc: the schema, the execution, and the glue all live in your app and are not interoperable with anyone else's.
MCP is a transport-and-protocol standard that sits one layer above. It defines a reusable client/server wire protocol (JSON-RPC 2.0) so any MCP-compatible host can discover and use any MCP server without custom glue — that is the whole point of solving M×N. Crucially, MCP still uses function calling under the hood: its tools primitive maps onto the model's native tool-use interface. What MCP adds around that is standardized discovery, plus resources, prompts, sampling, roots, elicitation, OAuth-based auth, and pluggable transports.
| Function calling | MCP | |
|---|---|---|
| Layer | Model capability | Protocol / transport standard |
| Scope | One app, one model | Many hosts, many servers |
| Discovery | Hardcoded per app | Standardized (tools/list, etc.) |
| Interoperable? | No — bespoke per app | Yes — any host ↔ any server |
| Beyond tools? | Tools only | Tools, resources, prompts, sampling, roots, elicitation |
| Relationship | The mechanism a model uses to invoke a tool | A standard way to connect models/hosts to tools and data — built on function calling |
In one line: function calling is how one model invokes one tool; MCP is a standard way to connect many models and hosts to many tools and data sources.
See it in all three formats: build a tool definition once and export it as an OpenAI function, an Anthropic tool, and an MCP tool — the same JSON Schema, three envelopes.
Tool / Function-Schema Builder
Build an LLM tool/function definition visually and export it in OpenAI, Anthropic, and MCP formats — one JSON Schema, three provider envelopes, copy-ready.
Open the full Tool / Function-Schema Builder tool →A short history, and who's on board
MCP launched as an open spec on November 25, 2024. What turned it from a useful Anthropic project into an industry baseline was cross-vendor adoption over the following year:
- OpenAI — March 2025; Sam Altman announced support around the 26th, with integration into the Agents SDK and ChatGPT desktop, later extended to ChatGPT "apps" in September 2025.
- Google / DeepMind — April 2025; Demis Hassabis confirmed MCP support for Gemini.
- Microsoft — May 2025; Microsoft and GitHub joined the MCP steering committee and announced native MCP support in Windows 11.
- Others — Block (Square), Cloudflare (remote MCP hosting), Replit, Zed, and Sourcegraph, with official SDKs across Python, TypeScript, Java/Kotlin, C#, and Go.
Governance has since moved to neutral ground: in December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI. The current stable specification is 2025-11-25, released on MCP's one-year anniversary (earlier revisions: 2024-11-05, 2025-03-26, 2025-06-18). There is also an official MCP Registry — an open catalogue and API for discovering public servers — which launched in preview on September 8, 2025 at registry.modelcontextprotocol.io. Treat it as preview-grade: useful for discovery, not yet a durability guarantee.
One honest caveat: the protocol is still evolving. The spec is versioned by date and moves quickly, and a release candidate beyond 2025-11-25 may be in flight by the time you read this. Pin to a known revision in production, and verify transport and auth details against the spec version you actually target rather than against a blog post.
Where MCP fits in the bigger picture
MCP solves one specific thing very well: connecting an agent to tools and data — the vertical relationship between a model and the outside world. It is not designed for agent-to-agent collaboration. That horizontal problem — letting separate agents discover each other and delegate work — is the domain of Google's Agent2Agent (A2A) protocol, which is complementary, not competitive. A typical stack uses MCP for tools and A2A for coordination between agents. (Mind the acronym soup: "A2A" here is the AI agent protocol, not Yamaha receiver linking or account-to-account payments; "ACP" is even more overloaded — IBM/BeeAI's Agent Communication Protocol is agent-to-agent, while Zed's Agent Client Protocol is editor-to-agent.) Our pillar guide to MCP, A2A, and ACP untangles all of it.
Finally, a word of caution before you connect everything in sight. A protocol that lets a model invoke tools and read returned content is a protocol that can be abused — tool poisoning hides instructions in a tool's description, indirect prompt injection rides in on tool results, and a confused-deputy server can turn one broad OAuth token into a private-data leak. None of these are theoretical; several have shipped as CVEs. Treat tool descriptions and outputs as untrusted, allowlist vetted servers, scope credentials tightly, and keep a human in the loop for irreversible actions. We cover the full risk catalogue and mitigations in MCP Security Risks.
MCP is, at its core, a boring-in-the-best-way piece of infrastructure: a single connector standard that turns a combinatorial integration mess into something composable. That is exactly why it caught on across every major AI vendor within a year — and why it is worth understanding well before you build on top of it.