Model Context Protocol(MCP) Advent Calendar 2025

MCP 2025-11-25 の仕様変更を分かりやすく解説してみる

Last updated at 2025-12-21Posted at 2025-12-21

はじめに

MCP (Model Context Protocol) の仕様は 2024年11月5日に初版がリリースされて以来、2025年12月21日時点で3回変更されています。
初回リリースから約1年後の 2025年11月25日にも仕様変更が行われたため、本記事ではその内容を深掘りします。

なお、 "深掘り" のセクションは1つ1つが長めなので、興味のある部分だけお読みいただくのが良いかと思います。概略の表の "⭐️" マークが付いているものを深掘りしています。

対象読者

MCP Server を利用した事がある
MCP Client を利用した事がある
MCP が何かを知っている
OAuth2 や OpenID Connect の基礎を知っている

2025-11-25 Key Changes

主要な変更点の一覧は以下の通りです:

Key Changes - Model Context Protocol

Major Changes

1. Major changes

#	変更内容	意図/効果
1	Authorization server discovery を拡張し OIDC Discovery 1.0 をサポート (PR #797)	従来は OAuth 2.0 Authorization Server Metadata (`/.well-known/oauth-authorization-server`) のみのサポート。 OIDC Discovery 1.0 (`/.well-known/openid-configuration`) にも対応することでより認可サーバーの情報取得の手段が広がる。
2	サーバーがツール（tools）、リソース (resources / resource templates)、プロンプト (prompts) に対して「アイコン」を追加メタデータとして公開可能に (SEP-973)	サーバーがツール・リソース等にアイコンを付与できるようになった。 UI/UX 向上のため、クライアントが視覚的にツールやリソースを識別しやすくなるメリットがある。
3	認可フロー改善 — `WWW-Authenticate` を使った incremental scope consent を実装 (SEP-835)	初回の認可で全ての権限を要求するのではなく、段階的 (incremental) にスコープ (権限) をユーザーに同意させやすく。必要な権限だけを逐次的にユーザーやクライアントに求める仕組み。結果として過剰なスコープ要求を避け、最小権限原則に沿った安全な OAuth2 運用につながる。
4	ツール名 (tool names) に関するガイダンスを提供 (SEP-986)	ツールの命名に関するガイダンスを明示し、名前付け規約や一意性の扱いを統一。これにより、LLM がツールを解釈しやすくなり、曖昧な識別による誤ったツールの呼び出しを減らす効果が期待できる。
5	スキーマの改善: `ElicitResult` と `EnumSchema` を、より標準に近い形へ更新。タイトル有り/無し、single-select／multi-select の enum に対応 (SEP-1330)	Elicitation の結果や Enum Schema をより標準的に扱えるよう仕様更新。単一選択・複数選択・名付き未名付きの enum 対応が改善され、クライアント側の UI/入力処理の互換性が高まる。
6	⭐️ URL モードによるエリシテーション (elicitation) をサポート (SEP-1036)	Elicitation に外部 URL を指定するモードを追加し、"MCP Client を経由しない外部入力フロー" をサポート。パスワードや機微情報など、MCP Client が扱いたくない入力を外部フォームで安全に取得できるようになる。
7	⭐️ Sampling 時にツール呼び出しをサポート（tools および toolChoice パラメータを利用） (SEP-1577)	モデルがサンプリング Sampling（応答生成）の過程でツールを呼び出す → より動的・実用的なエージェント設計が可能。たとえば、応答生成中に DB クエリやファイル操作を挟むなど。
8	⭐️ OAuth クライアント登録の方法として、Client ID Metadata Documents を推奨機構に (SEP-991)	OAuth 認可におけるクライアント登録方式に Client ID Metadata Documents (CIMD) を追加して推奨。 Dynamic Client Registration (DCR) に依存しない方式を採用でき、多数のクライアントが存在する MCP 環境でも認可フローを柔軟かつ安全に扱えるようにする。
9	実験的 (experimental) に tasks 機能を追加 — 長時間実行タスクのために、ポーリング & 結果取得の遅延が可能に (SEP-1686)	Tasks 機構をプロトコルに追加し、長時間・耐久的処理を tracking 可能に。 Task ID を発行して状態（working, completed, failed 等）を追跡・ポーリングし、結果を後で取得できるようにした。非同期/長時間処理を MCP の標準ワークフローとして扱えるようにし、複雑なジョブや並列処理を実装しやすくする。

Minor Changes

2. Minor changes

#	変更内容	意図/効果
1	stdio トランスポートで、エラーメッセージ以外のログも `stderr` を利用可能に (PR #670)	MCP Server が標準入出力（stdio）経由で通信する際、ログの種類（情報ログ／デバッグログ等）に関わらず `stderr` を使えるように明確化。これにより、クライアント側がログの出力先を一貫して扱いやすくなり、実装時の混乱を減らす効果がある。
2	`Implementation` インターフェースに任意の `description` フィールドを追加	MCP レジストリの `server.json` 形式との整合性のため、サーバー実装時に人間向けの説明文を付与できるようになった。初期化やデバッグ時に実装の意図を明示しやすくする改善。
3	Streamable HTTP トランスポートで無効な Origin ヘッダーに対して `HTTP 403 Forbidden` を返すことを明確化 (PR #1439)	セキュリティ面の厳格化。ブラウザベース等で CORS/Origin チェックを行う際、無効な Origin に対して必ず 403 応答とするべきことを仕様で明確にした。不正アクセスやブラウザの誤ったクロスオリジンリクエストを防ぐ効果がある。
4	セキュリティベストプラクティスガイダンスの更新	セキュリティベストプラクティス文書の内容がアップデートされた。実装者向けに新たな脅威や対策例を盛り込み、MCP を安全に運用するためのガイドを改善することで、セキュリティリスクを低減させる補強的な変更。
5	⭐️ 入力検証エラーは Protocol Error ではなく Tool Execution Error として返すことを明確化 (SEP-1303)	クライアント（特に LLM）の自己修正能力を高めるため、スキーマ／引数のバリデーションに失敗した際の返却種別を明確化。これにより、LLM はツール入力を修正する機会を持ちやすくなり、ユーザー側のエラーを減らす効果が期待できる。
6	SSE (Server-Sent Events) ストリームをサーバー側で任意に切断できるようにサポート (SEP-1699)	SSE ストリームを維持したまま長時間接続する必要がなくなるよう、サーバー側での切断/再接続ポーリングのサポートを追加。長時間処理でコネクションを維持せず、帯域やリソースを節約しながらイベントを配信できるようになる。
7	SEP-1699 の詳細を明確化： GET ストリームはポーリングをサポート、再開は常に GET、event ID はストリーム識別に利用、切断はサーバー側起因も含む (Issue #1847)	SSE ポーリング時の再接続/再開ルールを仕様として明確にしたもの。イベント識別子 (event ID) でストリームを識別し、どのストリームの続きかを制御する。これによりリジュームやクライアントの再接続動作が一貫して扱いやすくなる。
8	⭐️ OAuth 2.0 Protected Resource Metadata discovery を RFC 9728 に合わせて明確化し、 `WWW-Authenticate` ヘッダーをオプション化、.well-known エンドポイントにフォールバック (SEP-985)	認可サーバーやリソースサーバーのメタデータ探索をより信頼性高くする改善。従来は `WWW-Authenticate` で告知する方法があったが、.well-known エンドポイントにフォールバック可能にし、 discovery の失敗要因を減らす実装上の柔軟性向上につながる。
9	Elicitation スキーマの全てのプリミティブ型（string, number, enum）に対して default 値サポートを追加 (SEP-1034)	エリシテーションのスキーマ定義において、すべての基本型でデフォルト値を指定できるようになった。これによりフォーム UI などで初期値を持たせやすくなり、ユーザー入力フローの信頼性と UX が改善される。
10	MCP スキーマ定義の既定の JSON Schema Dialect を JSON Schema 2020-12 に設定 (SEP-1613)	MCP 全体のスキーマ記述の厳密性と整合性を高めるため、JSON Schema のデフォルト方言を 2020-12 に統一。これによりバリデーションやツール生成などのエコシステムの一貫性・相互運用性が向上する。

深掘り

このセクションでは単なる変更点の列挙ではなく、「なぜこの変更が入ったのか」「実装者に何が変わるのか」に焦点を当てて解説します。

Major Change 6: URL モードによる Elicitation をサポート

SEP-1036: URL Mode Elicitation for secure out-of-band interactions

Elicitation とは、 MCP Server 側のビジネスロジックの処理中にユーザーから追加情報を貰うための仕組みです。
つまり、サーバーが情報不足と判断したタイミングで発生します。よって、LLM がパラメータをセットしきれなかったときにも有効ですね。

これまでの Elicitation は、MCP Client がインターナルにフォーム UI やプロンプトを生成する形でした。
文章で説明するよりも Quick Start - MCP Elicitations - fast-agent documentation のページのサンプル画像を見ていただくと分かりやすいかと思います。

URL モードによる Elicitation では「外部の URL をユーザーに開かせるフロー」を定義できるようになりました。
これは例えば以下のような場面で役立ちます：

ユーザーに機微な情報（パスワードやアクセスキーなど）を聞きたいが MCP Client 側では直接扱いたくない
OAuth 認可などの別ウィンドウでの認証フローを経由したい
ブラウザで完結する外部フォームを提供したい

この機能により、MCP Client を経由しない「安全で柔軟な入力フロー」を設計できるようになり、より多様なユーザーインタラクションに対応できるようになります。
MCP Client は単にその URL を開くだけで、実際の入力内容をクライアントが保持しない、という方式をとります。

なお、設計の観点では以下のポイントを抑えておくと良さそうですね。

Form モード: MCP Client が UI をレンダリングして入力を受け取る (in-band)
URL モード: MCP Client を経由しない別プロセスのやり取り (out-of-band)

Elicitation のメリットは、ユーザーが直接入力フォームに情報を与えて自然言語や LLM が介入しないことにより、正確かつ安全に情報を MCP Server に伝達できます。
「これを利用すれば画像などの Binary ファイルを LLM に扱ってもらう必要がないので、 tools/call のパラメータ構築時にデータ破損が起きないのでは？」と思いました。
すると、既に SEP-1306 で提案されていました。
SEP-1306: Binary Mode Elicitation for File Uploads

Major Change 7: Sampling 時に Tool 呼び出しをサポート

SEP-1303: Input Validation Errors as Tool Execution Errors

Sampling は MCP における LLM の応答生成リクエストです。LLM サーバーに対して何をどう生成するかを伝えるフェーズで、これまでは単純なテキスト生成や補完が中心でした。
2025-11-25 の仕様変更で、Sampling に tools と toolChoice パラメータが追加され、定義されたツールを実行しながら生成プロセスを進めることができるようになりました。

これは以下のような意味を持ちます：

モデルが単に「テキスト回答を返す」だけでなく、実際のツール（API コールや DB クエリなど）を呼び出した結果を踏まえて回答を生成できる
サーバー側でエージェント的なループ制御（生成 → ツール実行 → 再生成）をプロトコル上で扱える

例としては、以下のような流れが可能になります：

モデルが「最新の売上データを取得したい」と言う
Sampling 中に定義された getSalesData ツールを呼び出す
実際のデータをサーバーが取得して返す
モデルはその結果を踏まえた自然言語応答を生成する

この仕組みによって、モデルを より動的で実用的なエージェント化 しやすくなり、単純な補完だけでなくアクションを含んだ応答が可能になります。

Major Change 8: Client ID Metadata Documents (CIMD)

SEP-991: Enable URL-based Client Registration using OAuth Client ID Metadata Documents

OAuth2 を用いた認可フローでは、クライアント（MCP Client）が 認可サーバーに登録されている必要があります。
従来 MCP では Dynamic Client Registration (DCR) を推奨していましたが、DCR は実装負担やセキュリティリスク（クライアントデータベースの肥大化・濫用リスクなど）に課題がありました。
そこで 2025-11-25 の仕様変更で Client ID Metadata Documents（CIMD） が追加され、「Client ID 自身が自身のメタデータの URL である」という方式が推奨されるようになりました。

従来:
- クライアントは事前に認可サーバーに登録し client_id / client_secret を得る
- または DCR を使って動的に登録する必要があった
変更後:
- クライアントは自分で HTTPS URL を持ち（例：https://app.example.com/oauth/client-metadata.json）
- その URL に自身のメタデータ（名前・リダイレクト URI・レスポンスタイプなど）を置く
- 認可サーバーはその URL を client_id として扱う

この方式は、事前登録が困難な環境や不特定多数のクライアントを想定する場面で有効です。
また、DCR のようにサーバー側にクライアント情報を保存・永続化せずとも OAuth2 フローを実装できます。

ただし、CIMD においてクライアントは MCP Server に対してエンドポイントを提供する（ポート解放を行う）必要があるため、エンドユーザー向けのアプリケーションが CIMD を利用するのは難しい場合があります。

FastMCP が OAuth Proxy という機能をサポートするようになり、自前で DCR を実装する必要はなくなりました。
Redis などのデータストアにも対応しており、DCR のクライアント情報の永続化も簡単に行えます。
OAuth Proxy - FastMCP

Minor Change 5: 入力検証は Tool Execution Error

SEP-1303: Input Validation Errors as Tool Execution Errors

MCP - Specification - Tools - 6. Error Handling に記載されているように、MCP には以下の2種類のエラーがあります：

Protocol Error（JSON-RPC 通信・構文のエラー）
→ JSON メッセージ自体が不正で、クライアントが受け取って処理を止めるべきもの
```
{
  "jsonrpc": "2.0",
  "id": 3,
  "error": {
    "code": -32602,
    "message": "Unknown tool: invalid_tool_name"
  }
}
```

Tool Execution Error（ツール実行時のエラー）
→ ツール内部で起きたエラー情報としてモデルへ返される

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Failed to connect to the database: Connection timeout"
      }
    ],
    "isError": true
  }
}

従来は、引数のバリデーション失敗（例：必須フィールドが無い・型が合わないなど）が Protocol Error として扱われることがありました。
Protocol Error はモデル（LLM）に渡されないので、モデルが修正のヒントを得られないという制約があります。

そのため 2025-11-25 の仕様で、これらの入力検証エラーも Tool Execution Error (isError: true) として返すように明確化されました。
こうすることで、モデルはエラー内容を受け取り、自己修正して再挑戦するチャンスを持てるようになります。
たとえば「location は空文字列ではダメ」というエラーをツール呼び出し時に返せば、モデルはそこを修正して次の呼び出しができるようになります。

Minor Change 8: OAuth 2.0 Protected Resource Metadata discovery

SEP-985: Align OAuth 2.0 Protected Resource Metadata with RFC 9728

OAuth2 の仕様では、保護リソース（API サーバーなど）が自分自身のメタデータ（どの認可サーバーを使うかなど）をクライアントに教える必要があります。
従来は WWW-Authenticate ヘッダーで通知するのが一般的でしたが、これが実装負担になっていました。

2025-11-25 の変更で、RFC 9728 に合わせて /.well-known/ エンドポイントへのフォールバックが可能になりました。

つまり、

WWW-Authenticate ヘッダーがあればそれを優先
それが無ければ /.well-known/oauth-protected-resource を見に行く

という形で、認可サーバーやリソースサーバーのメタデータ探索が安定し、実装の自由度が上がるようになります。

フォールバック とは、ある方法が使えない場合に別の方法を試すことを指します。
ここでは、WWW-Authenticate ヘッダーが無い場合に /.well-known/ エンドポイントを使うことを意味します。

様々な /.well-known/ エンドポイントがあってややこしいので、以下に整理します。

/.well-known/oauth-protected-resource (RFC 9728)
- リソースサーバー / MCP Server が提供するエンドポイント
- どの認可サーバーを信頼（利用）するかを示す
```
{
  "resource": "https://your-mcp.example.com",
  "authorization_servers": [
    "https://auth.example.com"
  ],
  "scopes_supported": ["read", "write"]
}
```
/.well-known/oauth-authorization-server (RFC 8414)
- 認可サーバー が提供するエンドポイント
- 認可サーバーのメタデータ（エンドポイント URL やサポート機能など）を示す
- OAuth クライアントが OAuth フローを実行するために必要な情報
```
{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "scopes_supported": ["read", "write"]
}
```

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up