MCP: one plug for every tool

A protocol so a tool gets written once instead of once per product. Hosts, clients, servers, JSON-RPC.

Part of the Agents track on lAItest.

Before a shared protocol, every app wrote its own connector to every tool. N apps times M tools.

The point of MCP is to make that N plus M.

Three roles

A host is the application the user is sitting in. Inside the host, a client holds exactly one connection to one server. A server exposes capabilities over that connection. The messages are JSON-RPC 2.0 — an old, boring, well-understood request and response format. The design goal is that a server author never has to know which host is calling.

What a server offers, and what a client offers back

A server exposes three kinds of thing. Resources: data the host can read, like a file or a record. Prompts: reusable templates a user invokes deliberately. Tools: functions the model can call. In the other direction a client can offer Elicitation, letting a server ask the user for input mid-task instead of guessing. Extensions add Tasks for long-running work with durable handles, Skills over MCP, and MCP Apps for inline interactive UI.

A common misconception

Commonly believed: MCP is an Anthropic API, so it only works with Claude.

Actually: It is a transport and schema specification, not a model feature. Any host can implement a client, and a server does not know or care which model is on the other side. Revisions are named by date rather than by version number: the one behind this lesson is dated 2026-07-28, and a newer one may already exist.

When this lesson was last checked

In one sentence

MCP standardises the wiring between an application and its tools, so a tool is written once instead of once per product.