No history yet

Protocol Architecture

The MCP Architecture

Standard networking often relies on a two-part, client-server model. The Model Context Protocol (MCP) introduces a third component, creating a host-client-server relationship.

  • Host: This is the AI application, like an AI-powered code editor or desktop assistant. Its job is to manage one or more clients.
  • Client: The client is a component within the host that manages a connection. It acts on the host's behalf.
  • Server: This is a process that provides specific capabilities, like accessing a filesystem, querying a database, or using a software tool. A server exposes these functions to be used by an AI.

The key difference is the host's role as an orchestrator. A single host can manage multiple clients, and each client establishes its own dedicated, one-to-one session with a specific MCP server. This allows an AI application to simultaneously connect to a file system server, a database server, and a code execution server, drawing context from all of them.

MCP follows a client-server architecture where an MCP host — an AI application like Claude Code or Claude Desktop — establishes connections to one or more MCP servers.

All communication within this architecture happens using a standardized data format. MCP uses JSON-RPC 2.0 for framing messages. This means every request and response is a JSON object with a predictable structure. A request specifies a method to be called, any params it needs, and a unique id to track the request. The server's response will reference the same id.

// Client Request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "textDocument/didOpen",
  "params": {
    "uri": "file:///path/to/file.py",
    "languageId": "python",
    "text": "print('Hello, world!')"
  }
}

// Server Response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": null
}

Transport and Handshakes

The JSON-RPC messages need a way to travel between client and server. MCP defines two primary transport layers for this.

For local processes, like a tool running on the same machine as the host, MCP uses standard input/output (stdio). This is a simple and secure method. The host launches the server as a subprocess and communicates with it by writing to its stdin and reading from its stdout. There are no network ports to manage or firewalls to configure, which makes it ideal for local tool integration.

For remote servers running on a different machine, MCP uses HTTP with Server-Sent Events (SSE). This allows a server to push updates to a client over a long-lived HTTP connection, which is essential for real-time collaboration and notifications.

TransportUse CaseSecurity Model
StdioLocal subprocessesProcess isolation by OS
HTTP/SSENetworked servicesStandard web security (TLS, auth)

Regardless of the transport used, an MCP session is always stateful. When a client first connects to a server, they perform an initialization handshake. This is similar in concept to a TCP handshake. The client sends an initialize request announcing its capabilities, like which version of the protocol it understands. The server responds with its own capabilities, such as the list of methods it supports.

This negotiation establishes a persistent session. The server can then remember the context of the interaction, such as which files are open or which database connection is active. This statefulness is crucial for complex tasks that require multiple steps, distinguishing MCP from stateless protocols like standard HTTP where each request is independent.

Quiz Questions 1/5

What are the three core components that define the Model Context Protocol (MCP) architecture?

Quiz Questions 2/5

For communication with a remote server on a different machine, MCP uses HTTP with what specific technology to allow the server to push real-time updates?

With the architecture established, we can explore how these components work together to provide context to an AI.