Model Context Protocol

The integration problem

Before a standard existed, connecting a model to an external system meant writing that integration once for one specific host application. The same connector — your issue tracker, your internal database, your file system — got rewritten separately for every application that wanted to use it, and every host invented its own shape for what a “tool” even looked like. MCP is the response: a protocol so that a tool provider is implemented once and any compliant application can connect to it. The value here is almost entirely the network effect of a shared standard, rather than any particular cleverness in the protocol’s design.

JSON-RPC underneath, and how a connection starts

Mechanically, MCP messages are JSON-RPC: a simple request-response format where each message names a method and carries parameters, with every request expecting a matching response correlated by an id. A connection begins with an explicit initialization handshake — the client states which protocol version and which capabilities it supports, the server responds with its own supported version and capabilities, and only once both sides have agreed on what is available does either side start sending the substantive requests that actually do anything. This negotiation step is what lets the protocol evolve over time without breaking older clients talking to newer servers or vice versa, since each side only ever uses features the other side has explicitly confirmed it understands.

The pieces, and who talks to whom

A host is the application the user is actually in — a chat interface, an IDE, a custom agent application. Inside that host, a client maintains a connection to exactly one server, which is a separate process, running either locally or remotely, that exposes some set of capabilities. One host typically runs several clients side by side, each independently connected to a different server — a filesystem server, a database server, a ticketing server — and the host is responsible for aggregating what all of its connected servers offer into one combined view for the model.

The three primitives, and who initiates each one

Tools are model-invoked: functions the model may decide to call during its own reasoning, exactly as covered in tool calling. Resources are application-controlled: data the host itself decides to read and place into context, such as the currently open file in an editor, without the model having requested it. Prompts are user-invoked: templates a person deliberately selects from a menu, such as “summarise this document” as a one-click action, rather than something either the model or the application decided to do on its own. A less commonly discussed fourth primitive, sampling, inverts the usual direction entirely: it lets a server ask the client’s own connected model to generate something on the server’s behalf, useful when a server needs a small piece of model reasoning as part of its own internal logic but has no model access of its own. The distinction between these primitives is about who is in control of each interaction, and it is the part most casual summaries of MCP flatten into “it’s like tool calling,” which misses the host-controlled and user-controlled halves entirely.

What has moved since the reference material was recorded

The transport layer has changed since MCP’s original release. The initial specification paired a simple standard-input/output transport for local servers running on the same machine with a server-sent-events-based transport for remote servers; the remote transport has since been reworked into a more capable streaming design, and authentication for remote servers has moved toward a proper OAuth-based flow rather than the simpler, less standardised schemes some early servers used. The reference workshop in this lesson’s deeper link remains the most complete walkthrough of MCP’s concepts, and is also the material most affected by this change — its transport-specific sections should be read as history, and the current specification consulted directly for anything about to be implemented.

A standard interface does not mean a trusted one

MCP makes connecting easy and does nothing whatsoever about trust. A server can do anything its own host process is capable of doing, and a server you did not write is free to describe its own tools however it likes — including descriptions deliberately crafted to steer the model’s behaviour, which is prompt injection arriving through the tool catalogue rather than through the user’s message. This is sometimes called a confused-deputy problem: the model, acting with whatever privileges the host has granted it, can be manipulated by a malicious server into misusing those privileges on the server’s behalf rather than the user’s. Run third-party MCP servers with exactly the same suspicion applied to any other dependency that has network access and holds your credentials — which is to say, read what it can reach and what it can do before connecting it to anything that matters.