Protocol Specification

Detailed technical specification of the Model Context Protocol

Protocol Overview

The Model Context Protocol (MCP) follows a client-host-server architecture where each host can run multiple client instances. This architecture enables users to integrate AI capabilities across applications while maintaining clear security boundaries and isolating concerns. MCP is built on JSON-RPC and provides a stateful session protocol focused on context exchange and sampling coordination between clients and servers.

Architecture

The core component architecture is shown below:

Component Details

Host

The host process is the core coordinator of the MCP protocol. It is responsible for managing the lifecycle of client instances, controlling connection permissions, and enforcing security policies. The host is also responsible for coordinating AI/LLM integration, ensuring smooth operation of the entire system.

Manage lifecycle of client instances

Control connection permissions and enforce security policies

Coordinate AI/LLM integration

Ensure system stability

Clients are created by the host to maintain independent connections with servers. Each client maintains a 1:1 relationship with a server, ensuring connection isolation and security.

Maintain independent connections with servers

Establish stateful sessions

Handle protocol negotiation

Manage message routing

Server

Servers are responsible for exposing resources and tools. They can run independently and handle sampling requests through clients. Servers can be local or remote, providing various functionalities to the system.

Expose specific resources and tools

Run and manage independently

Handle requests through clients

Support local and remote services

Protocol Basics

All messages in MCP must follow the JSON-RPC 2.0 specification. The protocol defines three types of messages:

Request

Bidirectional message that can be sent from client to server or vice versa

Must include an ID of string or integer type

ID cannot be null

The same ID cannot be reused by the requester within the same session

Can include an optional parameter object

Request Example

{
  "jsonrpc": "2.0",
  "id": "string | number",
  "method": "string",
  "param?": {
    "key": "value"
  }
}

Response

Sent as a reply to a request

Must include the same ID as the corresponding request

Must set either result or error, but not both

Error code must be an integer

Can include optional result data

Response Example

{
  "jsonrpc": "2.0",
  "id": "string | number",
  "result?": {
    "[key: string]": "unknown"
  },
  "error?": {
    "code": "number",
    "message": "string",
    "data?": "unknown"
  }
}

Notification

One-way message that doesn't require a response, can be sent from client to server or vice versa

Cannot include an ID field

Used for status updates and event notifications

Can include an optional parameter object

Reduces communication overhead, supports asynchronous operations

Notification Example

{
  "jsonrpc": "2.0",
  "method": "string",
  "params?": {
    "[key: string]": "unknown"
  }
}

Lifecycle

MCP defines a strict lifecycle for client-server connections, ensuring proper capability negotiation and state management.

Initialization Phase

The initialization phase must be the first interaction between the client and server. During this phase, both parties:

Establish protocol version compatibility

Exchange and negotiate capabilities

Share implementation details

Initialize Request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "sampling": {}
    },
    "clientInfo": {
      "name": "ExampleClient",
      "version": "1.0.0"
    }
  }
}

Initialize Response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "logging": {},
      "prompts": {
        "listChanged": true
      },
      "resources": {
        "subscribe": true,
        "listChanged": true
      },
      "tools": {
        "listChanged": true
      }
    },
    "serverInfo": {
      "name": "ExampleServer",
      "version": "1.0.0"
    }
  }
}

Initialized Notification

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

Version Negotiation

In the initialize request, the client must send the protocol version it supports.

The client should send the latest version it supports

The server must respond with the same version or another version it supports

If the client doesn't support the server's version, it should disconnect

Capability Negotiation

Client and server capabilities determine which optional protocol features are available during the session.

Client Capabilities

roots

Ability to provide filesystem root directories

sampling

Support for LLM sampling requests

experimental

Describes support for non-standard experimental features

Server Capabilities

prompts

Provides prompt templates

resources

Provides readable resources

tools

Provides callable tools

logging

Emits structured log messages

experimental

Describes support for non-standard experimental features

Operation Phase

During the operation phase, the client and server exchange messages according to the negotiated capabilities.

Adhere to the negotiated protocol version

Use only successfully negotiated capabilities

Shutdown Phase

In the shutdown phase, the connection is gracefully terminated.

Client sends a disconnect notification

Server closes the connection

Clean up associated resources

Transport Mechanisms

MCP currently defines two standard client-server communication transport mechanisms: stdio (standard input/output) and HTTP-based SSE. Clients should support stdio whenever possible. Additionally, clients and servers can implement custom transport mechanisms in a pluggable manner.

Standard Input/Output (stdio)

In the stdio transport mechanism:

The client launches the MCP server as a child process
The server receives JSON-RPC messages via standard input (stdin) and writes responses to standard output (stdout)
Messages are newline-delimited and must not contain embedded newlines
The server may write UTF-8 strings to standard error (stderr) for logging. Clients may capture, forward, or ignore these logs
The server must not write any non-valid MCP message content to stdout
The client must not write any non-valid MCP message content to the server's stdin

HTTP-based SSE

In the SSE transport mechanism, the server runs as a standalone process and can handle multiple client connections.

The server must provide two endpoints:

SSE Endpoint - For clients to establish connections and receive messages from the server
HTTP POST Endpoint - For clients to send messages to the server

When a client connects, the server must send an endpoint event containing the URI for the client to send messages to
All subsequent client messages must be sent as HTTP POST requests to this endpoint
Server messages are sent as SSE message events with the message content JSON-encoded in the event data

Custom Transport Mechanisms

Clients and servers can implement additional custom transport mechanisms to meet their specific needs. The protocol is transport-agnostic and can be implemented on any communication channel that supports bidirectional message exchange.

Implementers choosing to support custom transport mechanisms must ensure they preserve the JSON-RPC message format and lifecycle requirements defined by MCP
Custom transport mechanisms should document their specific connection establishment and message exchange patterns to aid in interoperability

Server Features

The server provides the basic building blocks for adding context to language models via MCP, offering three fundamental primitives for managing context: prompts, resources, and tools.

Primitive	Control	Description	Example
Prompts	System	Define model behavior and role	You are a professional code reviewer
Resources	User	Provide additional context information	Code files, documentation
Tools	System/User	Extend model capabilities	Code search, file editing

Resource Management

Provide context and data for AI models

Support for multiple resource types
Dynamic resource loading
Resource lifecycle management

Tool Integration

Extend AI model capabilities

Flexible tool registration mechanism
Tool invocation permission control
Asynchronous tool execution support

Context Control

Precisely control AI model behavior

System-level prompt management
Dynamic context updates
Multi-turn conversation state maintenance