The Model Context Protocol (MCP) is an open standard for connecting AI applications to data sources and tools. Think of it as one shared connector instead of a custom integration for every pair of systems.

Without MCP, each AI application needs separate code for every service it uses. For example, three AI applications connecting to four services may require twelve custom integrations. Each one needs its own tool definitions, authorization, and glue code.

MCP changes that pattern. Each application implements one client, and each external system gets one server. Compliant clients and servers can then connect without a new pair-specific integration.

The protocol standardizes four areas:

• Discovery of tools, resources, and prompts.
• Standard request and response messages.
• Transport options for local and remote connections.
• Session setup, capability negotiation, and notifications.

MCP defines three roles.

The host is the AI application the user actually interacts with: Claude Desktop, Claude Code, an IDE like Cursor, or your own agent. The host owns the model loop, the UI, and the security policy. It decides which servers to connect, gathers user consent, filters which tools reach the model, and mediates approvals.

A client is the protocol connector object the host creates to talk to one server. Each client maintains a 1:1 stateful session with exactly one server, handling initialization, capability negotiation, request/response correlation, and notifications. A host that connects to five servers runs five clients.

A server is the program that exposes capabilities: tools it can execute, resources it can read, and prompt templates it offers.

A useful mental model:

Host (Claude Desktop)
  Client 1  <->  Server A (filesystem, stdio)
  Client 2  <->  Server B (GitHub, Streamable HTTP)

The host receives a tool-use request from the model and routes it through the right client. It gets the result and inserts it back into the model's context.

MCP servers expose three kinds of capability, distinguished by who decides when they are used.

Tools are model-controlled. They are executable functions (query a database, send a message, create a ticket) that the language model chooses to invoke during generation. Invocation is subject to host approval. Tools are the action surface and carry the most risk, so hosts typically require user confirmation for consequential calls.

Resources are application-controlled. They are read-only data items with an address, such as a file, schema, or log stream. The host decides when to fetch and attach them.

Prompts are user-controlled. They are reusable, parameterized message templates the server publishes, which hosts typically surface as slash commands or menu items.

For example, a code review server might expose a review_pr prompt that the user selects. The application could attach a git://repo/diff resource, while the model could call a post_review_comment tool after approval.

A tool is a callable function a server exposes to the model. Each tool definition has a name, a human-and-model-readable description, an inputSchema (JSON Schema describing the arguments), and optionally an outputSchema, a title, and behavioral annotations.

Discovery and execution use two protocol methods. The client calls tools/list to get definitions and tools/call to execute one:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Berlin" }
  }
}

The result contains a content array with text, image, audio, or resource blocks. It may also include structuredContent when the tool declares an output schema, plus an isError flag for failures. The host displays the result or returns it to the model.

Two details matter in practice. First, the model chooses tools based almost entirely on names and descriptions, so those are effectively prompt engineering. Second, if the server declares the listChanged capability it can push a notifications/tools/list_changed notification, after which the client re-fetches the list. Tool sets are dynamic, not fixed at startup.

Resources are read-only context, not actions. Each resource has a uniform resource identifier (URI), such as file:///home/user/report.pdf, plus metadata like name, description, and mimeType.

The key differences from tools: resources are meant to have no side effects, they are addressed by identity rather than invoked with arbitrary arguments. They are application-controlled: the host or user decides which ones to load into context, rather than the model calling them mid-generation.

Servers can let clients subscribe to an address and send notifications/resources/updated when it changes. This suits live logs or documents.

Expose data as a resource when it is naturally "a thing you attach": files, schemas, configuration, documentation pages, records with stable identity.

One practical compatibility issue: some hosts historically had stronger tool support than resource support. Server authors therefore sometimes add a companion tool that reads the same data to maximize compatibility.

Prompts are server-defined, reusable message templates that users explicitly invoke. A prompt definition includes a name, title, description, and a list of typed arguments. Clients discover them via prompts/list and expand one via prompts/get, passing argument values; the server returns fully-formed messages (role plus content blocks) ready to insert into the conversation.

Prompt content can embed resources, so a template can pull in live data at expansion time.

{
  "name": "review_code",
  "description": "Review code for quality and security issues",
  "arguments": [
    { "name": "language", "description": "Programming language", "required": true }
  ]
}

Because users choose prompts, hosts show them as commands, menu items, or buttons.

The value is that the server author, who knows the domain, can encode the best way to ask. That means the right framing, the right context to include, and the right output format.

Instead of every user hand-writing "summarize this incident and check the runbook," the incident-management server ships an analyze_incident prompt that does it consistently. Prompts also support argument autocompletion through the completion/complete request, so hosts can offer suggestions while the user fills in parameters.

MCP uses JSON-RPC (JSON Remote Procedure Call) 2.0, a request-and-response message standard, encoded as Unicode text. There are three message shapes.

A request carries jsonrpc: "2.0", a unique id (string or number, never null), a method, and optional params. A response echoes the id and contains exactly one of result or error, where error has a numeric code, a message, and optional data.

A notification has a method and params but no id, and must never be answered.

{ "jsonrpc": "2.0", "id": 1, "method": "resources/read",
  "params": { "uri": "file:///notes.md" } }

{ "jsonrpc": "2.0", "id": 1, "result": {
  "contents": [{ "uri": "file:///notes.md", "mimeType": "text/markdown", "text": "..." }] } }

MCP layers its own method namespace on top: initialize, tools/list, tools/call, resources/read, prompts/get, sampling/createMessage, notifications/..., and so on. Both sides can send requests, which is unusual and important: servers can call back into clients (sampling, roots, elicitation). The protocol is therefore bidirectional and sessions are stateful.

Requests may be answered out of order; the id does the correlation.