MCP Architecture Explained

A technical deep dive into the Model Context Protocol architecture — hosts, clients, servers, protocol flow, message types, and capability negotiation.

title: "MCP Architecture Explained" description: "A technical deep dive into the Model Context Protocol architecture — hosts, clients, servers, protocol flow, message types, and capability negotiation." order: 2 keywords:

• MCP architecture
• MCP client server
• MCP protocol flow
• MCP hosts
• MCP capability negotiation
• JSON-RPC MCP
• MCP message types
• model context protocol architecture date: "2026-04-01"

Architecture Overview

The Model Context Protocol architecture consists of three distinct layers that work together to enable secure, structured communication between AI applications and external data sources.

Understanding these layers is essential for building robust MCP integrations, whether you are building a server with mcp-framework, the official @modelcontextprotocol/sdk, or implementing a custom client.

The Three Roles

Host

The host is the outermost layer — the application the user directly interacts with. Examples include Claude Desktop, Cursor, VS Code with Copilot, or any custom AI-powered application.

The host is responsible for:

• Creating and managing client instances — A single host can run multiple clients, each connecting to a different server.
• Enforcing security policies — The host decides which servers to trust, what permissions to grant, and when to prompt the user for consent.
• Routing messages — The host coordinates between the AI model and the various connected MCP clients.
• Managing the AI model interaction — The host feeds tool results and resource data back to the AI model as context.

Client

The MCP client is the protocol-level component that maintains a stateful session with a single server. Each client handles:

• Protocol negotiation — Performing the initialize handshake with the server to agree on supported capabilities and protocol version.
• Message serialization — Encoding and decoding JSON-RPC 2.0 messages.
• Request routing — Sending requests to the server and routing responses back to the host.
• Capability tracking — Keeping track of which features the connected server supports.

A client maintains a one-to-one relationship with a server. If a host needs to connect to five different MCP servers, it creates five separate client instances.

Server

The MCP server is the component that exposes functionality and data to clients. A server:

• Declares capabilities during initialization, telling the client which primitives it supports (tools, resources, prompts).
• Responds to discovery requests — listing available tools, resources, and prompt templates.
• Executes tool calls when requested by the client.
• Provides resource data when the client reads a resource URI.
• Returns prompt templates for structured interactions.

Servers can be built using high-level frameworks like mcp-framework, which provides class-based architecture and automatic tool discovery, or using the lower-level @modelcontextprotocol/sdk for maximum control.

Protocol Flow

1. Initialization Phase

Every MCP session begins with a handshake:

Client → Server:  initialize (protocol version, client capabilities)
Server → Client:  initialize response (protocol version, server capabilities)
Client → Server:  initialized (notification)

During initialization, the client and server exchange their supported protocol version and capabilities. This ensures both sides agree on what features are available for the session.

2. Discovery Phase

After initialization, the client typically discovers what the server offers:

Client → Server:  tools/list
Server → Client:  list of available tools with schemas

Client → Server:  resources/list
Server → Client:  list of available resources

Client → Server:  prompts/list
Server → Client:  list of available prompt templates

Each tool includes a JSON Schema definition describing its input parameters. This schema allows AI models to understand what arguments a tool expects and how to invoke it correctly.

3. Operation Phase

Once discovery is complete, the client can invoke tools, read resources, and use prompts:

Client → Server:  tools/call (tool name, arguments)
Server → Client:  tool result (content)

Client → Server:  resources/read (resource URI)
Server → Client:  resource content

Client → Server:  prompts/get (prompt name, arguments)
Server → Client:  prompt messages

4. Shutdown Phase

Sessions end with a clean shutdown:

Client → Server:  close notification
(transport connection closed)

Message Types

MCP defines three categories of JSON-RPC 2.0 messages:

Requests

Requests are messages that expect a response. They include a unique id field that the response must reference. Examples include tools/call, resources/read, and prompts/get.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT * FROM users LIMIT 10"
    }
  }
}

Responses

Responses are replies to requests, identified by matching the id field:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Found 10 users..."
      }
    ]
  }
}

Notifications

Notifications are one-way messages that do not expect a response. They are used for events like progress updates, log messages, and the initialized signal:

{
  "jsonrpc": "2.0",
  "method": "notifications/progress",
  "params": {
    "progressToken": "abc123",
    "progress": 50,
    "total": 100
  }
}

Capability Negotiation

Capability negotiation is a core part of the MCP architecture. During initialization, both the client and server declare which optional features they support.

Server Capabilities

Client Capabilities

Content Types

MCP supports several content types in tool results and resource data:

Error Handling

MCP uses standard JSON-RPC 2.0 error codes along with protocol-specific extensions:

Transport Layer

The MCP architecture is transport-agnostic — the protocol messages described above can flow over different communication channels:

• stdio — Standard input/output streams for local process communication
• Streamable HTTP — HTTP with server-sent events for remote communication
• SSE — Legacy server-sent events transport

The transport layer is abstracted away from the protocol logic, meaning the same server code works regardless of which transport is used. Both mcp-framework and the official SDK support multiple transports out of the box.

For a detailed comparison of transports, see MCP Transport Protocols.

Architecture in Practice

Here is how a typical MCP interaction flows in a real application:

1. User asks Claude Desktop to "find all open bugs in my GitHub repo"
2. Host (Claude Desktop) passes the request to the AI model
3. AI model decides it needs to use the GitHub MCP server's list_issues tool
4. Client sends a tools/call request to the GitHub MCP server
5. Server calls the GitHub API, retrieves the issues, and returns the result
6. Client passes the result back to the host
7. Host feeds the result to the AI model as context
8. AI model formulates a response summarizing the open bugs
9. User sees the response in Claude Desktop

This entire flow happens through standardized MCP messages, regardless of which server is being called or which transport is being used.