Protocol Revision: draft
The Model Context Protocol consists of several key components that work together:
  • Base Protocol: Core JSON-RPC message types
  • Lifecycle Management: Connection initialization, capability negotiation, and session control
  • Authorization: Authentication and authorization framework for HTTP-based transports
  • Server Features: Resources, prompts, and tools exposed by servers
  • Client Features: Sampling and root directory lists provided by clients
  • Utilities: Cross-cutting concerns like logging and argument completion
All implementations MUST support the base protocol and lifecycle management components. Other components MAY be implemented based on the specific needs of the application. These protocol layers establish clear separation of concerns while enabling rich interactions between clients and servers. The modular design allows implementations to support exactly the features they need.

​
Messages

All messages between MCP clients and servers MUST follow the JSON-RPC 2.0 specification. The protocol defines these types of messages:

​
Requests

Requests are sent from the client to the server or vice versa, to initiate an operation. 
{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
  • Requests MUST include a string or integer ID.
  • Unlike base JSON-RPC, the ID MUST NOT be null.
  • The request ID MUST NOT have been previously used by the requestor within the same session.

​
Responses

Responses are sent in reply to requests, containing the result or error of the operation. 
{
  jsonrpc: "2.0";
  id: string | number;
  result?: {
    [key: string]: unknown;
  }
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}
  • Responses MUST include the same ID as the request they correspond to.
  • Responses are further sub-categorized as either successful results or errors. Either a result or an error MUST be set. A response MUST NOT set both.
  • Results MAY follow any JSON object structure, while errors MUST include an error code and message at minimum.
  • Error codes MUST be integers.

​
Notifications

Notifications are sent from the client to the server or vice versa, as a one-way message. The receiver MUST NOT send a response. 
{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
  • Notifications MUST NOT include an ID.

​
Auth

MCP provides an Authorization framework for use with HTTP. Implementations using an HTTP-based transport SHOULD conform to this specification, whereas implementations using STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment. Additionally, clients and servers MAY negotiate their own custom authentication and authorization strategies. For further discussions and contributions to the evolution of MCP’s auth mechanisms, join us in GitHub Discussions to help shape the future of the protocol!

​
Schema

The full specification of the protocol is defined as a TypeScript schema. This is the source of truth for all protocol messages and structures. There is also a JSON Schema, which is automatically generated from the TypeScript source of truth, for use with various automated tooling.

​
General fields

​
_meta

The _meta property/parameter is reserved by MCP to allow clients and servers to attach additional metadata to their interactions. Certain key names are reserved by MCP for protocol-level metadata, as specified below; implementations MUST NOT make assumptions about values at these keys. Additionally, definitions in the schema may reserve particular names for purpose-specific metadata, as declared in those definitions. Key name format: valid _meta key names have two segments: an optional prefix, and a name. Prefix:
  • If specified, MUST be a series of labels separated by dots (.), followed by a slash (/).
    • Labels MUST start with a letter and end with a letter or digit; interior characters can be letters, digits, or hyphens (-).
  • Any prefix beginning with zero or more valid labels, followed by modelcontextprotocol or mcp, followed by any valid label, is reserved for MCP use.
    • For example: modelcontextprotocol.io/, mcp.dev/, api.modelcontextprotocol.org/, and tools.mcp.com/ are all reserved.
Name:
  • Unless empty, MUST begin and end with an alphanumeric character ([a-z0-9A-Z]).
  • MAY contain hyphens (-), underscores (_), dots (.), and alphanumerics in between.

​
icons

The icons property provides a standardized way for servers to expose visual identifiers for their resources, tools, prompts, and implementations. Icons enhance user interfaces by providing visual context and improving the discoverability of available functionality. Icons are represented as an array of Icon objects, where each icon includes:
  • src: A URI pointing to the icon resource (required). This can be:
    • An HTTP/HTTPS URL pointing to an image file
    • A data URI with base64-encoded image data
  • mimeType: Optional MIME type if the server’s type is missing or generic
  • sizes: Optional size specification (e.g., “48x48”, “any” for scalable formats like SVG, or “48x48 96x96” for multiple sizes)
Required MIME type support: Clients that support rendering icons MUST support at least the following MIME types:
  • image/png - PNG images (safe, universal compatibility)
  • image/jpeg (and image/jpg) - JPEG images (safe, universal compatibility)
Clients that support rendering icons SHOULD also support:
  • image/svg+xml - SVG images (scalable but requires security precautions as noted below)
  • image/webp - WebP images (modern, efficient format)
Security considerations: Consumers of icon metadata MUST take appropriate security precautions when handling icons to prevent compromise:
  • Treat icon metadata and icon bytes as untrusted inputs and defend against network, privacy, and parsing risks.
  • Ensure that the icon URI is either a HTTPS or data: URI. Clients MUST reject icon URIs that use unsafe schemes and redirects, such as javascript:, file:, ftp:, ws:, or local app URI schemes.
    • Disallow scheme changes and redirects to hosts on different origins.
  • Be resilient against resource exhaustion attacks stemming from oversized images, large dimensions, or excessive frames (e.g., in GIFs).
    • Consumers MAY set limits for image and content size.
  • Fetch icons without credentials. Do not send cookies, Authorization headers, or client credentials.
  • Verify that icon URIs are from the same origin as the server. This minimizes the risk of exposing data or tracking information to third-parties.
  • Exercise caution when fetching and rendering icons as the payload MAY contain executable content (e.g., SVG with embedded JavaScript or extended capabilities).
    • Consumers MAY choose to disallow specific file types or otherwize sanitize icon files before rendering.
  • Validate MIME types and file contents before rendering. Treat the MIME type information as advisory. Detect content type via magic bytes; reject on mismatch or unknown types.
    • Maintain a strict allowlist of image types.
Usage: Icons can be attached to:
  • Implementation: Visual identifier for the MCP server/client implementation
  • Tool: Visual representation of the tool’s functionality
  • Prompt: Icon to display alongside prompt templates
  • Resource: Visual indicator for different resource types
Multiple icons can be provided to support different display contexts and resolutions. Clients should select the most appropriate icon based on their UI requirements.