Movatterモバイル変換

[0]ホーム
URL:

Skip to main content
Base Protocol

Overview

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, andsession 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 implementationsMUST support the base protocol and lifecycle managementcomponents. Other componentsMAY be implemented based on the specific needs of theapplication.These protocol layers establish clear separation of concerns while enabling richinteractions between clients and servers. The modular design allows implementations tosupport exactly the features they need.

Messages

All messages between MCP clients and serversMUST follow theJSON-RPC 2.0 specification. The protocol definesthese 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;  };}
  • RequestsMUST include a string or integer ID.
  • Unlike base JSON-RPC, the IDMUST NOT benull.
  • The request IDMUST NOT have been previously used by the requestor within the samesession.

Responses

Responses are sent in reply to requests, containing either the result or error of the operation.

Result Responses

Result responses are sent when the operation completes successfully.
{  jsonrpc:"2.0";  id:string | number;  result: {    [key:string]:unknown;  }}
  • Result responsesMUST include the same ID as the request they correspond to.
  • Result responsesMUST include aresult field.
  • TheresultMAY follow any JSON object structure.

Error Responses

Error responses are sent when the operation fails or encounters an error.
{  jsonrpc:"2.0";  id?: string | number;  error: {    code:number;    message:string;    data?: unknown;  }}
  • Error responsesMUST include the same ID as the request they correspond to (except in error cases where the ID could not be read due a malformed request).
  • Error responsesMUST include anerror field with acode andmessage.
  • Error codesMUST be integers.

Notifications

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

Auth

MCP provides anAuthorization framework for use with HTTP.Implementations using an HTTP-based transportSHOULD conform to this specification,whereas implementations using STDIO transportSHOULD NOT follow this specification,and instead retrieve credentials from the environment.Additionally, clients and serversMAY negotiate their own custom authentication andauthorization strategies.For further discussions and contributions to the evolution of MCP’s auth mechanisms, joinus inGitHub Discussionsto help shape the future of the protocol!

Schema

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

JSON Schema Usage

The Model Context Protocol uses JSON Schema for validation throughout the protocol. This section clarifies how JSON Schema should be used within MCP messages.

Schema Dialect

MCP supports JSON Schema with the following rules:
  1. Default dialect: When a schema does not include a$schema field, it defaults to JSON Schema 2020-12 (https://json-schema.org/draft/2020-12/schema)
  2. Explicit dialect: Schemas MAY include a$schema field to specify a different dialect
  3. Supported dialects: Implementations MUST support at least 2020-12 and SHOULD document which additional dialects they support
  4. Recommendation: Implementors are RECOMMENDED to use JSON Schema 2020-12.

Example Usage

Default dialect (2020-12):

{  "type":"object",  "properties": {    "name": {"type":"string" },    "age": {"type":"integer","minimum":0 }  },  "required": ["name"]}

Explicit dialect (draft-07):

{  "$schema":"http://json-schema.org/draft-07/schema#",  "type":"object",  "properties": {    "name": {"type":"string" },    "age": {"type":"integer","minimum":0 }  },  "required": ["name"]}

Implementation Requirements

  • Clients and serversMUST support JSON Schema 2020-12 for schemas without an explicit$schema field
  • Clients and serversMUST validate schemas according to their declared or default dialect. TheyMUST handle unsupported dialects gracefully by returning an appropriate error indicating the dialect is not supported.
  • Clients and serversSHOULD document which schema dialects they support

Schema Validation

  • SchemasMUST be valid according to their declared or default dialect

General fields

_meta

The_meta property/parameter is reserved by MCP to allow clients and serversto 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 theschemamay reserve particular names for purpose-specific metadata, as declared in those definitions.Key name format: valid_meta key names have two segments: an optionalprefix, and aname.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 (-).
    • Implementations SHOULD use reverse DNS notation (e.g.,com.example/ rather thanexample.com/).
  • Any prefix where the second label ismodelcontextprotocol ormcp isreserved for MCP use.
    • For example:io.modelcontextprotocol/,dev.mcp/,org.modelcontextprotocol.api/, andcom.mcp.tools/ are all reserved.
    • However,com.example.mcp/ is NOT reserved, as the second label isexample.
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

Theicons 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 ofIcon 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 array of size specifications (e.g.,["48x48"],["any"] for scalable formats like SVG, or["48x48", "96x96"] for multiple sizes)
  • theme: Optional theme preference (light ordark) for the icon background
Required MIME type support:Clients that support rendering iconsMUST support at least the following MIME types:
  • image/png - PNG images (safe, universal compatibility)
  • image/jpeg (andimage/jpg) - JPEG images (safe, universal compatibility)
Clients that support rendering iconsSHOULD 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 metadataMUST 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 ordata: URI. ClientsMUST reject icon URIs that use unsafe schemes and redirects, such as#"https://www.w3.org/TR/SVG11/script.html" rel="noreferrer">embedded JavaScript orextended capabilities).
    • ConsumersMAY choose to disallow specific file types or otherwise 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.

Was this page helpful?

⌘I
[8]ページ先頭
©2009-2025 Movatter.jp