What is the Model Context Protocol? A complete guide
The Model Context Protocol (MCP) is an open standard, originally published by Anthropic in November 2024, that defines how AI applications connect to external tools, data and prompts. It replaces one-off integrations — a custom connector for Slack, another for Postgres, another for GitHub — with a single protocol: any application that speaks MCP can talk to any server that speaks MCP, regardless of who built either side. It is a wire format and a set of rules, not a product, a company or a specific piece of software.
Key takeaways
- MCP is a JSON-RPC 2.0 based protocol for connecting AI hosts to external tools, data and prompts, published as an open standard by Anthropic in November 2024.
- It defines three roles — host, client and server — and a small set of primitives a server can expose: tools, resources and prompts.
- Two transports carry the protocol: stdio for local subprocesses, and Streamable HTTP for remote servers reached over the network.
- The protocol's connection model has evolved from a stateful initialize handshake to a newer, stateless per-request capability model, while staying backward compatible with older servers.
- In December 2025 Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation, moving governance out of any single vendor's hands.
Where MCP came from
Anthropic open-sourced MCP on November 25, 2024, describing it as "a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments". The release included the specification itself, SDKs, Claude Desktop support, and a set of reference servers for systems like Google Drive, Slack, GitHub, Git and Postgres — a working demonstration, not just a spec document.
"Today, we're open-sourcing the Model Context Protocol (MCP), a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments." — Anthropic, "Introducing the Model Context Protocol," November 25, 2024
The protocol did not stay an Anthropic project for long. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, with Google, Microsoft, AWS, Cloudflare and Bloomberg also backing it. That matters more than it sounds: it means the spec's future is set by a multi-vendor foundation rather than by the company that happened to invent it, which is part of why MCP has become the connector every major agent framework implements rather than one option among several.
The three roles: host, client, server
MCP's architecture has three participants, and the terms are precise enough to be worth using correctly. The host is the AI application itself — Claude Desktop, an IDE, a custom agent runtime. The host creates one client for every server it connects to, and each client maintains a dedicated, one-to-one connection to its server. The serveris the program that actually provides context — it has no idea it's talking to a language model at all; from its point of view it just received an RPC call, the same as any other API request.
A single host application typically runs several clients at once — one per connected server — which is why a chat client or IDE with a dozen MCP servers configured has a dozen separate connections open behind the scenes, not one shared pipe. For the practical difference this makes to how a server should be run and authenticated, see our companion piece on what an MCP server actually is.
Two layers: data and transport
MCP separates what gets said from how it travels. The data layer is a JSON-RPC 2.0 based exchange protocol: every request, response and notification is a JSON-RPC message, and the data layer defines what those messages mean — discovery, capability negotiation, and the core primitives (tools, resources, prompts). The transport layer is the outer layer: it defines how those same JSON-RPC messages actually get from client to server, handling connection setup, message framing and authentication. Because the two are separate, the exact same message format works whether the server is a local subprocess or a server halfway across the world — only the transport changes.
The primitives a server can expose
MCP defines three core primitives a server can offer, and the model or host decides how to use each one differently:
| Primitive | What it is | Who initiates it | Example |
|---|---|---|---|
| Tools | Executable functions the model can invoke to take an action | Model-controlled — the AI decides when to call it | run_query, create_issue, send_email |
| Resources | Read-only data attached to the model's context | Application-controlled — the host decides what to attach | A file's contents, a database schema, an open ticket |
| Prompts | Reusable prompt templates the server suggests for its own tools | User-controlled — surfaced as a pickable option, e.g. a slash command | A few-shot template for querying a specific database |
Almost every server you'll encounter leans on tools alone; resources and prompts exist and are genuinely useful, but far fewer servers bother implementing them. Each tool is declared with a name, a human-readable description and a JSON Schema for its arguments — and that description is the only thing the model reads to decide when and how to call it, which makes a misleading or manipulated description a real attack surface rather than a cosmetic detail. We cover that specific risk in our guide to MCP prompt injection.
The protocol also defines primitives that flow the other way, from server to client. The best known of these was sampling— a mechanism letting a server ask the host's own model for a completion, so a server author never has to embed an LLM SDK or API key of their own. As the protocol has matured, sampling (along with server-side logging) has been superseded by elicitation, a narrower mechanism for a server to request specific input or confirmation from the user, with servers that need a model of their own now expected to integrate directly with a provider's API instead.
How a call actually flows
Strip away the SDK and the exchange is plain JSON-RPC. A client that wants to know what a server can do sends a request; the server answers with an array of tool definitions. When the model decides to use one, the host sends a tools/call request naming the tool and its arguments, and the server returns a content array — text, an image, an embedded resource — that the host folds back into the conversation as though it were any other piece of context. The server can also push notifications, JSON-RPC messages with no id and no expected reply, so it can tell a client its tool list changed without waiting to be polled.
Getting to that point requires the two sides to agree on what they support, and this is where MCP has genuinely changed shape over its lifetime. Servers built against the original specification (2025-11-25 and earlier) open every connection with a stateful initializehandshake, in which the client and server exchange their supported capabilities once before anything else can happen. Newer servers, built against later revisions of the spec, drop that handshake entirely: every request carries its own protocol version and capabilities inline, so the server can process each request independently, and a client can optionally call a discovery method up front purely as a convenience rather than a requirement. A well-built client detects which style a given server speaks and falls back accordingly — which is exactly the kind of compatibility detail that separates a mature implementation from a weekend project, and one reason to check a server's SDK version rather than assume it against how to vet an MCP server.
stdio and Streamable HTTP
Two transports carry MCP messages in practice. stdio runs the server as a subprocess on your own machine, talking to the client over standard input and output — no network involved, no auth beyond whatever permissions the process already has, and typically one client per server. This is how Claude Desktop runs a local filesystem server, for instance. Streamable HTTPis built for servers that live somewhere else: it uses HTTP POST for client-to-server messages, with optional Server-Sent Events for streaming responses back, and it supports the authentication methods you'd expect from any hosted API — bearer tokens, API keys, and OAuth for obtaining them. A remote server built this way can serve many clients at once, which a stdio server structurally cannot. The choice between the two changes what you need to check before you trust a server — see remote vs local MCP servers for the practical difference.
MCP vs. a plain API vs. function calling
None of this is a new capability — an agent could always call an API or invoke a function you defined yourself. What MCP changes is who has to write the integration and how many times. Hand-rolled function callingmeans you write the tool definitions and the code that executes them, specific to one model provider's function-calling format. A plain REST or GraphQL API wasn't designed for a model to introspect at all — there's no standard way for an agent to discover what it can do or how to describe it to the model. MCP sits between the two: it standardizes the description format (tool name, description, JSON Schema) and the transport, so a server built once, by anyone, can be discovered and called by any MCP-compatible host without either side writing bespoke glue. The trade-off is that MCP only helps once both ends adopt it — a legacy internal API still needs someone to wrap it in an MCP server before an agent can use it directly.
Where MCP is headed
Two things are true about MCP's trajectory at once: the protocol keeps evolving — the shift away from the stateful initializehandshake and the deprecation of sampling in favor of elicitation are real, recent changes to the spec, not settled history — and its governance keeps getting more distant from any single company. Moving to the Linux Foundation's Agentic AI Foundation, with Anthropic, Block, OpenAI, Google, Microsoft, AWS, Cloudflare and Bloomberg all involved, is the clearest signal that MCP is being treated as infrastructure the whole industry depends on, not a feature of one vendor's product.
What hasn't changed is that the protocol says nothing about whether a given server is safe, maintained or honestly described — that's left entirely to whoever builds and publishes it. The ecosystem has grown fast enough that this gap is the practical problem now: Vouchity currently tracks 320MCP servers across the public registry, and being reachable over the protocol tells you nothing about whether any one of them deserves a connection to your agent. That's the layer a Trust Score is built to cover — you can look any server up in the registry, browse the highest-scoring ones on the trust leaderboard, or read how to vet a server yourself before you wire it in.
Frequently asked questions
What is the Model Context Protocol (MCP)?
MCP is an open standard, originally published by Anthropic in November 2024, that defines how AI applications (hosts) connect to external tools, data and prompts through servers. It standardizes the message format (JSON-RPC 2.0) and transport so a server built once can be used by any MCP-compatible host.
Who created MCP and who controls it now?
Anthropic created and open-sourced MCP in November 2024. In December 2025, Anthropic donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, with Google, Microsoft, AWS, Cloudflare and Bloomberg also backing it — moving governance away from any single vendor.
What are MCP's three core primitives?
Tools (executable functions the model can invoke, like a database query or an API call), resources (read-only data attached to context, like a file or schema), and prompts (reusable prompt templates a server suggests for its own tools).
What's the difference between MCP and function calling?
Function calling is provider-specific: you write the tool definitions and execution code against one model vendor's format. MCP standardizes both the description format and the transport, so a server built once can be discovered and called by any MCP-compatible host, not just one provider's models.
What transports does MCP use?
Two: stdio, where the server runs as a local subprocess and talks to the client over standard input/output with no network involved, and Streamable HTTP, where a remote server is reached over HTTP with optional Server-Sent Events for streaming and standard auth (bearer tokens, API keys, OAuth).
Trust Score changes, in your inbox
A weekly digest of newly flagged risks and the biggest Trust Score movers across the MCP registry. No spam, unsubscribe anytime.
