Lesson 2 of 3 in Tool Design & MCP Integration

4.2 · MCP architecture

The Model Context Protocol standardizes how AI applications connect to external systems. This lesson covers the host/client/server architecture, the three primitives (tools, resources, prompts), the transports that carry the JSON-RPC messages, and the handshake that establishes what each side can do.

Host, client, server

Host is the application the user interacts with (Claude Desktop, Claude Code, a custom app). Client is a connector inside the host that speaks the MCP protocol. Server is the external process that exposes tools, resources, and prompts. One host can host many clients, each connected to a different server.

Claude Code (host) ↔ 3 clients ↔ Postgres MCP server, Jira MCP server, Filesystem MCP server

The three primitives

Tools: functions the model can call. Resources: data the host can fetch (files, URL contents, query results). Prompts: reusable prompt templates the user can invoke. Most servers focus on tools, but resources and prompts are equally valid.

Protocol & transports

MCP messages are JSON-RPC. Transports: stdio (for local subprocesses), streamable HTTP (for remote servers, the current spec preference), or SSE (older HTTP transport). The protocol is versioned; current spec is 2025-06-18.

Good to know — SSE is being deprecated in favor of streamable HTTP for new remote deployments.

// Client requests the list of tools
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Server responds
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "query_orders",
        "description": "Query orders by date range",
        "inputSchema": { ... }
      }
    ]
  }
}

// Client invokes a tool
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "query_orders",
    "arguments": {"start": "2026-01-01"}
  }
}

Handshake and capabilities

On connection, client and server negotiate capabilities: what primitives they support, what versions, what auth. The server declares tools/resources/prompts; the client declares what it can consume. Both sides know the surface before real work starts.

Takeaways

Host ↔ client ↔ server is the architecture
Tools, resources, prompts are the three primitives
JSON-RPC over stdio (local) or streamable HTTP (remote)
Capabilities negotiated at handshake

Exam traps

Adding more instructions when a few-shot example would fix it

For consistency issues, 2–4 examples covering the boundary cases outperform any amount of rule text.

Confusing extended thinking with CoT prompting

Extended thinking is a built-in capability with its own token budget. CoT via <thinking> tags is a prompt technique. Both are valid; they're different levers.

Using CoT when latency and cost matter more than reasoning depth

CoT costs tokens. On simple tasks, it's overhead. Use it where the reasoning depth matters.

Practice scenario

A prompt classifies support tickets into 6 categories. Accuracy is 78%. Which single intervention is most likely to raise accuracy the most?

← Previous Next →