#Architecture

This chapter covers MCP participants, local versus remote deployment, and how the data and transport layers stack. Prefer the official architecture overview when details diverge.

#Three participants

MCP is a client–server architecture. A Host is the AI application the user talks to. It creates one Client per Server. Each Client keeps a dedicated connection and hands context back to the Host.

“Server” means the program that serves context, wherever it runs.

graph TB
    subgraph "MCP Host (AI application)"
        Client1["MCP Client 1"]
        Client2["MCP Client 2"]
        Client3["MCP Client 3"]
        Client4["MCP Client 4"]
    end

    ServerA["Server A · local<br/>e.g. Filesystem"]
    ServerB["Server B · local<br/>e.g. Database"]
    ServerC["Server C · remote<br/>e.g. Sentry"]

    Client1 ---|"Dedicated<br/>connection"| ServerA
    Client2 ---|"Dedicated<br/>connection"| ServerB
    Client3 ---|"Dedicated<br/>connection"| ServerC
    Client4 ---|"Dedicated<br/>connection"| ServerC

One remote server can serve many clients (even many hosts). A local stdio server usually serves only the client that launched it.

#Local vs remote

When Claude Desktop launches the filesystem server, that process is on the same machine—a local MCP server. The official Sentry server runs on Sentry’s platform over Streamable HTTP—a remote MCP server.

Rule of thumb: the capability must touch this disk or an intranet, and only you use it → stdio. The capability is shared with a team or public hosts → Streamable HTTP.

#Two layers

MCP has two layers. Conceptually the data layer is inside and the transport layer is outside:

┌──────────────────────────────────────────────┐
│  Transport: Stdio / Streamable HTTP / (legacy SSE) │
│  Connect, frame, authorize, cancel           │
├──────────────────────────────────────────────┤
│  Data: JSON-RPC 2.0                          │
│  Discovery, tools / resources / prompts, notifications │
└──────────────────────────────────────────────┘

The data layer defines message shape and meaning:

• Discovery: server/discover reports supported versions, capabilities, and identity
• Server features: Tools (actions), Resources (data), Prompts (templates)
• Client features: elicitation (ask the user for more input). Sampling is deprecated as of 2026-07-28
• Utilities: progress, cancellation, optional subscription notifications

The transport layer only moves bytes. The same JSON-RPC messages run on stdio or HTTP; see Transports.

#Statelessness and discovery

The current spec makes the protocol core stateless: every request carries protocol version, client identity, and capabilities in _meta, so a server can handle that request alone. Send server/discover when you want a catalog first. It is not required before every call, but every server must implement it.

For operators, a remote server can sit behind a plain round-robin load balancer; sticky Mcp-Session-Id routing is no longer the protocol default. If your app still needs state across calls, return an explicit handle from a tool and have the model pass it back—clearer than hiding session state in the transport.

Older clients may still speak the initialize handshake. Official SDKs negotiate per connection. Write new servers against the current API.

#What happens inside a host?

1. The user configures servers (a command line or a URL)
2. The host creates one client per server
3. The client discovers tools, resources, and prompts and registers them
4. When the model chooses a tool, the host sends tools/call on that client
5. Results return to the conversation; the UI should let users approve dangerous calls

MCP does not decide how the model picks a tool in step 4. That is the host’s agent loop.

#Next

• Primitives
• Transports
• Connect Clients