Model Context Protocol (MCP).

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to outside tools and data through one common interface. Anthropic released it in November 2024.

The problem it solves is integration cost. Before MCP, every AI app wrote custom glue for every system: one connector for GitHub, another for Postgres, another for Slack. With M apps and N systems, you maintain M times N connectors.

MCP turns that into M plus N. You expose a system once as an MCP server, and any MCP-capable app can use it. The official analogy is a USB-C port for AI applications: one connector, many devices.

The real payoff is portability. Integrations move between hosts, and you add one without rewriting the app.

MCP splits an integration into three roles: a host, one or more clients inside it, and servers that expose capabilities.

Host (Claude Desktop, IDE, agent)
├── Client A  <-->  Server A  (filesystem, local)
├── Client B  <-->  Server B  (GitHub, remote)
└── Client C  <-->  Server C  (database, local)

The host is the AI application the user sees. It holds the model conversation, renders the UI, and asks the user for permission.

A client is a connector the host creates, and each client talks to exactly one server. Ten servers means ten clients. Since the 2026-07-28 revision, every request a client sends carries its own protocol version and capabilities, so no session state sits between requests.

A server is a separate program offering capabilities to its client. It may run locally as a subprocess or remotely over HTTP.

That one-to-one pairing is the isolation boundary. A server sees only what its own client sends, never other servers or the full conversation.

MCP servers expose three primitives: tools, resources, and prompts. They differ mainly in who decides when each one is used.

• Tools are model-controlled. The LLM chooses and calls them mid-turn, normally behind user approval.
• Resources are application-controlled. The host decides what data to read and attach as context.
• Prompts are user-controlled. The user picks them on purpose, like a slash command or menu item.

This control axis should drive your design. Anything with side effects belongs in a tool, so the host can gate it. Plain read-only context belongs in a resource, so the host stays in charge of the context window. A workflow a person should trigger belongs in a prompt.

Sampling, roots, and elicitation are client primitives, not server ones.

A tool is a function a server exposes that the model can choose to call. Each tool has a unique name, a description, and an inputSchema, the JSON Schema that describes its arguments.

Discovery and calling are two JSON-RPC methods. The client sends tools/list and hands the returned definitions to the model. When the model picks one, the client sends tools/call with the name and arguments. The server returns content blocks such as text, images, or embedded resources.

// client -> server
{"jsonrpc": "2.0", "id": 2, "method": "tools/call",
 "params": {"name": "get_weather", "arguments": {"city": "Berlin"}}}

// server -> client
{"jsonrpc": "2.0", "id": 2,
 "result": {"content": [{"type": "text", "text": "18C, cloudy"}], "isError": false}}

Two details matter. Tools are model-controlled, so hosts should ask the user before running one. And if the server declares the listChanged capability, it can send notifications/tools/list_changed, and the client must re-list to stay current.

A tool is an action the model calls, while a resource is read-only data the host reads and puts into context.

Roughly, resources are GET and tools are POST.

{
  "uri": "file:///project/schema.sql",
  "name": "Database schema",
  "mimeType": "text/plain"
}

Expose data as a resource when it is stable, addressable content a user may want to attach: a file, a schema, a log. Host support varies, though, and some clients ignore resources. If the model itself must fetch the data, also ship a tool.

Prompts are reusable message templates that a server exposes by name. They are user-controlled, so a person picks one and the model does not invoke it on its own.

A client lists them with prompts/list and fetches one with prompts/get, passing any declared arguments. The server returns a list of messages, each with a role and content, which the host puts into the conversation.

{
  "description": "Review a diff for bugs",
  "messages": [
    { "role": "user", "content": { "type": "text", "text": "Review this diff:\n..." } }
  ]
}

In hosts they appear as explicit user actions, such as slash commands namespaced by server in Claude Code and menu items in Claude Desktop. Message content can embed resources, so one pick pulls in files plus instructions.

MCP messages are JSON-RPC 2.0 messages, UTF-8 JSON objects that carry "jsonrpc": "2.0". The transport only decides how they are framed and delivered.

There are three shapes. A request has an id, a method, and optional params, and expects exactly one reply. A response repeats that id with either result or error, never both. A notification has a method but no id, so nothing is sent back.

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_weather","arguments":{"city":"Oslo"}}}
{"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text","text":"12C, clear"}]}}

An id is a string or an integer, never null, and a sender never reuses one still awaiting its reply. An error holds an integer code, a message, and optional data. Batching was allowed early on, then removed in the 2025-06-18 revision.