Model Context Protocolで何ができますか？

• 要約ではなくスキーマを読む — プロトコルはschema/<revision>/schema.tsにTypeScriptで定義され、それを取り込めない処理系向けにJSON Schema版も公開されています。メッセージがどのフィールドを持つかという問いに対する正解は、各SDKのドキュメントではなくこのリポジトリ内のファイルです。
• 日付形式の改訂番号を把握する — 改訂番号はYYYY-MM-DD形式の文字列で、後方互換性を壊す変更が入ったときにだけ進みます。互換性を保つ改善はバージョンを動かさずに反映されます。現行の改訂は2026-07-28で、2025-11-25以前は初期化時のハンドシェイクでバージョンを決める世代にあたります。
• セッション単位ではなくリクエスト単位で折衝する — 2026-07-28以降、バージョンは全リクエストの_meta内にio.modelcontextprotocol/protocolVersionとして載り、Streamable HTTPではMCP-Protocol-Versionヘッダにも入ります。サーバーはリクエストごとに個別に受理・拒否し、拒否時は対応バージョンを列挙したUnsupportedProtocolVersionErrorを返します。対応バージョン、機能、識別情報を1往復でまとめて取得するserver/discoverも必須のRPCとして用意されています。
• コア機能を待たずに拡張を選ぶ — Tasksは長時間かかる処理に、状態の問い合わせと途中入力を伴う永続的なハンドルを与えます。MCP Appsは会話の中にグラフやフォーム、動画プレーヤーを直接描画します。認可まわりには、機械間認証と組織による集中管理の2つの拡張があります。拡張は既定で無効で、クライアントは各リクエストのio.modelcontextprotocol/clientCapabilitiesで、サーバーはserver/discoverの応答で対応を宣言します。両端が対応して初めて使えます。
• 安全性の強制をプロトコルに期待しない — 仕様書自身が、MCPはプロトコルの層でセキュリティ原則を強制できないと明記しています。ツールの注釈は、サーバーが信頼できる場合を除いて信頼できないものとして扱うべきだとされ、同意の取得はホスト側の責任です。どの利用者がどのツールを呼べるかは、実装するか、ゲートウェイに任せるかのどちらかになります。
• 動くコードは別リポジトリにある — このリポジトリにあるのは仕様とドキュメントだけです。リファレンス実装のサーバー群、コミュニティ運営のレジストリ、Python・TypeScript・Go・C#・Rust・Java・Kotlin・PHP・Swift・Rubyの公式SDKは、いずれも同じ組織の別リポジトリで、リリース時期もそれぞれ独立しています。新しい改訂への対応は改訂の公開より後になるため、実際にどの改訂で話せるかは採用するSDK次第です。