What is the Model Context Protocol (MCP)?

The Model Context Protocol is an open standard for connecting AI applications to external tools, data, and workflows through a single, consistent interface. Anthropic, which created it, describes MCP as being like a USB-C port for AI applications: one connector that any compatible tool can plug into.

That analogy is useful for about ten seconds, so let us go past it. What MCP really standardizes is three things an AI model constantly needs from the outside world: the ability to read data (a document, a database row, a file), the ability to call functions (send an email, query an API, run a job), and the ability to reuse structured workflows (a saved prompt template). Before MCP, every one of those connections was a bespoke, one-off integration.

Who created MCP and when

MCP was introduced and open-sourced by Anthropic on November 25, 2024, created by engineers David Soria Parra and Justin Spahr-Summers. Anthropic shipped it as a genuinely open project: a public specification, official SDKs, and an open repository of reference servers. Within months it stopped being one company's idea and became a de facto industry standard, which is why you now see it everywhere from IDEs to enterprise platforms.

The problem MCP solves: the N times M integration problem

Here is the core idea, and it is the single most important thing on this page.

Imagine you have N AI applications (Claude Desktop, an IDE assistant, a customer support agent) and M systems you want them to reach (GitHub, Slack, Postgres, your internal API). Without a shared protocol, connecting them means building N times M custom integrations. Every new AI app has to re-integrate every tool. Every new tool has to be wired into every app. The work explodes.

MCP collapses that to N plus M. Each application implements the protocol once as a client. Each tool implements it once as a server. Now any client can talk to any server.

The result is a simpler, more reliable way to give AI systems access to the data they need, replacing fragmented integrations with a single protocol.

That quote is Anthropic's framing from the launch, and it is the whole thesis. MCP is the integration layer for AI.

MCP architecture: hosts, clients, and servers

MCP uses a client-server model with three roles. Getting these three straight is the key to understanding everything else.

MCP host

The host is the AI application the user actually interacts with: Claude Desktop, an AI-powered IDE like Cursor, a chat interface, or an autonomous agent. The host contains the orchestration logic and holds one or more clients.

MCP client

The client lives inside the host and maintains a dedicated, stateful, one-to-one connection to a single server. If a host connects to five servers, it runs five clients. The client handles the handshake and capability negotiation with its server.

MCP server

The server is the program that exposes capabilities to the AI: a GitHub server, a Slack server, a Postgres server, a web-search server, or a wrapper around your own internal API. This is the part you build and run. Keep this distinction in mind, because the server is where the real engineering work, and the real security surface, lives.

How the pieces talk: JSON-RPC 2.0

Every message between client and server is JSON-RPC 2.0, a lightweight, well-established remote-procedure-call format. The connection is stateful and begins with an initialize handshake, during which client and server negotiate protocol version and capabilities.

One detail most explainers miss: MCP deliberately borrows its design from the Language Server Protocol (LSP), the standard that lets one code editor support many programming languages. LSP solved the same N times M problem for editors and languages. MCP applies the same proven pattern to AI apps and tools. That lineage is confirmed in the official MCP specification, and it is a big reason the protocol felt mature so quickly.

The core building blocks: tools, resources, and prompts

An MCP server exposes its capabilities through three primitives. The easiest way to keep them straight is to ask "who is in control of this?"

Tools

Tools are functions the AI model can call, and they can have side effects: send a message, write to a database, hit an external API. Tools are model-controlled, meaning the model decides when to invoke one based on the task.

Resources

Resources are data and context the server exposes for reading: files, database records, documents. Resources are read-only. They return information, they do not perform actions. Think of tools as verbs and resources as nouns.

Prompts

Prompts are reusable, templated workflows that a user can select to structure an interaction with the server. They are user-controlled entry points into a common task.

Client-side primitives

The picture is not one-directional. The client can also offer capabilities back to the server, which is what makes MCP feel current rather than a static plugin format:

• Sampling: a server can ask the host to run an LLM completion on its behalf.
• Roots: the client tells the server which filesystem or URI boundaries it is allowed to operate in.
• Elicitation: a server can request additional input from the user mid-task.

How MCP works: a step-by-step walkthrough

Enough theory. Here is what actually happens when an AI app uses a tool over MCP.

1. The host starts a client and opens a connection to a server, either a local process or a remote endpoint.
2. The client and server run the initialize handshake and negotiate protocol version and capabilities.
3. The client asks the server what it can do by calling tools/list (and, if relevant, resources/list and prompts/list).
4. Given the available tools, the model decides one is needed and the client sends a tools/call request.
5. The server executes the function and returns a structured result, which flows back into the model's context.

Here is a minimal tools/list exchange so you can see the JSON-RPC shape:

// Client -> Server
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }

// Server -> Client
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [\
      {\
        "name": "search_orders",\
        "description": "Find orders by customer email",\
        "inputSchema": {\
          "type": "object",\
          "properties": { "email": { "type": "string" } },\
          "required": ["email"]\
        }\
      }\
    ]
  }
}

The model reads that schema, decides to call search_orders with an email, and the server returns the result. Simple, discoverable, and identical no matter which host or which server is involved. That uniformity is the whole point.

MCP transports: stdio, SSE, and Streamable HTTP

MCP separates what messages mean from how they travel. There are two transports that matter, plus one that is now legacy. Getting this right is a quiet mark of authority, because most guides gloss over it.

stdio

With stdio, the client launches the server as a local subprocess and talks to it over standard input and output. It is fast, simple, and ideal for local development tools and desktop apps where the server runs on the same machine as the host.

HTTP with SSE (the original remote transport)

The first way remote servers worked combined HTTP with Server-Sent Events (SSE). It did the job but had real limitations around scalability and statelessness. It is now deprecated in favor of the transport below. If you read an older tutorial that only mentions HTTP plus SSE, it is out of date.

Streamable HTTP (the current remote standard)

Streamable HTTP was introduced in the 2025-03-26 revision of the spec and replaced the old HTTP plus SSE approach for remote servers. It supports streaming responses, can operate statelessly, and scales far better for hosted, multi-user deployments. This is what you deploy today when the server does not live on the user's machine.

The rule of thumb: local integration means stdio, anything remote or hosted means Streamable HTTP.

Why MCP matters for AI agents

An AI agent is only as capable as the tools and data it can reach. A brilliant model with no connection to your systems is a very expensive text generator. MCP is the standard plumbing that gives agents that reach, which is why it landed at exactly the moment agents went mainstream.

Three things make it matter:

• Build once, use everywhere. Expose a capability as an MCP server and any MCP-compatible host or model can use it. You are no longer locked into one vendor's proprietary plugin format.
• Persistent, structured context. Because connections are stateful and capabilities are discoverable, agents can maintain context as they move between tools rather than re-learning your stack every session.
• A shared ecosystem. Thousands of servers already exist for common systems, so a lot of the integration work is already done.

It is worth being precise about what MCP is not. MCP is not an agent framework, and it does not replace orchestration. The model still decides when to call a tool. Frameworks and platforms still decide how the agent reasons, remembers, and stays within guardrails. MCP only standardizes how the tool call is made. If you want to go deeper on the layers around it, our guides on AI agent architecture and AI agent orchestration cover the parts MCP deliberately leaves out, and AI agent memory explains why an agent's memory is a separate concern from the resources a server exposes.

MCP vs traditional APIs and function calling

If MCP is just a way to call functions, how is it different from a REST API or a model's built-in function calling? The difference is standardization and discovery.

Function calling tells one model about one set of functions you wired in by hand. MCP turns that into an open, discoverable ecosystem any client can join.

The MCP ecosystem and adoption

The clearest signal of MCP's importance is how fast the rest of the industry adopted it. Anthropic released it in November 2024. Within the following months, it was embraced across the major AI platforms and picked up by the largest developer-tools companies, moving from a single vendor's specification to something close to an industry default.

The tooling backs that up:

• Official SDKs exist for TypeScript, Python, C#, Kotlin, Go, Ruby, Rust, Java, Swift, and PHP, so you can build a server in whatever stack you already use.
• The reference servers repository has passed 89,000 stars and 11,000 forks, with example servers for Git, filesystem access, fetch, memory, and more.
• An MCP Registry now exists to help discover published servers, and early adopters like Block and Apollo integrated it into their own systems.

MCP security considerations

Here is the part most "what is MCP" articles rush past, and it is the most important part if you plan to run servers for real. MCP grants AI models arbitrary data access and code execution paths. The official spec says so plainly: "The Model Context Protocol enables powerful capabilities through arbitrary data access and code execution paths. With this power comes important security and trust considerations that all implementors must carefully address."

In other words, an MCP server is a new and powerful attack surface. Treat it like one.

Tool poisoning and indirect prompt injection

The sharpest known risk is tool poisoning, discovered and demonstrated by Invariant Labs. The mechanism is simple and nasty: an AI model reads the full text of a tool's description, but the user usually sees only a simplified label. A malicious server can hide instructions inside a tool description that tell the model to read your SSH keys or config files and quietly exfiltrate them, all while showing you an innocent-looking "add two numbers" tool.

Invariant documented several variants worth knowing by name:

• Rug pulls: a server behaves well during approval, then changes its tool descriptions to something malicious after you have trusted it.
• Tool shadowing: a malicious server injects instructions that alter how the agent uses a different, trusted server, for example silently redirecting every email to an attacker.
• Indirect prompt injection: hidden instructions ride in on tool descriptions or tool outputs and hijack the agent.

How to run MCP servers safely

The protocol cannot enforce safety for you. The spec is explicit that tool descriptions "should be considered untrusted, unless obtained from a trusted server," and that hosts must get explicit user consent before invoking any tool. Practically, that means:

• Treat every tool description and tool output as untrusted input.
• Schema-validate server responses instead of trusting them blindly.
• Scope each server to least privilege, only the data and actions it truly needs.
• Pin or verify trusted servers so a rug pull cannot silently change behavior.
• Require human approval for sensitive or irreversible actions.
• Monitor and audit every tool call, so nothing happens that you cannot see.

That last pair, human approval and full visibility, is the difference between a demo and a system you can actually deploy. If you want the deeper agent threat model, our AI agent security guide and our breakdown of AI agent guardrails go further than a protocol overview can.

Getting started with MCP

You do not need to build anything to try MCP. A good path from zero:

• Add an existing server (Git, filesystem, fetch) to an MCP host like Claude Desktop or an MCP-enabled IDE.
• Build a simple server with an official SDK in your preferred language.
• Inspect it with the MCP Inspector to see the tools, resources, and prompts it exposes.
• Deploy it, then put a real governance layer around it before you point it at anything sensitive.