What is MCP?

The Problem MCP Solves

Before MCP, the pattern was always the same:

1. An AI app (Claude Desktop, Cursor, a custom agent) wants to access some external capability.
2. The app team writes a bespoke adapter — usually REST HTTP calls with hand-rolled JSON schemas.
3. The server team writes a bespoke counterpart that only works for that app.
4. When a second app wants the same capability, the server team writes a second adapter.
5. Six months later, there are 5 adapters, they all slightly disagree on schema formats, and updating the underlying service breaks all of them.

MCP was proposed by Anthropic in November 2024 and immediately adopted by major IDEs (Cursor, Windsurf, Zed) and cloud vendors (Cloudflare, Supabase, MongoDB). The spec is open, the reference implementations are MIT-licensed, and the protocol is LLM-agnostic — a Claude Desktop plugin works equally well as an OpenAI tool server.

The MCP Architecture

MCP defines three distinct roles. These are not the same as "client" and "server" in the REST sense — the naming is more specific:

Notice the layering: the Host and Server never communicate directly. Every message is brokered by the Client. This is intentional — it means the host can connect to dozens of servers without writing transport code for each one, and the server never needs to know which host it's talking to.

In practice, the Client lives inside the same process as the Host (it's typically a library import, not a separate binary). The Server is almost always a separate process — either a local subprocess (stdio) or a remote service (HTTP/SSE).

JSON-RPC 2.0 Wire Format

Here is a complete tool-call round-trip. Every field shown here is part of the official MCP spec:

Step 1 — Client sends a tool_call request

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "search_documents",
    "arguments": {
      "query": "MCP transport options",
      "limit": 5
    }
  }
}

Step 2 — Server sends the result

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Found 3 results for 'MCP transport options':\n1. stdio: local subprocess, lowest latency\n2. HTTP/SSE: remote service, sharable across clients\n3. WebSocket: bidirectional streaming (experimental)"
      }
    ],
    "isError": false
  }
}

Step 3 — If something went wrong

{
  "jsonrpc": "2.0",
  "id": 42,
  "error": {
    "code": -32602,
    "message": "Invalid params: 'limit' must be between 1 and 100"
  }
}

You will almost never write these JSON messages by hand — the SDK handles all serialization. But seeing the wire format demystifies what the SDK is doing, and it's essential for debugging with tools like mcp dev (MCP Inspector).

The Three Primitives

Every MCP server exposes its capabilities using exactly three building blocks. Choosing the right one determines how the LLM interacts with your data or logic.

Tools (Actions)

A Tool is a function the LLM can invoke that may have side effects. The LLM describes what it wants to do, the host routes it through the client to the server, and the server executes it. Use tools for: API calls, database writes, sending messages, running computations, triggering workflows.

Resources (Data)

A Resource is a URI-addressed piece of data the LLM can read into its context. Resources are always read-only — they have no side effects. They can be static (a file) or dynamic (a live database row). Use resources for: files, database records, API snapshots, configuration, documentation. Think of them as "managed context injection."

Prompts (Templates)

A Prompt is a reusable prompt template stored on the server. The host can ask the server to list its prompts, then inject one into the conversation. This moves prompt engineering to the server side, where it can be versioned, tested, and deployed without touching client code. Use prompts for: standardized analysis patterns, domain-specific instructions, workflow openers.

Two Transports

MCP is transport-agnostic at the protocol level, but the spec defines two official transports. Your choice between them determines where your server can run and who can connect to it.

Capability Negotiation Handshake

Before the LLM can call any tool, the client and server must complete a structured handshake. This is how the host discovers what a server can do — and it happens automatically every time a connection is established.

The capabilities object in the server's initialize response tells the client which primitives the server supports — tools, resources, prompts, and optional extensions like sampling and logging. If the server doesn't advertise a capability, the client won't request it.

{
  "protocolVersion": "2024-11-05",
  "serverInfo": {
    "name": "my-document-server",
    "version": "1.0.0"
  },
  "capabilities": {
    "tools": { "listChanged": true },
    "resources": { "subscribe": false, "listChanged": false },
    "prompts": {}
  }
}

The listChanged field tells the client whether the server can notify it when the tool list changes at runtime (useful for servers that load plugins dynamically). subscribe on resources means the client can ask to be notified when a specific resource URI changes.

Real-World Deployments

The pattern across all these deployments is the same: configure the host with the server's location (command + args for stdio, or URL for HTTP/SSE), and the capability negotiation handshake takes care of the rest. The host discovers the tools automatically — there's no manual "register this tool" step on the host side.

Knowledge Check

Five questions to verify you've got the protocol concepts solid before building your first server in MCP01.