Volume VI · Reaching Outside the Model

From M×N to M+N

Lecture 13 established the JSON contract one application makes with one model: a schema out, a structured call back, a result appended. Nothing in that contract says anything about what happens when there are five applications and eight tools and data sources each of those applications wants to reach. Left alone, that is forty bespoke integrations. MCP is the decision to write the contract once, instead of forty times.

The problem before the protocol

Take the JSON contract from Lecture 13 as a given — every AI application already knows how to declare a tool and handle a tool_use/tool_result round trip. The problem MCP (Model Context Protocol, an open specification published by Anthropic at modelcontextprotocol.io) exists to solve is not that contract itself, but what happens before it: without a standard, each AI application still needs its own bespoke integration code for every data source or tool it wants to reach, because nothing forces those integrations to look the same from one application to the next. Five applications wanting to reach eight tools and data sources, each pairing built by hand, is forty separate integrations — M applications times N tools, an M×N problem that grows multiplicatively as either side grows.

MCP's answer is to standardize the interface itself, so that any MCP-speaking application (a "host") can talk to any MCP-speaking tool or data source (a "server") without a bespoke integration for that specific pairing. Each side now only has to implement the protocol once: five applications implementing the client side once each, eight tools implementing the server side once each, is thirteen implementations total — M+N instead of M×N — and every new application or every new tool added afterward costs one more implementation, not one more per existing partner on the other side.

Host, client, server

MCP's architecture is client-server, with a specific one-to-many arrangement on the application side. An MCP host — Claude Code, Claude Desktop, or an editor like VS Code — is the application the user actually interacts with. The host instantiates one MCP client for every MCP server it connects to, and each client maintains a dedicated one-to-one connection to its own server; a host talking to three servers runs three clients side by side, never one client multiplexed across all three. An MCP server is the thing on the other end exposing tools, data, or interaction templates — a database, a filesystem, a SaaS product, a local script.

Two layers: what is said, and how it travels

MCP separates a data layer from a transport layer. The data layer is a JSON-RPC 2.0-based protocol covering lifecycle management — an initialize handshake in which client and server negotiate protocol version and declare their capabilities before anything else happens — plus the primitives each side exposes. Servers expose tools (executable functions, the same shape as Lecture 13's tool-use contract), resources (contextual data sources the client can read), and prompts (reusable interaction templates). Clients, symmetrically, expose primitives back to the server: sampling lets a server ask the client's own LLM to generate a completion, elicitation lets a server ask the human user for more input, and logging carries diagnostic messages. Notifications such as notifications/tools/list_changed let a server tell a client its available tools changed, without the client having to poll for it.

The transport layer is how those JSON-RPC messages actually move. stdio is a local process-to-process pipe — no network overhead, and typically one client per local server, the shape most command-line MCP servers use. Streamable HTTP is HTTP POST with an optional Server-Sent Events stream layered on top, which supports a remote server serving multiple clients at once and recommends OAuth for authentication. The data layer does not care which transport carried it — the same tools/list and tools/call messages work over either one.