What Is MCP? The Model Context Protocol Explained

Model APIs have supported tool use (“function calling”) for years: the application describes some functions, the model asks for one to be called, and the application runs it and returns the result. What tool use does not define is where those functions come from. Every chat app, IDE and agent framework wrote its own GitHub integration, its own database connector and its own file tools, so M applications and N services meant roughly M × N integrations, each with its own bugs.

MCP moves each integration into a reusable server that any compliant host can connect to, which turns M × N into M + N. The specification names the Language Server Protocol as its inspiration: LSP lets any editor use any language's tooling, and MCP lets any AI application use any server's tools and data. The protocol is not tied to a model. The host reads a server's tool list and translates it into whatever tool-use format its own model API expects.

The three roles are easy to blur, but the security model depends on keeping them apart.

• Host. The application the user runs: a desktop chat client, an IDE, an agent runtime. It owns the model and the conversation, creates the clients, enforces consent and decides what each server gets to see.
• Client. A connector inside the host with a one-to-one relationship to a single server. It attaches the protocol version and its capabilities to every request and routes messages in both directions.
• Server. A program that offers capabilities, either as a local process or as a remote service. It can be very small: a few tools wrapped around an existing API.

One of the specification's design principles is that servers “should not be able to read the whole conversation, nor ‘see into’ other servers”. A server receives only what the host sends it, usually the arguments of a tool call. The flip side is that every trust decision sits in the host. A server cannot tell whether a call reflects what the user wanted or an instruction the model picked up from a web page it just read. That is why MCP security is mostly about hosts, approvals and what each server is allowed to touch.

Servers expose three kinds of feature. They differ mainly in who decides when they are used.

A tool definition has a name, a description, an inputSchema (JSON Schema, 2020-12 by default), an optional outputSchema and optional annotations such as hints that a tool is read-only or destructive. The specification is blunt about those hints: clients must treat annotations as untrusted unless they come from a trusted server. A tool result holds content blocks (text, images, audio, links to resources, embedded resources) and, when the tool declares an output schema, a machine-readable structuredContent value.

What clients offer servers

Sometimes a server needs something back from the client in the middle of a request. The active feature for this is elicitation: the server asks the user for input, either through a form with a flat JSON schema or by sending the user to a URL. Form mode must not be used to collect passwords, API keys or payment details; those go through URL mode so they never pass through the client. Two older client features, sampling (the server asks the host's model for a completion) and roots (the client tells the server which directories it may work in), still function but were deprecated in 2026-07-28. The specification suggests passing directories as tool parameters or configuration instead of roots, and calling a model provider directly instead of sampling.

The mechanism changed too. In 2026-07-28 a server never sends its own request to the client. It answers the original request with an InputRequiredResult listing what it needs, and the client retries the original request with the answers attached (the specification calls this multi round-trip requests).

MCP uses plain JSON-RPC 2.0: requests carry an id, a method and params; responses carry the same id and either a result or an error; notifications have no id and get no reply. Here is a complete tool call under the 2026-07-28 revision, using a real tool from a file-transfer server (the response is abridged):

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "srift_quick_share",
    "arguments": { "filePath": "/home/ana/build/report.pdf", "encrypt": true },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-host", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "resultType": "complete",
    "content": [{ "type": "text", "text": "Download link: https://srift.app/d/<token>#k=<key>" }],
    "structuredContent": {
      "downloadUrl": "https://srift.app/d/<token>#k=<key>",
      "fileName": "report.pdf",
      "encrypted": true
    },
    "isError": false
  }
}

Versions and capabilities, per request

Every 2026-07-28 request carries its protocol version and the client's capabilities in _meta. Servers must implement server/discover, which returns the versions, capabilities and identity they support, and a request for an unsupported version fails with UnsupportedProtocolVersionError. Revisions up to 2025-11-25 worked differently: a connection began with an initialize request and an initialized notification that fixed the version and capabilities once, and an HTTP server could assign an Mcp-Session-Id that the client echoed on every request. Many deployed clients and servers still speak that era, so the specification describes how a client probes for a modern server and falls back to initialize when it finds an old one.

Without a protocol session, a server that needs state across calls (a shopping cart, an open transaction, a file-transfer room) returns an explicit handle from one tool and accepts it as an argument on the next.

Two kinds of error

A protocol error (unknown tool, malformed request) is a JSON-RPC error. A tool execution error (the API call failed, a date was in the past) is a normal result with "isError": true and a readable explanation, so the model can correct its arguments and try again. Servers that report every failure as a protocol error deprive the model of that chance.

The protocol means the same thing on every transport; a transport only defines framing, delivery and cancellation. Two are standard:

• stdio. The client launches the server as a subprocess and exchanges newline-delimited JSON-RPC messages over its stdin and stdout. The server may log to stderr but must not write anything to stdout that is not an MCP message. The client shuts the server down by closing its stdin.
• Streamable HTTP. The server exposes one endpoint, and every client message is its own HTTP POST. The server answers with a single JSON object or with a Server-Sent Events stream scoped to that one request, so progress notifications can arrive before the final result. Requests also carry MCP-Protocol-Version, Mcp-Method and Mcp-Name headers so load balancers and gateways can route without parsing the body. Servers must validate the Origin header, and local servers should bind to 127.0.0.1 only.

The older HTTP+SSE transport from 2024-11-05 is deprecated. Authorization is optional in the specification and applies to HTTP transports: the MCP server acts as an OAuth 2.1 resource server, publishes Protected Resource Metadata (RFC 9728) so clients can find its authorization server, and must only accept tokens issued for itself. Clients bind each token to the server with the resource parameter from RFC 8707. A stdio server skips all of this and takes credentials from its environment. Local vs remote MCP servers compares the two transports in depth.

A concrete server makes the primitives easier to picture. SRIFT, an open-source end-to-end encrypted transfer tool, ships an MCP server in two forms: a local one started with srift mcp, which can read files on the machine, and a hosted endpoint at https://srift.app/mcp, which has no filesystem to read.

Note what does not travel over MCP: the file. A JSON-RPC result is text, so returning a file means base64, which inflates it by a third and pushes the whole thing through the host and possibly into the model's context. The tool instead returns a link, and the bytes stream from the machine to whoever opens it. That pattern (MCP for control, a separate channel for data) suits any server that handles large objects; how AI coding agents deliver files compares the options.

Setup instructions for Claude, Cursor and other clients are on the MCP file transfer page.

• Not an agent framework. MCP has no planning loop, memory or model. It defines how a host discovers and calls capabilities; deciding what to call is the host's and the model's job.
• Not a security boundary. The specification states that MCP cannot enforce its security principles at the protocol level, and that tools represent arbitrary code execution. Consent, sandboxing and access control are left to hosts and servers.
• Not an agent-to-agent protocol. MCP connects an application to the capabilities it uses; it is not designed for two autonomous agents to find and message each other. That is a different problem, covered in agent-to-agent file transfer.
• Not a bulk data channel. Results are JSON. Anything large is better returned as a link or a resource reference than inlined.
• Not tied to one vendor. The specification is public, the SDKs are open source, and clients from many vendors implement it.