
はじめに
開発本部でデリッシュキッチンのアプリウェブグロース向けの開発を担当しているhondです!
9月末にMCPの最新仕様が2025/11/25にリリースされることが発表されました。この記事では2024-11-05から2025-03-26、2025-06-18、そして次期2025-11-25でどのような変更が行われてきたか主要な機能と私が特に興味を持った点について説明しようと思います。
先日Go公式のMCP SDKについて発表したスライドもあるので、興味のある方はぜひチェックしてください。
MCPとは
MCP(Model Context Protocol)は、LLM に外部コンテキストを安全かつ一貫した方法で渡すためのオープンプロトコルです。プロトコルはJSON‑RPC 2.0で、基本的には stateful な接続を前提としています。主要なcomponentはHost、Client、Server の3つで、IDE やチャットなどの実行環境(Host)と、実際にServerとやり取りを行うClientがServerごとに生成されます

主要機能
Clientには作業の起点を示すRootsと、LLMへの生成依頼を行うSamplingがあり、Serverには実行可能な機能一覧を返すTools、ファイルやデータベーススキーマなどLLMがコンテキストとして利用可能なソースを公開するResources、再利用可能なPromptsが用意されています。
バージョニングの原則
MCPの仕様はリリースされた日付(YYYY-MM-DD)で管理されています。初期化時には Client/Server 間で利用可能なバージョンの合意を行います。
以降の章ではバージョンごとの主要な変更点についてまとめていきます。
2024-11-05
概要
最初の安定版にあたる2024-11-05では、通信方式・ライフサイクル・機能群の土台が定義されました。ざっくりの全体像は次のとおりです。
- Transport: HTTP+SSE、stdio
- ベース: JSON-RPC 2.0 / Base lifecycle / Capabilities
- Client: Roots / Sampling
- Server: Tools / Resources / Prompts
- ユーティリティ: Pagination / Logging / Completion
Client
Roots
Clientが「どこを起点に動くのか」ファイルシステムのルートを明示するのが Roots です。初期化フェーズで Serverが Roots を確認し、その後の操作はこの範囲(ワークスペースやルートディレクトリなど)の中で行われます。
Sampling
ServerがClientを介してLLMに生成や補完を依頼する仕組みです。モデルのヒントや優先度、トークン数などを指定して、対話生成を柔軟にコントロールできます。
Sampling を使うと生成・補完はLLMに任せることができ、Serverは特定のドメイン知識を抱える必要がなくなります。
例
Sampling - Model Context Protocol
下記が公式から引用した例になります。
フランスの首都に関する情報をLLMに補完させることでServerが、それらの情報を持つ必要をなくしています。
Request
{ "jsonrpc": "2.0", "id": 1, "method": "sampling/createMessage", "params": { "messages": [ { "role": "user", "content": { "type": "text", "text": "What is the capital of France?" } } ], "modelPreferences": { "hints": [{ "name": "claude-3-sonnet" }], "intelligencePriority": 0.8, "speedPriority": 0.5 }, "systemPrompt": "You are a helpful assistant.", "maxTokens": 100 } }
Response
{ "jsonrpc": "2.0", "id": 1, "result": { "role": "assistant", "content": { "type": "text", "text": "The capital of France is Paris." }, "model": "claude-3-sonnet-20240307", "stopReason": "endTurn" } }
Server
Tools
ファイル操作や外部 API 呼び出しなどのServerが行えるアクションを、Clientに公開する機能です。ClientはToolsから実行したい機能を選択し、必要な引数を渡して実行します。
Resources
ServerがClientにファイルやデータベーススキーマなどのServerが有する情報を公開する機能です。各リソースはURIによって公開され、Clientはこれらの情報をLLMにコンテキストとして利用することが可能です。
例
Resources - Model Context Protocol
下記はResourceの一覧取得に関するRequestとResponseになります。
Request
{ "jsonrpc": "2.0", "id": 1, "method": "resources/list", "params": { "cursor": "optional-cursor-value" } }
Response
{ "jsonrpc": "2.0", "id": 1, "result": { "resources": [ { "uri": "file:///project/src/main.rs", "name": "main.rs", "description": "Primary application entry point", "mimeType": "text/x-rust" } ], "nextCursor": "next-page-cursor" } }
Prompts
Serverが利用可能なプロンプトの雛形を公開する機能です。Clientはprompts/list で候補を見つけ、prompts/get でテンプレート本文と変数を取得します。
2025-03-26
2025-03-26では認証方式の追加や通信方式の改善、スキーマの改善が行われました。(Key Changes)以降はその中でもMajor changesに当たるOAuth,Streamable HTTP,JSON-RPC Batching,Tool Annotationsについて説明します。
Authorization Framework
HTTPベースのTransportではOAuth 2.0,OAuth 2.1の仕様に基づいたAuthorizationの実装が推奨されるようになりました。stdioではAuthorizationは非推奨となっており代わりに環境変数を用いた方式が推奨されています。
この仕様追加により各言語SDKが認証を公式提供する様になったので、企業など不特定多数にMCPを提供する際に特定のユーザーのみに制限する実装が容易になりました。
Streamable HTTP
Transportの推奨がstdio,HTTP+SSEからstdio,Sreamable HTTPに変更されました。これによりClientとしては単一のエンドポイントで双方向の通信が可能になるので以前より実装が容易になります。
双方向の通信を実現するためになぜWebSocketを採用しなかったのかなどSreamable HTTPに移行するにあたる詳細な判断理由はこちらのPRに記述されています。
JSON-RPC Batching
複数のリクエストをまとめて送る仕組みであるJSON-RPC Batchingが導入されました。JSON-RPC 2.0の仕様にはBatchingが定義されているものの、MCPの仕様では明確化されておらずJSON-RPCの仕様から外れた状態になっていたこともありこのタイミングで仕様書含め明記される様になりました。
例
[ {"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}, {"jsonrpc": "2.0", "id": 2, "method": "resources/list", "params": {}} ]
Tool Annotations
inputSchema/descriptionだけでは伝わりづらい動作特性(read‑only / destructive / sensitive など)を明示するためにTool Annotationsが追加されました。
これによりLLMがTool利用する際の判断基準がこれまでより明確になり、より場面にあったTool選択を適切に行える様になりました。
2025-06-18
2025-06-18では、セキュリティと相互運用性の強化、実装の簡素化を中心に改善が行われました。(Key Changes)以降はJSON-RPC Batchingの削除、Structured Tool Output、Elicitationの内容を抜粋し説明します。
JSON-RPC Batchingの削除
前バージョンである2025-03-26で「JSON‑RPC準拠」として導入されたバッチングですが、実運用面で採用が伸びず言語SDK・ストリーミングとの両立で実装の複雑さが増したため削除されました。
Structured Tool Output
Toolの結果を構造化データとして返せる機能が追加されました。これによりClientはレスポンスを検証可能になるためより型安全な運用が可能になります。
既存の仕様ではスキーマが固定されていなかったため柔軟なJSONパースが求められていましたが、型が厳密になるためレスポンスに応じたClientの動作を行うことが可能になります。
例
Tools - Model Context Protocol
Tool
{ "name": "get_weather_data", "title": "Weather Data Retriever", "description": "Get current weather data for a location", "inputSchema": { "type": "object", "properties": { "location": { "type": "string", "description": "City name or zip code" } }, "required": ["location"] }, "outputSchema": { "type": "object", "properties": { "temperature": { "type": "number", "description": "Temperature in celsius" }, "conditions": { "type": "string", "description": "Weather conditions description" }, "humidity": { "type": "number", "description": "Humidity percentage" } }, "required": ["temperature", "conditions", "humidity"] } }
Response
{ "jsonrpc": "2.0", "id": 5, "result": { "content": [ { "type": "text", "text": "{\"temperature\": 22.5, \"conditions\": \"Partly cloudy\", \"humidity\": 65}" } ], "structuredContent": { "temperature": 22.5, "conditions": "Partly cloudy", "humidity": 65 } } }
Elicitation
ServerがTool実行に必要な不足情報を、Client経由でユーザーに尋ねる機能です。Elicitationの内容としては単純に同意を求めるものから実際にemailなど文字列の入力を求めるものが可能です。
またStructured Tool Outputと組み合わせることでより柔軟な値を型安全に扱うことが可能です。
スキーマは下記の4つの型がサポートされています。
- String
- Number
- Boolean
- Enum
例
Elicitation - Model Context Protocol
下記の例はServerがユーザーに対して「名前」「メールアドレス」「年齢」の入力を求めるものになります。
Request
{ "jsonrpc": "2.0", "id": 2, "method": "elicitation/create", "params": { "message": "Please provide your contact information", "requestedSchema": { "type": "object", "properties": { "name": { "type": "string", "description": "Your full name" }, "email": { "type": "string", "format": "email", "description": "Your email address" }, "age": { "type": "number", "minimum": 18, "description": "Your age" } }, "required": ["name", "email"] } } }
Response
{ "jsonrpc": "2.0", "id": 2, "result": { "action": "accept", "content": { "name": "Monalisa Octocat", "email": "octocat@github.com", "age": 30 } } }
2025-11-25
最後にリリース予定の2025-11-25について実装にあたり特に意識する必要がありそうな点をまとめます。このバージョンについては現状まだ仕様がリリースされていないのでmcp blogを元に説明します。
非同期処理
現状の実装ではMCPは処理がすべて同期的に処理が行われます。しかし、すべてのToolの処理がすぐ終わるわけではなく大量のファイルの入出力などは膨大な時間を要します。これにより移行の処理がブロックされてしまう問題がありました。これらの問題やさらに長い時間を要する操作も可能にするために非同期処理の追加が提案されています。詳細についてはこちらのissueから確認することが可能です。
非同期処理の具体的な実行フローは下記が提示されています。
Clientがtools/listを用いてToolの発見行うtools/callを用いて非同期Toolの実行をリクエストする。この際にServerはバックグラウンドでの実行開始し、非同期処理を追跡するためのTokenをClientに返すClientはTokenを用いてtools/async/statusを呼び出し非同期処理の実行ステータスを取得する- 実行完了ステータスを取得後
Clientはtools/async/resultを呼び出し結果を取得する Serverはクリーンアップ処理を行う
公式拡張
MCPの成長に伴い特定の分野において、実装パターンが固まりつつあるようです。それらの内容を仕様に記述するのではなく今後は公式拡張という側面でプロトコル拡張機能として文書化していく方針が提示されています。これによって特定の分野におけるMCPの実装をより加速することが見込まれているようです。
まとめ
今回はMCPの正式リリースされたバージョン2024-11-05から次期リリースの2025-11-25の主要な変更点についてまとめました。JSON-RPC Batchの追加・削除のように利用しやすいよう柔軟に仕様を変更していく姿勢が利用者としては好感を持てるなと思いました。私自身Goの公式MCP SDKに関心があるので2025-11-25の仕様が確定次第改めて仕様の詳細確認して追っていこうと思いました。
また、blog末尾にTypescriptやSwiftのメンテナーが不足している旨が記述されていたので機会があったらチャレンジしてみたいです。
ここまで読んでいただきありがとうございます。MCPの仕様を追っている方の参考になったら幸いです。
参考資料
- 仕様 2024-11-05: spec.modelcontextprotocol.io/specification/2024-11-05
- 仕様 2025-03-26: spec.modelcontextprotocol.io/specification/2025-03-26
- 仕様 2025-06-18: spec.modelcontextprotocol.io/specification/2025-06-18
- 仕様 Draft: spec.modelcontextprotocol.io/specification/draft
- MCP Blog: blog.modelcontextprotocol.io
- SEP-1391(非同期の提案): github.com/modelcontextprotocol/modelcontextprotocol/issues/1391