Model context protocol
Understand Anthropic's Model Context Protocol (MCP), how it standardizes tool and resource access for AI agents, and when to build an MCP server instead of raw function calling.
TL;DR
- MCP is an open protocol (Anthropic, November 2024) that standardizes how AI models connect to external tools, data sources, and prompt templates.
- It collapses the N x M integration problem: instead of building custom connectors for every (AI client, tool) pair, you build one MCP server that works with any conforming client.
- Three primitive types: tools (model-controlled actions), resources (application-controlled data), and prompts (user-controlled templates).
- Architecture: a host (such as Claude Desktop, Cursor, or another application) contains an MCP client that connects to MCP servers over
stdio(local) or Streamable HTTP (remote), using JSON-RPC 2.0. Older revisions used HTTP+SSE. - The ecosystem includes many open-source MCP servers (filesystem, GitHub, Slack, Postgres, and others) and clients; exact counts and support change quickly.
- Use MCP when your tools need to work with multiple AI clients. Use raw function calling when you control both ends and portability does not matter.
30-Second Explanation
Mental model: MCP is a protocol boundary between an AI host and servers that expose tools, resources, or prompts. The host controls connections and consent; the server performs the actual side effects. Standardization can reduce duplicated adapters, but it does not remove authentication, authorization, validation, or prompt-injection risk.
The problem it solves
Your team builds a code search tool for your LLM-powered assistant. It works with your OpenAI-based agent. Then your team adopts Cursor. And Claude Desktop. And a LangGraph-based internal agent. Each AI client has a different tool integration format, so you end up maintaining four separate implementations of the same underlying tool.
That is the N x M integration problem. N AI clients, M tools. Every combination requires custom glue code. When the tool's API changes, you update four places. Behavior drifts between implementations because nobody tests all four.
Teams can otherwise rewrite the same Slack integration for several AI clients, with different error handling and parameter names. MCP is intended to reduce that duplicated adapter work, although client-specific behavior and testing still remain.
The bottom line: MCP can reduce an N × M integration matrix toward an N + M model by standardizing the server boundary. The savings are greatest when several clients share the same tools; it does not eliminate client configuration or compatibility work.
What is it?
The Model Context Protocol is an open specification for communication between AI model hosts and servers that expose tools, data, and prompts. Anthropic published it in November 2024, but it is developed as a community standard with contributions from multiple companies.
Think of MCP as USB-C for AI integrations. Before USB-C, every device had a different cable and connector. Before MCP, every AI client had a different tool integration format. USB-C gives you one physical interface that works with any device. MCP gives you one protocol that works with any conforming AI client.
The protocol is transport-agnostic and uses JSON-RPC 2.0 as its message format. It defines a clear separation: the AI application (the host) contains an MCP client, the tools live in MCP servers. The client discovers what the server offers, and the model decides what to use and when.
If you know Language Server Protocol (LSP) from the editor world, MCP follows the same philosophy. LSP standardized how editors talk to language tools so you build one language server and every editor can use it. MCP does the same for AI tool access.
The specification is open-source (MIT license) and hosted on GitHub. Official SDKs exist for TypeScript and Python, with community SDKs for Rust, Go, Java, and C#. Anthropic stewards the spec but does not control it. Any company can build MCP clients or servers without permission or licensing.
How it works
Architecture
The host application (Claude Desktop, Cursor, your custom agent) embeds an MCP client. That client maintains connections to one or more MCP servers. Each server exposes some combination of the three primitives. The model, through the host, discovers available capabilities and decides what to use based on the current task.
One important constraint: each MCP client maintains a 1:1 connection with each server. A host that connects to five servers has five independent client instances. The servers do not know about each other. Coordination across servers (if needed) happens in the host application, not at the protocol layer.
A single host can connect to many servers simultaneously. Your Cursor instance might connect to a filesystem MCP server, a GitHub server, and your company's internal search server, all at once. Each server is independent and stateless from the others.
The three primitives
MCP defines three primitive types, each with a different control model:
| Primitive | Controlled by | Purpose | Example |
|---|---|---|---|
| Tools | Model decides when to invoke | Execute actions | run_tests(file), send_slack(channel, msg) |
| Resources | Application decides when to read | Provide data into context | file:///src/main.py, db://users/123 |
| Prompts | User decides when to activate | Reusable prompt templates | code-review(diff), summarize(document) |
Tools are the most familiar if you know function calling. A tool has a name, a description the model reads, and a JSON Schema for parameters. The model decides whether and when to call a tool based on the conversation. The key difference from raw function calling: the tool lives in an external server, not embedded in your API request.
Resources are data endpoints the model can read. Think of them like GET endpoints in a REST API. A filesystem server exposes files as resources. A database server exposes tables or rows. Resources use URIs (file:///path, db://table/id) and can include MIME types for structured data.
Prompts are reusable templates with arguments. A code review server might expose a code-review prompt that takes a diff and returns a structured review prompt. This centralizes prompt engineering in the server, so every client benefits from improvements to the template.
The three primitives map to three control models: tools are model-controlled, resources are application-controlled, and prompts are user-controlled. Keeping those control paths distinct helps make permissions and consent explicit.
Transport layer
Protocol versions matter here. The current versioned specification defines stdio and Streamable HTTP as the standard transports. The HTTP + SSE wording in the legacy diagram and code below reflects older MCP revisions; use the current versioned specification when implementing a server.
MCP supports two current transport mechanisms:
Stdio (local): The MCP server runs as a subprocess on the same machine as the client. Communication happens over standard input/output. This is the most common setup for development tools. Claude Desktop launches an MCP server process, pipes JSON-RPC messages through stdin/stdout, and the server responds.
Streamable HTTP (remote): The MCP server runs as an HTTP service at a single MCP endpoint. The client sends requests with HTTP POST; a response can be a JSON object or a request-scoped SSE stream. This supports remote, shared, and cloud-hosted tools.
Both transports carry the same JSON-RPC 2.0 messages. The protocol is the same; only the wire format differs.
The transport choice has real implications. Stdio servers are local subprocesses with no network hop, but they are limited to the host machine. Streamable HTTP requires hosting infrastructure and adds network latency, but it can serve shared clients. Choose based on deployment, authentication, isolation, and latency requirements rather than assuming one transport is always for production.
Server lifecycle
For connection-oriented MCP sessions, the lifecycle commonly follows four phases:
- Initialize: The client sends an
initializerequest with its protocol version and capabilities. The server responds with its own capabilities (which primitives it supports, what features are available). - Negotiate: Client and server agree on the protocol version and feature set. If they cannot agree, the connection fails cleanly.
- Operate: Normal operation. The client can list tools, invoke tools, read resources, and use prompts. The server can send notifications (resource updates, progress events).
- Shutdown: Either side can terminate the connection gracefully.
Continue Reading with Premium
Unlock this article and every other in-depth system design guide on the platform with SDEpedia Premium.
Related Articles
Learn how function calling lets LLMs trigger real APIs and return structured data, why it's essential for production AI systems, and how to design tool schemas that work reliably.
Understand what AI agents are, how the ReAct loop works, what memory and tool primitives look like, and why production agents fail so often at tasks that demos make look easy.
Learn how to construct the context window to get the best results from LLMs, why 'context engineering' has replaced prompt engineering as the key skill, and what belongs in a production system prompt.