Architecture overview

This overview covers MCP scope, core concepts, and how clients and servers exchange context.

Because MCP SDKs abstract many concerns, most developers find the data layer protocol (primitives and discovery) the most useful part. For implementation details, use your language-specific SDK.

Adapted from the official Architecture overview. Verify against the live docs and specification.

Host → clients → servers: one dedicated connection per client–server pair. Playbook diagram adapted from MCP architecture concepts.

Two transport mechanisms: local stdio and remote Streamable HTTP. Playbook diagram.

Executive summary

MCP separates the host (AI app) from protocol clients and capability servers. The data layer is JSON-RPC (tools, resources, prompts, elicitation). The transport layer is stdio (local) or Streamable HTTP (remote, typically OAuth).

Scope

The Model Context Protocol includes:

• MCP Specification — implementation requirements for clients and servers
• MCP SDKs — language implementations
• MCP development tools — including the MCP Inspector
• Reference server implementations

MCP focuses solely on the protocol for context exchange — it does not dictate how AI applications use LLMs or manage the provided context.

Participants

MCP follows a client–server architecture where an MCP host (for example Claude Code, Claude Desktop, Cursor or VS Code) establishes connections to one or more MCP servers by creating one MCP client per server.

Role	Responsibility
MCP Host	AI application that coordinates one or many MCP clients
MCP Client	Maintains a connection to one MCP server and obtains context for the host
MCP Server	Program that provides context (tools, resources, prompts) to clients

Example: Visual Studio Code acts as an MCP host. Connecting to the Sentry MCP server instantiates one MCP client; connecting to a local filesystem server instantiates another. A remote Streamable HTTP server may serve many clients; a local stdio server typically serves one.

Local servers (stdio) usually run on the same machine. Remote servers (Streamable HTTP) run on a platform — for example the official Sentry MCP server.

Layers

MCP has two layers:

Layer	Role
Data layer	JSON-RPC protocol: capability and version discovery, tools, resources, prompts, notifications
Transport layer	Connection establishment, message framing, authorization

Conceptually the data layer is inner; transport is outer.

Data layer

Built on JSON-RPC 2.0:

• Discovery — server/discover for supported versions, capabilities and identity
• Server features — tools, resources, prompts
• Client features — elicitation (sampling is deprecated as of 2026-07-28)
• Utilities — notifications, progress for long-running work

Transport layer

Transport	When to use
stdio	Local processes on the same machine — high performance, no network
Streamable HTTP	Remote servers — HTTP POST client→server, optional SSE for streaming; bearer tokens / OAuth recommended

The same JSON-RPC message format applies across transports.

Statelessness and discovery

MCP is a stateless protocol. Every request carries protocol version and relevant capabilities in its _meta field so the server can process each request independently. Clients should identify themselves in _meta unless configured not to.

Servers advertise supported versions and capabilities through the mandatory server/discover request. Clients may call it before other requests; discovery responses are typically cacheable.

Example discover request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

Primitives

Server primitives

Primitive	Purpose	Typical methods
Tools	Executable actions (APIs, files, DB)	tools/list, tools/call
Resources	Contextual data (files, records)	resources/list, resources/read
Prompts	Reusable interaction templates	prompts/list, prompts/get

Listings can be dynamic — clients discover then invoke.

Client primitives

Primitive	Purpose	Notes
Elicitation	Server asks the user for structured input	Delivered via Multi Round-Trip Requests
Sampling	Server asks the host LLM for a completion	Deprecated in 2026-07-28
Logging	Server → client log stream	Deprecated — prefer stderr / OpenTelemetry

Optional extensions (for example Tasks) build on the core protocol.

Notifications

Servers can notify clients when capabilities change (for example tools list updates). Change notifications are opt-in: the client opens a long-lived subscriptions/listen stream naming notification types; the server delivers matching notifications on that stream.

Negative cases to design for

• Server does not support the requested protocol version → UnsupportedProtocolVersionError; retry with a mutual version or fail clearly.
• Remote server requires auth the host cannot obtain → fail closed; do not silently strip scopes.
• Tool list changes mid-session → subscribe or re-list before critical calls.
• Stdio child process crashes → host must restart and re-discover; surface errors to the user.

Key takeaways

• One host, many clients, one client per server connection.
• Data layer = JSON-RPC primitives; transport = stdio or Streamable HTTP.
• Prefer server/discover and _meta version/capabilities on every request.
• Sampling and logging client primitives are deprecated in 2026-07-28.

What to do next

Read Understanding MCP servers next, then Understanding MCP clients.