The Model Context Protocol — A Visual Tour

Topics We'll Cover

• The M×N Problem — Why MCP Exists
• Host / Client / Server — The Three Roles
• JSON-RPC 2.0 — The Wire Alphabet
• The Five Primitives
• Capability Negotiation
• Lifecycle — initialize → operate → shutdown before 2026-07-28
• Lifecycle in 2026-07-28 — No Handshake, Every Request Stands Alone 2026-07-28
• Versioning — The Spec Timeline
• Worked Example — A Full Annotated Exchange before 2026-07-28
• Worked Example in 2026-07-28 — The Same Call, Stateless 2026-07-28
• What to Take Away

The M×N Problem — Why MCP Exists

By late 2024 every serious LLM application had reinvented the same wheel: a bespoke way to plug a model into a database, a filesystem, a ticketing system, an internal API. M AI applications times N data sources is M×N integrations — each one a brittle bag of function-calling JSON, prompt scaffolding, and authentication glue.

Anthropic open-sourced the Model Context Protocol in November 2024 to collapse this to M+N: each application speaks one protocol, each tool ships one server. The marketing line is “USB-C for AI” — a single shaped plug that any compliant host can talk to.

Host / Client / Server — The Three Roles

The MCP architecture has three named participants. Mixing them up is the single most common source of confusion when reading the spec, so it's worth pinning down up front:

JSON-RPC 2.0 — The Wire Alphabet

MCP doesn't invent a new wire format. Every message is a JSON-RPC 2.0 envelope, defined by the 5-page spec from 2010. There are exactly three message shapes:

The Standard Error Codes

JSON-RPC defines reserved codes; MCP layers a small set on top. Anything outside -32768..-32000 is yours to define for tool-level failures.

Source: MCP specification 2026-07-28 — Overview: error codes; Key changes (accessed 2026-10-08).

The Five Primitives

The protocol's surface area is small: three primitives a server can offer, two that a client can offer back. Everything else in MCP is plumbing for these.

Server-side primitives (server → client)

Client-side primitives (client → server)

Source: MCP specification 2026-07-28 — Multi round-trip requests; Deprecated features; Subscriptions (accessed 2026-10-08).

Capability Negotiation

before 2026-07-28 The handshake form is shown first; the callout at the end gives the 2026-07-28 form.

MCP explicitly avoids feature-detection by trial-and-error. At handshake time both sides exchange a capabilities object; nothing else can be assumed. This is what lets a Python server written against the 2024-11-05 spec keep working with a Claude Desktop running 2025-06-18.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools":     { "listChanged": true },
      "resources": { "subscribe":   true,
                       "listChanged": true },
      "prompts":   { "listChanged": true },
      "logging":   {},
      "completions": {}                // argument autocompletion
    },
    "serverInfo": { "name": "my-server", "version": "0.4.1" },
    "instructions": "Use the ‘query’ tool to read the database."
  }
}

Sub-flags worth knowing

Source: MCP specification 2026-07-28 — Overview: _meta; Discovery (accessed 2026-10-08).

Lifecycle — initialize → operate → shutdown before 2026-07-28

Up to and including 2025-11-25 (the “legacy” era in the spec's own terms), every MCP session goes through the same three phases. The protocol is strict about ordering: a request issued in the wrong phase is a protocol error.

Lifecycle in 2026-07-28 — No Handshake, Every Request Stands Alone 2026-07-28

Revision 2026-07-28 removed initialize, notifications/initialized, ping and protocol-level sessions. MCP is now stateless: every request carries its protocol version and client capabilities in _meta, and a server must not infer anything from earlier requests on the same connection.

Source: MCP specification 2026-07-28 — Key changes; Versioning and compatibility; Overview: statelessness; Discovery (accessed 2026-10-08).

Versioning — The Spec Timeline

MCP versions are date-stamped, not semver. The string is literally the date the spec was frozen. Five revisions have shipped; as of October 2026 the current one is 2026-07-28:

Why dates, not semver?

Date-stamping makes the spec trivially comparable (string sort ≡ chronological order) and dodges the semver fight over what counts as “breaking”. The compatibility contract is: servers SHOULD support a window of recent versions; clients negotiate the highest both sides know — through initialize before 2026-07-28, and per request (retry on -32022, or server/discover first) from 2026-07-28.

Source: MCP specification 2026-07-28 — Key changes; Versioning and compatibility; Deprecated features; 2025-11-25 key changes (accessed 2026-10-08).

Worked Example — A Full Annotated Exchange before 2026-07-28

Protocol version 2025-06-18. End-to-end: a Claude Desktop client connects to a tiny weather server, lists tools, calls one, receives a structured result. Every line on the wire is shown.

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
  "protocolVersion":"2025-06-18",
  "capabilities":{
    "sampling":{},
    "elicitation":{},
    "roots":{"listChanged":true}
  },
  "clientInfo":{"name":"claude-desktop","version":"0.13.0"}
}}

{"jsonrpc":"2.0","id":1,"result":{
  "protocolVersion":"2025-06-18",
  "capabilities":{
    "tools":{"listChanged":true},
    "resources":{"subscribe":false,"listChanged":true}
  },
  "serverInfo":{"name":"weather-server","version":"1.2.0"},
  "instructions":"Provide forecasts via the ‘forecast’ tool. Locations must be ISO 3166-2 codes."
}}

{"jsonrpc":"2.0","method":"notifications/initialized"}

// → client
{"jsonrpc":"2.0","id":2,"method":"tools/list"}
// ← server
{"jsonrpc":"2.0","id":2,"result":{
  "tools":[{
    "name":"forecast",
    "title":"Weather Forecast",
    "description":"Return a 24-hour forecast for an ISO 3166-2 region.",
    "inputSchema":{
      "type":"object",
      "properties":{ "region":{"type":"string","pattern":"^[A-Z]{2}-[A-Z0-9]{1,3}$"} },
      "required":["region"]
    },
    "outputSchema":{
      "type":"object",
      "properties":{
        "tempC":{"type":"number"},
        "windKph":{"type":"number"},
        "summary":{"type":"string"}
      },
      "required":["tempC","windKph","summary"]
    },
    "annotations":{ "readOnlyHint":true, "openWorldHint":false }
  }]
}}

// → client
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{
  "name":"forecast",
  "arguments":{"region":"GB-LND"}
}}
// ← server
{"jsonrpc":"2.0","id":3,"result":{
  "content":[{"type":"text","text":"London: 12°C, 14 km/h, light rain easing this evening."}],
  "structuredContent":{"tempC":12.0,"windKph":14.0,"summary":"light rain easing"},
  "isError":false
}}

Worked Example in 2026-07-28 — The Same Call, Stateless 2026-07-28

The same weather tool under 2026-07-28. There is no initialize and no notifications/initialized: the first message can be the tool call itself. Steps 1–3 of the previous slide disappear; what is left is longer per message and shorter overall.

// → client
{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{
  "_meta":{
    "io.modelcontextprotocol/protocolVersion":"2026-07-28",
    "io.modelcontextprotocol/clientInfo":{"name":"example-host","version":"1.0.0"},
    "io.modelcontextprotocol/clientCapabilities":{"elicitation":{}}
  }
}}
// ← server
{"jsonrpc":"2.0","id":1,"result":{
  "resultType":"complete",
  "tools":[{ "name":"forecast", ... }],
  "ttlMs":300000,
  "cacheScope":"public",
  "_meta":{"io.modelcontextprotocol/serverInfo":{"name":"weather-server","version":"1.2.0"}}
}}

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: forecast

{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
  "name":"forecast",
  "arguments":{"region":"GB-LND"},
  "_meta":{
    "io.modelcontextprotocol/protocolVersion":"2026-07-28",
    "io.modelcontextprotocol/clientCapabilities":{"elicitation":{}}
  }
}}
// ← server
{"jsonrpc":"2.0","id":2,"result":{
  "resultType":"complete",
  "content":[{"type":"text","text":"London: 12°C, 14 km/h, light rain easing this evening."}],
  "structuredContent":{"tempC":12.0,"windKph":14.0,"summary":"light rain easing"},
  "isError":false
}}

Source: MCP specification 2026-07-28 — Overview: _meta and resultType; Tools; Caching; Streamable HTTP (accessed 2026-10-08).

What to Take Away

• MCP is JSON-RPC 2.0 with five primitives bolted on. The whole protocol is small enough to keep in your head.
• Three roles, three nouns. Host owns the LLM. Client is one-per-server inside the host. Server is a pure protocol citizen with no model awareness.
• Three message shapes. Request/response carry an id; notifications don't. Tool failures live in result.isError, not in JSON-RPC errors.
• Five primitives. Server exposes tools, resources, prompts. Client exposes sampling, elicitation. Roots and logging are first-class auxiliaries.
• Capabilities are declared, not probed. Absent ≠ empty. Before 2026-07-28: check the initialize result. From 2026-07-28: they ride in every request's _meta, and server/discover lists the server's.
• Versions are date-stamps. Pin to the highest common one. 2026-07-28 is current (stateless: no handshake, no sessions); 2025-06-18, this deck's original target, and 2025-11-25 are the legacy handshake era that dual-era SDKs still speak.