Model Context Protocol（MCP）は、JSON-RPC バッチングサポートを削除する一方で、重要なセキュリティ強化と新機能を導入する大幅な仕様更新をリリースした。この改訂は、プロトコル導入以来最も大きな変更の一つであり、開発者コミュニティ内でプロトコルの複雑さと実用的価値について議論を呼んでいる。
JSON-RPC バッチング削除に開発者が失望
JSON-RPC バッチングの廃止は、コミュニティから様々な反応を呼んでいる。この機能により、開発者は複数のリクエストをまとめて単一の操作として処理することができ、実用性は限定的だったものの、多くの開発者がエレガントだと感じていた。この削除は、仕様の簡素化に焦点を当てるプロトコル管理者の方針を反映しているが、一部の開発者は優れた技術的機能だと考えていたものへの懐かしさを表明している。
OAuth 統合による大幅なセキュリティ見直し
この更新では、MCP サーバーを OAuth リソースサーバーとして分類することで、包括的な OAuth セキュリティ対策を導入している。この変更により、MCP クライアントは RFC 8707 で規定されている Resource Indicators を実装し、悪意のあるサーバーが不正なアクセストークンを取得することを防ぐ必要がある。仕様には、強化されたセキュリティ考慮事項とベストプラクティスのドキュメントが含まれており、本番環境でのプロトコルのセキュリティモデルに対する懸念の高まりに対応している。
*RFC 8707：アクセストークンがどのリソースを対象としているかを指定する方法を定義する技術標準で、トークンの悪用防止に役立つ。
新機能がプロトコルの機能を拡張
プロトコルの機能性を向上させるため、いくつかの新機能が追加された。構造化ツール出力サポートにより、より整理されたデータ交換が可能になり、elicitation 機能により、サーバーはインタラクション中にユーザーから追加情報を要求できるようになった。ツール呼び出し結果のリソースリンクは、システムの異なるコンポーネント間のより良い接続性を提供する。
MCP 仕様アップデートにおける主要な変更点
削除された機能:
- JSON-RPC バッチング サポート
新しいセキュリティ機能:
- MCP サーバーの OAuth Resource Server 分類
- Resource Indicators 実装（ RFC 8707 ）要件
- 強化されたセキュリティ考慮事項ドキュメント
- 新しいセキュリティベストプラクティスページ
新機能:
- 構造化ツール出力サポート
- 追加ユーザー情報を要求するための Elicitation
- ツール呼び出し結果における Resource Links
- HTTP リクエストに対する MCP-Protocol-Version ヘッダー要件
スキーマ変更:
- 追加インターフェースタイプに
_metaフィールドを追加 CompletionRequestにcontextフィールドを追加- 人間にとって分かりやすい表示名のための
titleフィールド - Lifecycle Operation を SHOULD から MUST に変更
コミュニティがプロトコルの根本的価値に疑問
これらの改善にもかかわらず、開発者コミュニティは MCP の核となる価値提案について意見が分かれたままである。批判者は、従来の RPC 呼び出しや直接的な API 統合と比較して、プロトコルが不要な複雑さを追加していると主張している。特にバックエンド開発者は、各 API に対して個別のサーバーを必要とするアーキテクチャ決定に疑問を呈しており、シンプルな関数呼び出しで十分な場合に数百のマイクロサービスを作成する可能性があると見ている。
「MCP の誇大宣伝に乗っている間に得た最大の教訓の一つは、バックエンドソフトウェアを書いているなら、実際には MCP を行う必要がないということです。アーキテクチャ的に、それらは意味をなさないのです。」
支持者は、MCP が API コストを発生させることなく AI エージェントにツールを接続する標準化された方法を提供し、特に Claude ユーザーにとって有益であると反論している。彼らは、すべての人がリソースに対して直接コードを書くことができない、または権限がない環境でのプラグアンドプレイ統合システムとしての価値を強調している。
プロトコルの成熟度と採用の課題
仕様変更の急速なペースは、プロトコルの成熟度と安定性について疑問を提起している。一部の開発者は継続的な改善とコミュニティフィードバックへの対応を評価している一方で、他の開発者は各仕様改訂で複数の MCP サーバーを更新し続ける保守負担を心配している。OpenAPI などのより従来的な API ドキュメント形式ではなく、コア仕様に TypeScript を使用するプロトコルの依存も、型破りな選択として注目を集めている。
この議論は、AI ツールエコシステムにおける標準化についてのより広範な疑問と、既存のプロトコルがより少ない複雑さで同様の目的を果たすことができるかどうかを反映している。MCP が進化を続ける中で、その採用は、標準化の利点が異なるタイプのアプリケーションにとって認識される複雑さのコストを上回るかどうかに依存する可能性が高い。
参考：主要な変更点