Most introductions to Model Context Protocol (MCP) jump straight to "here is how to build a server." That works for hello-world demos, but it leaves you without a real mental model of what is happening under the hood — which makes debugging painful and design decisions guesswork.

This article slows down and walks through the complete MCP architecture: the layers, the actors, the message lifecycle, and the wire-level details. By the end you will be able to read an MCP trace and know exactly what is happening at every step.

The four-layer mental model #

MCP is best understood as four stacked layers:

The host is the only layer the human sees. Everything below it is plumbing.

Host vs Client — a common point of confusion #

These two terms get used interchangeably, but the spec treats them as distinct:

• A host is the application (Claude Desktop is one host).
• A client is one connection the host opens to one server.

A single host typically opens many clients — one per configured MCP server. So Claude Desktop with three MCP servers configured has three active clients running inside it, each talking to a different server.

┌──────────────────────── Host (Claude Desktop) ────────────────────────┐
│                                                                       │
│   ┌─ Client A ─┐    ┌─ Client B ─┐    ┌─ Client C ─┐                  │
│   │ stdio ⇄    │    │ HTTP ⇄     │    │ stdio ⇄    │                  │
│   └────────────┘    └────────────┘    └────────────┘                  │
│         │                  │                  │                       │
└─────────┼──────────────────┼──────────────────┼───────────────────────┘
          │                  │                  │
     ┌────▼─────┐      ┌─────▼─────┐      ┌─────▼─────┐
     │ Postgres │      │  GitHub   │      │  Slack    │
     │  Server  │      │  Server   │      │  Server   │
     └──────────┘      └───────────┘      └───────────┘

The three transports #

MCP messages are JSON-RPC 2.0 — a tiny, widely-supported protocol. What changes between transports is how those messages are physically moved.

1. stdio #

The server runs as a subprocess of the host. Messages flow over the subprocess's stdin/stdout streams, one JSON object per line.

Use it when:

• The server runs on the same machine as the host
• You want zero network configuration
• The user already has Node, Python, or whatever runtime installed

2. HTTP + SSE (legacy) #

The server is a standalone HTTP service. Client → server requests use plain HTTP POST. Server → client notifications use Server-Sent Events (SSE) on a separate persistent connection.

Use it when:

• The server is remote (different machine, different network)
• Multiple hosts need to connect to the same server

3. Streamable HTTP (the modern remote transport) #

A refinement introduced in a 2025 spec update. Combines request/response and streaming into a single endpoint using chunked HTTP or SSE responses. Simpler to deploy than the dual-channel HTTP+SSE pattern, and the recommended transport for new remote servers.

Anatomy of an MCP session #

Every MCP session goes through the same five phases. Walking through them with real messages is the fastest way to internalize how the protocol works.

Phase 1: Initialize #

The client says "hello, here is what I support." The server responds with what it supports.

Client → Server:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "sampling": {}, "roots": { "listChanged": true } },
    "clientInfo": { "name": "my-host", "version": "1.0.0" }
  }
}

Server → Client:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": {},
      "prompts": {}
    },
    "serverInfo": { "name": "weather-server", "version": "1.0.0" }
  }
}

Note the capability negotiation. Both sides declare what they can do; the rest of the session is constrained by the intersection.

Phase 2: Initialized notification #

The client follows up with a fire-and-forget notification that the handshake is done. No id field — this is a one-way notification, not a request.

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

Phase 3: Discovery #

Now the client asks the server what it offers:

{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

Response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [{
      "name": "get_weather",
      "description": "Get current weather for any city",
      "inputSchema": {
        "type": "object",
        "properties": { "city": { "type": "string" } },
        "required": ["city"]
      }
    }]
  }
}

The host hands these tools to the LLM as available actions. Similar resources/list and prompts/list calls fetch the other two primitives.

Phase 4: Invocation #

The LLM decides to call get_weather. The host forwards the call:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Chennai" }
  }
}

The server executes and returns:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [{ "type": "text", "text": "It is 31°C in Chennai, partly cloudy." }],
    "isError": false
  }
}

The host feeds the text back into the LLM's context. The conversation continues.

Phase 5: Shutdown #

The client closes the transport. For stdio that means closing stdin/stdout. For HTTP that means closing the SSE connection or letting it time out. There is no explicit "goodbye" message in the protocol.

Requests, responses, and notifications #

JSON-RPC 2.0 has three message kinds; MCP uses all three:

Notifications are how servers push events to clients without a request-response roundtrip — used for progress updates, resource changes, and logging.

A minimal echo server in code #

Here is the smallest possible MCP server that exposes one tool. It captures everything the architecture demands in under 30 lines:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const server = new McpServer({
  name: 'echo-server',
  version: '1.0.0',
});

server.tool(
  'echo',
  'Echoes back whatever message you send',
  { message: z.string().describe('Anything you want echoed back') },
  async ({ message }) => ({
    content: [{ type: 'text', text: `You said: ${message}` }],
  })
);

await server.connect(new StdioServerTransport());

The SDK handles the initialize handshake, capability negotiation, tools/list response, and tools/call dispatch automatically. You provide the business logic; the SDK provides the wire protocol.

Tools, resources, prompts — the three capabilities #

A server can expose any combination of three primitives:

• Tools — actions the LLM can invoke (tools/list, tools/call)
• Resources — data the LLM can read (resources/list, resources/read, resources/subscribe)
• Prompts — pre-baked templates the user can invoke (prompts/list, prompts/get)

A server that only offers tools is the most common. A server that also offers resources (e.g., a file system or database server) lets the host attach context to a conversation. A server that offers prompts gives users one-click access to standardized workflows.

Beyond the basics #

A few advanced architectural features that are useful to know exist:

• Sampling — a server can ask the client's LLM to generate text on its behalf (reverse direction). Powerful for agentic patterns.
• Roots — the client tells the server which filesystem paths it should consider "in scope."
• Cancellation — long-running calls can be cancelled via notifications/cancelled.
• Progress — long-running calls can emit notifications/progress so the host can show a spinner.

You rarely need these on day one, but they are why MCP feels mature compared to ad-hoc tool integrations.

Conclusion #

MCP is conceptually small: four layers, three transports, three primitives, and a JSON-RPC 2.0 message format. The complexity comes from the interactions between them — capability negotiation, progress streaming, multi-server hosts, sampling — but the foundation is approachable.

If you understand the initialize → list → call → shutdown cycle, you understand MCP. Everything else is detail you can pick up as you need it.

Try it yourself #

After connecting your weather MCP server to Claude Desktop, here is what a discovery-and-invoke conversation looks like:

What just happened underneath: the client sent initialize, the server responded with capabilities, the client called tools/list and received the get_weather schema, the LLM emitted tools/call with { city: Chennai }, and the server fetched the upstream weather API and returned a text result. Five JSON-RPC messages total.