MCP Explained

The Model Context Protocol (MCP) is an open standard that lets any AI application connect to any tool or data source through a single, uniform interface. Before MCP every integration was a one-off; after MCP a single server implementation works with every compliant host - Claude, Cursor, VS Code, or your own app.

What MCP standardises

Before MCP, connecting an LLM to an external capability - a database, a file system, a web search API - meant writing a bespoke integration for every (model, tool) pair. A team with three models and ten tools needed thirty integrations. Adding a new model meant rewriting all ten. This is the same "N times M" problem that USB solved for hardware peripherals.

MCP introduces a client-server architecture between the AI application and the tools it uses. The MCP specification defines:

• A JSON-RPC 2.0 wire format that all compliant implementations speak.
• Three primitive types (Tools, Resources, Prompts) that cover how models interact with external systems.
• A capability negotiation handshake so client and server agree on supported features at connection time.
• Lifecycle management: how servers start, how clients reconnect, and how sessions are terminated cleanly.

Any host application that implements the MCP client side automatically gains access to the entire ecosystem of MCP servers - without any per-server integration work.

Host, client, and server

MCP has three roles. The host is the user-facing application (Claude Desktop, Cursor, VS Code Copilot, or your own product). The host embeds one or more MCP clients - each client maintains a 1:1 connection to one MCP server. The MCP server is a lightweight process that exposes capabilities (tools, resources, prompts) over the wire.

A host can run many MCP clients simultaneously, so a single session in Claude Desktop might have live connections to a Filesystem server, a GitHub server, and a Postgres server at the same time. The LLM sees all their capabilities as a unified tool set in its context.

Tools, Resources, and Prompts

MCP defines exactly three primitive types. Understanding them is 90% of understanding the protocol.

Transports

MCP separates the protocol layer (JSON-RPC message format) from the transport layer (how bytes move between client and server). Two transports are defined in the spec:

Implementers can also define custom transports (WebSocket, gRPC, etc.) as long as both sides agree. The JSON-RPC message envelope is transport-agnostic.

How a request flows

Tracing a single tool call end-to-end shows how all three layers interact:

1. 1

   LLM generates a tool call

   The model finishes a reasoning step and emits a structured tool-call object: { name: "read_file", arguments: { path: "/etc/hosts" } }. The host intercepts this before returning it to the user.
2. 2

   MCP Client routes the call

   The host looks up which MCP Server registered the tool "read_file" during the capability handshake. It serialises the call as a JSON-RPC 2.0 request and sends it over the appropriate transport (stdio or HTTP+SSE).
3. 3

   MCP Server executes

   The server receives the request, validates arguments against the tool's JSON Schema, runs the actual logic (reads the file from disk), and returns a JSON-RPC response with the file contents.
4. 4

   Result returned to the host

   The MCP Client receives the response and formats it as a tool result in the model's conversation context. If the server sends a progress notification mid-execution, the host can stream it to the user.
5. 5

   LLM continues reasoning

   With the tool result in context, the LLM decides whether to make another tool call or produce the final answer. This loop repeats until the model emits a terminal text response.

Why MCP matters for agents

Agents are LLMs that loop over (plan, tool call, observe) until a goal is reached. The quality of an agent is largely determined by the quality and breadth of its tool set. MCP makes the tool-set problem separable from the agent logic:

• Composability - mix and match servers from the ecosystem. An agent can use a community-built GitHub server alongside your proprietary internal search server without any glue code.
• Security boundary - the MCP Server process is isolated. A compromised tool call cannot access host memory; it can only return what the server chooses to expose.
• Portability - an MCP Server you write for Claude Desktop today works in Cursor, VS Code, and any future host without changes.
• Observability - because all tool calls flow through a standard wire format, you can log, rate-limit, and audit them in one place.

To understand how agents use MCP in practice, see AI Agents Explained. For the role that builds these systems, see the AI Agent Engineer guide.