Chapter 7: MCP Fundamentals: The Model Context Protocol

Why MCP Exists

Building a hyper-personalized assistant means connecting a language model to the messy, heterogeneous world where a user's data actually lives: their calendar, email, a CRM, a document store, an internal database, a payments API. Before MCP, every one of those connections was a bespoke engineering project. Anthropic introduced the Model Context Protocol as an open standard on November 25, 2024, describing it as an open standard for "secure, two-way connections between data sources and AI-powered tools," motivated by the fact that even capable models were "trapped behind information silos and legacy systems."

The N×M Integration Problem

Imagine N AI applications (chat assistants, IDEs, agents) and M tools or data sources (Slack, Google Drive, GitHub, a Postgres database). Wire them directly and each application needs a custom connector for each data source — roughly N×M bespoke integrations. Add one new tool and you build N new connectors; add one new application and you build M new connectors. With MCP, each side implements the protocol once and any compliant client can talk to any compliant server.

Suppose you have 4 assistants and 5 data sources:

Figure 7.1: Point-to-point integrations (N×M) versus a shared MCP protocol (N+M).

MCP as a Universal Connector

Before USB-C, every device had its own proprietary cable. USB-C replaced that with a single port any peripheral could use. MCP does the same for software: one universal interface so any compliant model or app can connect to any compliant data source or service. A concrete benefit falls straight out: the ecosystem becomes shareable. The project ships not just a specification but language SDKs, tooling such as the MCP Inspector, and pre-built reference servers for Google Drive, Slack, and GitHub. Crucially the standard did not stay proprietary — cross-vendor adoption is exactly what makes the USB-C analogy hold, because a connector standard is only useful if everyone plugs into it.

Relationship to Function Calling

Function calling is the model-facing mechanism: presented with function definitions, the LLM decides which to call and produces a structured argument object — a capability of the model and its API. MCP is the integration-facing standard: how an application discovers what an external system offers, negotiates capabilities, and invokes them over a common wire format. MCP "focuses solely on the protocol for context exchange — it does not dictate how AI applications use their LLMs."

In practice, an MCP server exposes tools; the model, through function calling, decides to invoke one; and MCP carries the invocation to the server and the result back. Function calling is how the model reaches; MCP standardizes what it reaches into.

Client and Server Roles

MCP's architecture is deliberately simple, but three words — host, client, server — sound interchangeable and are not. A host application establishes connections to one or more servers, creating one client per server.

Host, Client, and Server

Think of the host as a restaurant's front-of-house manager, each client as a dedicated waiter assigned to exactly one kitchen station, and each server as a specialized station (the grill, the pastry counter). The manager coordinates the experience and decides what the guest may order; each waiter talks to only one station and never lets stations talk directly to each other or to the guest. The one-client-per-server (1:1) rule is a defining structural feature: a host connected to multiple servers runs multiple clients in parallel, which preserves security boundaries.

MCP is defined in two layers: a data layer (the JSON-RPC 2.0 protocol defining message structure, lifecycle, and the core primitives) and a transport layer (STDIO for local processes; Streamable HTTP with optional Server-Sent Events for remote, supporting bearer tokens, API keys, and recommending OAuth). The transport layer abstracts communication so the same JSON-RPC message format works across every transport.

Figure 7.2: The MCP host-client-server architecture with one client bound 1:1 to each server.

Capability Negotiation and Initialization

MCP is a stateful protocol. The first thing a client and server do is negotiate the capabilities they both support, through a three-step handshake:

1. initialize request (client → server) — carries protocolVersion (e.g., "2025-06-18"), capabilities (e.g., sampling, elicitation), and clientInfo.
2. initialize response (server → client) — returns the selected protocolVersion, the server's capabilities (e.g., "tools": {"listChanged": true}, "resources": {}), and serverInfo.
3. notifications/initialized (client → server) — a notification (no id) acknowledging readiness. The session is now live.

Figure 7.3: The three-step initialize capability-negotiation handshake.

Reading a real exchange top to bottom: both sides agree on version 2025-06-18; the server advertises tools (and will notify on tool-list changes) and resources, but says nothing about prompts — so the client knows not to attempt prompt operations. The initialization exchange serves three critical purposes:

Who Owns What

Because the host is the security boundary, a compromised or misbehaving server cannot reach into another server or silently exfiltrate context — the host mediates every interaction.

MCP Primitives

Anthropic's documentation calls the primitives "the most important concept within MCP." They define what clients and servers can offer each other. MCP defines three core primitives that servers expose: tools, resources, and prompts.

Tools, Resources, and Prompts

Tools are "executable functions that AI applications can invoke to perform actions" — a tool takes JSON Schema arguments (inputSchema) and does something. They are model-controlled and, because they have side effects, most demand careful permissioning by the host (e.g., create_calendar_event).

Resources are "data sources that provide contextual information" — read-only content the application pulls in. They are application-controlled. A tool is a verb (do something); a resource is a noun (here is some data), e.g., the contents of the user's latest invoice.

Prompts are "reusable templates that help structure interactions with language models." They are user-controlled — a human explicitly selects one, typically as a slash command — and often act as the "handoff artifact" packaging an expert's workflow.

The Control Model

The three primitives are best understood by who decides when they get used — three distinct control planes:

A concrete illustration ties all three together: a server providing context about a database can expose tools for querying it, a resource containing the schema, and a prompt with few-shot examples. The model calls the tools, the app supplies the schema, and the user invokes the prompt.

Prompts and Sampling — Client-Side Primitives

For completeness, MCP also defines primitives that clients expose so servers can build richer interactions:

• Sampling (sampling/createMessage) lets a server request an LLM completion from the host — so server authors can be "AI-powered" without embedding an LLM SDK, staying model-independent.
• Elicitation (elicitation/create) lets a server request additional information or confirmation from the user.
• Logging lets a server send log messages to the client for debugging and monitoring.

Sampling inverts the usual direction of control: instead of the model reaching out to the server, the server reaches back to borrow the host's model.

The Message Lifecycle

Everything in MCP travels as JSON-RPC 2.0 messages, and every primitive is reached through a small, predictable set of methods.

JSON-RPC Message Flow

Every JSON-RPC message begins with "jsonrpc": "2.0". The id field pairs a response to its originating request; its absence is precisely what marks a message as a fire-and-forget notification (e.g., notifications/initialized, notifications/tools/list_changed).

Discovery and Listing

After the handshake, a client discovers what a server offers via the */list methods. Crucially, listings are dynamic and can change over time. A server whose tools depend on runtime state (say, which repository is open) can add or remove tools mid-session. This is where the listChanged capability earns its keep: a server that declared "tools": {"listChanged": true} can push a notifications/tools/list_changed message, prompting the client to call tools/list again. Only servers that declared this capability send such notifications — which is exactly why capability negotiation happens first.

Invocation and Results

Note the asymmetry: only tools are executed via tools/call. Resources and prompts are retrieved — nothing is done in the world. This maps precisely back to the control model: the executable primitive (tools) is the one the model drives, and it is the only one with a call method.

Figure 7.4: The full JSON-RPC message lifecycle for a database assistant, from initialization to dynamic updates.

Beyond these core methods, MCP defines cross-cutting utilities. Notifications enable the real-time updates just described, and experimental Tasks provide durable execution wrappers for long-running requests that cannot complete in a single quick round trip.