Model Context Protocol (MCP)

MCP defines a standardized JSON-RPC 2.0 message format for providing context to a model. Instead of raw text concatenation, context is passed as a structured payload containing typed resources, prompts, and tool definitions. This allows the model to distinguish between system instructions, user data, and available functions without relying on fragile string templating. The protocol ensures that context is schema-validated before reaching the model, preventing prompt injection and structural errors.

MCP standardizes how tools are described and invoked. Servers expose a list of available tools with JSON Schema-defined input parameters, enabling models to perform function calling with deterministic contracts. When a model decides to use a tool, it generates a structured request that the MCP client routes to the appropriate server. The execution result is returned as a typed content block, closing the loop. This decouples the model's reasoning from side-effect execution, enforcing a read-eval-print loop (REPL) pattern for safe tool use.

MCP introduces Resources and Prompts as first-class primitives. Resources represent live data that can be read by the model, such as file contents or database records, identified by a URI scheme. Prompts are pre-defined, parameterized interaction templates that users can invoke. Both are discovered dynamically by the client, allowing models to browse available context without hardcoded paths. This enables a plug-and-play architecture where new data sources and interaction patterns can be added without modifying the model or client code.

The protocol is designed to be transport-agnostic, operating over any reliable, bidirectional byte stream. The primary implementations use stdio for local subprocess communication and HTTP with Server-Sent Events (SSE) for remote connections. This abstraction allows an MCP client to connect to a local file system server and a remote API server simultaneously, using the same message format. The transport layer handles session negotiation and capability exchange, ensuring both client and server agree on supported features before any context is exchanged.

MCP includes a Sampling feature that allows servers to request completions from the client's language model. This inverts the typical control flow, enabling servers to perform agentic sub-tasks like summarizing a fetched document or generating a follow-up query. The client retains full control, enforcing user permission prompts before any sampling request is fulfilled. This primitive supports multi-hop reasoning patterns where a tool execution requires intermediate model inference without exposing the user's full context to the server.

Upon connection, the client and server perform a capability handshake. Each party declares which protocol features it supports, such as tool calling, resource subscriptions, or prompt listing. This prevents runtime errors from unsupported operations and allows for graceful degradation. The negotiation ensures that a basic client can still interact with an advanced server by only using mutually understood primitives. This design is critical for building an open ecosystem where different vendors' implementations can interoperate reliably.