Skip to content

Overview

Model Context Protocol は、相互に連携して動作するいくつかの主要な構成要素から成り立っています。

  • Base Protocol: 中核となる JSON-RPC message type
  • Lifecycle Management: connection initialization、capability negotiation、session control
  • Authorization: HTTP-based transport 向けの authentication / authorization framework
  • Server Features: server が公開する resources、prompts、tools
  • Client Features: client が提供する sampling と root directory list
  • Utilities: logging や argument completion のような横断的関心事

すべての implementation は、base protocol と lifecycle management component をサポートしなければなりません (MUST)。その他の component は、アプリケーション固有の必要に応じて実装してもよいです (MAY)。

これらの protocol layer は、client と server の間の豊かな相互作用を可能にしつつ、関心事の明確な分離を確立します。modular design により、implementation は自分たちに必要な feature だけを正確にサポートできます。

Messages

MCP client と server の間のすべての message は、JSON-RPC 2.0 specification に従わなければなりません (MUST)。この protocol では、次の種類の message を定義しています。

Requests

Requests は、ある操作を開始するために、client から server、またはその逆方向に送られます。

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
  • Request には、string または integer の ID を含めなければなりません (MUST)。
  • 基本の JSON-RPC とは異なり、ID を null にしてはなりません (MUST NOT)。
  • request ID は、同じ session 内で requestor によって以前使われたものであってはなりません (MUST NOT)。

Responses

Response は request への返答として送られ、操作の result または error を含みます。

Result Responses

Result response は、操作が正常に完了したときに送られます。

{
  jsonrpc: "2.0";
  id: string | number;
  result: {
    [key: string]: unknown;
  }
}
  • Result response は、対応する request と同じ ID を含めなければなりません (MUST)。
  • Result response は、result field を含めなければなりません (MUST)。
  • result は任意の JSON object structure に従ってもよいです (MAY)。

Error Responses

Error response は、操作が失敗したり error に遭遇したりしたときに送られます。

{
  jsonrpc: "2.0";
  id?: string | number;
  error: {
    code: number;
    message: string;
    data?: unknown;
  }
}
  • Error response は、対応する request と同じ ID を含めなければなりません (MUST)（ただし、不正な request により ID を読み取れない error case は除きます）。
  • Error response は、code と message を持つ error field を含めなければなりません (MUST)。
  • error code は integer でなければなりません (MUST)。

Notifications

Notification は、client から server、またはその逆方向に送られる一方向 message です。 受信側は response を送ってはなりません (MUST NOT)。

{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
  • Notification には ID を含めてはなりません (MUST NOT)。

Auth

MCP は、HTTP で利用するための Authorization framework を提供します。 HTTP-based transport を使用する implementation は、この仕様に準拠するべきです (SHOULD)。一方、STDIO transport を使用する implementation は、この仕様に従うべきではありません (SHOULD NOT)。代わりに environment から credential を取得します。

さらに、client と server は独自の custom authentication / authorization strategy を交渉してもよいです (MAY)。

MCP の auth mechanism の進化に関するさらなる議論や貢献については、GitHub Discussions に参加して protocol の将来形成に協力してください。

Schema

protocol の完全な仕様は TypeScript schema として定義されています。 これが、すべての protocol message と structure に関する source of truth です。

また、TypeScript の source of truth から自動生成される JSON Schema もあります。これは各種の automated tooling で利用するためのものです。

JSON Schema Usage

Model Context Protocol は、protocol 全体を通じて validation に JSON Schema を使用します。この section では、MCP message 内で JSON Schema をどのように使うべきかを明確にします。

Schema Dialect

MCP は、次のルールで JSON Schema をサポートします。

  1. Default dialect: schema に $schema field が含まれていない場合、JSON Schema 2020-12 が default になります
  2. Explicit dialect: schema は、異なる dialect を指定するために $schema field を含めてもよいです (MAY)
  3. Supported dialects: implementation は少なくとも 2020-12 をサポートしなければなりません (MUST)。また、追加でサポートする dialect を文書化するべきです (SHOULD)
  4. Recommendation: 実装者は JSON Schema 2020-12 を使うことが推奨されます (RECOMMENDED)

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

  • client と server は、明示的な $schema field がない schema について JSON Schema 2020-12 をサポートしなければなりません (MUST)
  • client と server は、宣言された dialect または default dialect に従って schema を検証しなければなりません (MUST)。未対応の dialect については、その dialect がサポートされていないことを示す適切な error を返し、gracefully に処理しなければなりません (MUST)。
  • client と server は、どの schema dialect をサポートするか文書化するべきです (SHOULD)

Schema Validation

  • schema は、宣言された dialect または default dialect に従って妥当でなければなりません (MUST)

General fields

_meta

_meta property / parameter は、client と server が相互作用に追加 metadata を付加できるようにするために、MCP によって予約されています。

以下に示すとおり、一部の key name は protocol-level metadata のために MCP によって予約されています。implementation は、これらの key にある value について前提を置いてはなりません (MUST NOT)。

さらに、schema 内の定義では、その定義で宣言された purpose-specific metadata のために、特定の name が予約されている場合があります。

Key name format: 有効な _meta key name は、任意の prefix と name という 2 つの segment を持ちます。

Prefix:

  • 指定する場合、dot（.）で区切られた label 群の後に slash（/）が続く形式でなければなりません (MUST)。
    • label は文字で始まり、文字または数字で終わらなければなりません (MUST)。中間の文字には、文字、数字、hyphen（-）を使用できます。
    • implementation は reverse DNS notation を使うべきです (SHOULD)（例: example.com/ ではなく com.example/）
  • 2 番目の label が modelcontextprotocol または mcp である prefix は、MCP 用として reserved されています。
    • たとえば io.modelcontextprotocol/、dev.mcp/、org.modelcontextprotocol.api/、com.mcp.tools/ はすべて reserved です。
    • 一方で com.example.mcp/ は reserved ではありません。2 番目の label が example だからです。

Name:

  • 空でない場合、英数字（[a-z0-9A-Z]）で始まり、英数字で終わらなければなりません (MUST)。
  • 途中には hyphen（-）、underscore（_）、dot（.）、および英数字を含めてもよいです (MAY)。

icons

icons property は、server が自らの resources、tools、prompts、implementation に対して visual identifier を公開するための標準化された方法を提供します。icon は、visual context を与え、利用可能な機能の discoverability を高めることで、user interface を改善します。

icon は Icon object の配列として表され、各 icon には次が含まれます。

  • src: icon resource を指す URI（必須）。次のいずれかです。
    • image file を指す HTTP/HTTPS URL
    • base64-encoded image data を持つ data URI
  • mimeType: server の type が欠けている、または一般的すぎる場合に使う任意の MIME type
  • sizes: 任意の size specification の配列（例: ["48x48"]、SVG のような scalable format 向けの ["any"]、または複数 size 向けの ["48x48", "96x96"]）
  • theme: icon background に対する任意の theme preference（light または dark）

Required MIME type support:

icon の rendering をサポートする client は、少なくとも次の MIME type をサポートしなければなりません (MUST)。

  • image/png - PNG image（安全で、広く互換性がある）
  • image/jpeg および image/jpg - JPEG image（安全で、広く互換性がある）

icon の rendering をサポートする client は、次もサポートするべきです (SHOULD)。

  • image/svg+xml - SVG image（scalable だが、後述のとおり security precaution が必要）
  • image/webp - WebP image（現代的で効率のよい format）

Security considerations:

icon metadata を利用する側は、icon を扱う際に compromise を防ぐため、適切な security precaution を講じなければなりません (MUST)。

  • icon metadata と icon bytes は untrusted input として扱い、network、privacy、parsing に関する risk から防御すること。
  • icon URI が HTTPS または data: URI のいずれかであることを確認すること。client は、javascript:、file:、ftp:、ws:、または local app URI scheme などの unsafe scheme や redirect を使う icon URI を拒否しなければなりません (MUST)。
    • scheme の変更や、異なる origin host への redirect を許可しないこと。
  • oversized image、大きすぎる dimension、過剰な frame 数（GIF など）による resource exhaustion attack に耐えられるようにすること。
    • 利用側は、image size や content size に制限を設けてもよいです (MAY)。
  • credential なしで icon を fetch すること。cookie、Authorization header、client credential を送信してはなりません。
  • icon URI が server と同じ origin に属することを検証すること。これにより third-party への data や tracking information の露出 risk を最小化できます。
  • payload に executable content が含まれる可能性があるため、icon の fetch と rendering には注意を払うことが必要です（たとえば embedded JavaScript を含む SVG や extended capability）。
    • 利用側は、特定の file type を禁止したり、rendering 前に icon file を sanitize したりしてもよいです (MAY)。
  • rendering 前に MIME type と file content を検証すること。MIME type 情報は advisory として扱うこと。magic bytes で content type を検出し、不一致または未知の type は拒否すること。
    • image type の strict allowlist を維持すること。

Usage:

icon は次に付与できます。

  • Implementation: MCP server / client implementation の visual identifier
  • Tool: tool の機能を表す visual representation
  • Prompt: prompt template と一緒に表示する icon
  • Resource: 異なる resource type の visual indicator

異なる display context や resolution をサポートするために、複数の icon を提供できます。client は、自身の UI requirement に応じて最も適切な icon を選択すべきです (SHOULD)。