MCP仕様 – 2025-06-18版の変更点

 (modelcontextprotocol.io)
1 ポイント 投稿者 GN⁺ 2025-06-20 | 2件のコメント | WhatsAppで共有
  • MCP仕様の新しいアップデートは、構造化メタデータとコンテキスト管理に重点を置いている。目的は拡張性の向上と、さまざまなシステム間での相互運用性の強化
  • 新しいデータフィールドが追加され、既存の必須フィールドもより具体的に定義された。メタデータ構造の階層化により、システムごとの個別拡張方式をサポートできるようになった
  • コンテキスト追跡と属性更新のための明確なルールが提示され、従来よりも一貫した状態情報管理機能が重視されている
  • 権限管理およびデータ検証手順がプロトコル仕様に明記された。新たに追加された一部フィールドは、将来のプロトコルバージョンとの互換性を考慮したもの
  • クロスプラットフォーム統合をサポート: 複数のAIプラットフォームやクラウドサービス環境でも、一貫した方法でコンテキストデータを交換できる基盤を提供
  • MCP(Model Context Protocol)は、機械学習モデルや大規模言語モデルなど、さまざまなAIシステム間でコンテキストメタデータを交換するためのプロトコルである

Major changes

  1. JSON-RPCバッチ処理(batching)サポートを削除 (PR #416)
  2. 構造化ツール出力(structured tool output)サポートを追加 (PR #371)
  3. MCPサーバーをOAuthリソースサーバーとして分類し、保護対象リソースメタデータを追加して、連携するAuthorizationサーバーを見つけられるよう改善 (PR #338)
  4. MCPクライアントにRFC 8707のResource Indicator実装を必須化（悪意のあるサーバーによるアクセストークン取得の防止が目的） (PR #734)
  5. Authorization仕様内のsecurity considerationsおよびベストプラクティスを明確化し、別途セキュリティガイドページを追加
  6. Elicitation(追加情報の問い合わせ)機能を追加し、サーバーがユーザーに追加情報を要求できるようサポート (PR #382)
  7. Resource Linksサポートを追加し、ツール呼び出し結果にリソースリンクを含められるようにした (PR #603)
  8. プロトコルバージョン交渉時、HTTPでMCP-Protocol-Versionヘッダーを必須化 (PR #548)
  9. Lifecycle OperationのSHOULDをMUSTに変更 (参考)

Other schema changes

  1. _metaフィールドがより多くのインターフェース型に追加され (PR #710)、適切な使用方法 も明記された
  2. CompletionRequestにcontextフィールドを追加し、以前に解釈された変数を含められるようにした (PR #598)
  3. プログラム向け識別子とは別に、ユーザーフレンドリーな表示用のtitleフィールドを追加（nameはコード識別子用、titleは表示用） (PR #663)

関連記事

2件のコメント

 
kernel00 2025-06-20

Hacker News のコメントはちょっと物足りないですね。stdio しか見ていないのかもしれませんが、いまや remote MCP server や、それを仲介する registry がどれだけ雨後の筍のように増えていることか……
 
GN⁺ 2025-06-20
Hacker Newsの意見
  • MCP（Machine Context Protocol）ブームに乗って自分が最も強く学んだのは、バックエンドソフトウェア開発では別にMCPを使う必要はないということ。アーキテクチャ的に噛み合わない部分がある。特にElixirのような環境ではなおさらそう思う。APIごとにサーバーを別に置くなら、500個のAPIに500個のマイクロサービスを動かすことになる。実際に20種類のMCPサーバーを使ってみてから気づいたが、結局MCPも関数呼び出しの殻にすぎなかった。各APIはサーバーではなく個別のモジュールとして作れば十分。わざわざ最新のMCP仕様を追いかける必要も、仕様変更のたびに何百ものマイクロサービスを更新する必要もない。ただの不要な複雑性だという結論
    • クライアントがゲートウェイやBFFを通さず各マイクロサービスに直接つながるのでない限り、MCPをサービス全体の前段に置いて、API、GraphQL、RPCなど既存の方式のように機能だけ公開すればよい。実質的にはLLM特化のインターフェースという感じ。OpenAPI仕様ベースのtool callでも十分使える。いずれにせよ、すべてのマイクロサービス同士をMCPだけで通信させるのはさすがに過剰な発想
    • 自分はMCPを、ClaudeのようにAPIコストなしでfunction callを可能にするプラグイン型の統合ソリューション程度に見ていた。もしすでにAPIを使っていて急ぎの事情がないなら、わざわざ必要な選択肢ではない
    • 実際のところMCPは、クライアントとモデルをつなぐ標準プロトコルだと思う。単にツール呼び出しを包む容器ではない
    • その通りで、APIごとにMCPサーバーを1つずつ置く構成はスケールしない。nango.devのようなものを使えば、1台のサーバーで400以上のAPIをカバーできる。認証処理、可観測性の確保、そして直接tool callできるさまざまなインターフェースも提供している。（ちなみに自分は創業者）
    • 自分はさらに一歩進めて、LLMにJSON出力を強制する文化自体が愚かだと思っている。LLMがそもそも得意でもない厄介なフォーマットに合わせるために、時間も労力もかかりすぎる。もっと制約の強いテキストベースのDSLのほうが、はるかによい代替だった。昔のGPT 3.5の時代には、プロンプトに簡単な例をいくつか入れるだけで、英語ベースのDSLを信頼して出力させられた。なのに最新モデルでさえJSON schemaの一部をときどき無視するという注意書きが残っている。四角い穴に丸い釘を無理やり打ち込むような感じで、みんなそんな無理はしないでほしい
  • 認証済みMCPサーバーへのシンプルな道筋ができたのは本当にうれしい。MCPコミュニティとAnthropicチームには心から感謝したい
    • そもそもMCPサーバーがなぜ必要なのかよく分からない。エージェントがRPCをしたいなら、ただRPCを使えば十分ではないかと思う
  • 中核仕様がOpenAPIやほかの形式ではなくTypeScriptで書かれているのは本当に不思議に感じる。もっともな理由はあるのだろうが、それでも意外という印象
    • なぜそれが驚きなのか気になる。自分もTypeScriptはよく使うが、そういう観点で考えたことがなかったので、言語設計の面でどんな判断があったのか気になる
  • WWW-Authenticateチャレンジが導入されたのはとても喜ばしい。これでMCPサーバーがクライアントをリソース提供者のOAuthフローに送り、Authorization: Bearer ... ヘッダーを受け取ればよいという構図が明確になった
  • <i>大半は</i>不要な複雑性だと思うが、バッチ実行機能がなくなったのは残念。「この作業を全部やって、結果をまとめて一度に返す」という実装を作るのは面白かった。もちろんクライアント側で勝手にバッチ応答をまとめることもできるが、それでもやはり面白みがある
    • そう。JSON-RPCのバッチ機能は本当に「おお、これは面白いな」と思った体験だった。仕様から外れるのは残念だが、最終的には複雑性を増す面もあるので理解はできる
  • elicitation（推論ベースのプロンプト処理）は大きな収穫だと思う。自分が一番気に入っているMCPサーバーの1つは、自作のSSHサーバー。サーバー作業の90%を自動化できる。認証は設定ファイルで管理しているが、新しいサーバーに接続するたびに手で修正しないといけないので、少し面倒ではある
    • こういう場合はfabfile.orgのようなものも使えると思う。わざわざLLMを持ち込まなくてもよい会話なら、個人的な領域に留めておくほうがよいと思う
  • ここ数日、MCPでデータセットラッパーを作って遊んでみた経験
  1. LLM分野で最もワクワクする試みだと思う。もちろん既存のAPIやtool callでも似たことはできるが、技術に詳しくない友人にClaude用のMCP URLを渡すだけで、数クリックで試せるのはかなり印象的だった
  2. csharp SDKを使っているが、認証機能がまだブランチにしかなくてかなり初期段階。MCP統合では時間の95%が認証実装に消えた（ローカルビルドでないなら必須）。文書が増えれば改善されるだろうが、現状ではかなり手のかかる工程
  3. 開発者向けログの露出が足りないという問題もある。ClaudeがWeb版（デスクトップではなく）で何を送受信していて、どこでエラーが起きているのか、開発者モードでrequest/responseログを見せてほしい。認証更新の問題で長いこと悩んだが、自分が誤ったエンドポイントをログしていたことに気づくのが遅れた。もっとよいMCPロギングがあれば数分で終わっていた話だった。デスクトップ版とMCP inspectorではうまく動く
  4. 一番悩ましいのは長時間タスクの扱い。自分が公開しているデータセットは複数のPDF文書。Claude単体でPDFを扱うのは難しそうで（方法があるならぜひ教えてほしい！）、いったんgeminiを経由してテキストに変換し、それをMCPで渡している。短い文書はうまくいくが、長い文書は処理時間が長くなる。今は「処理中なので後でもう一度試してください」という案内を返しているだけ。progress APIはあるが、サーバーとの接続を維持し続ける必要があり（Cloudflare上では一定時間後に切れる）、実用性には限界があるように思う。LLMがx秒後に再確認し、それまでは別の作業をするようにできて、タイマーが終わるまで「実行を一時停止」するような仕組みがあれば本当に助かる。現状では接続維持中はLLMが何もできず待機状態になるか、あるいはjob IDを返して終えると不完全な応答しか出ず、全体の文脈が抜け落ちがち。10分以上かかる作業では大きな障害になりうると思う
  • 長時間実行タスクは、まだ公に議論が続いているテーマ。MCPも今後これを解決する意図があると理解している。いろいろな提案が出ていて、常に作業が長引くと分かるわけでもないので、長時間タスクAPIを分けるだけでは解決にならない。この点を統合的に解決しようという自分の提案もある discussionリンク
  • MCP仕様が急速に改善しているのはとてもうれしい。新しいリリースが出るたびに、自分がMCP統合で物足りないと感じていた部分が1つずつ埋まっていくのを確認できる
  • 仕様変更がマージされるのに承認がたった1回でよいという点が面白い
  • MCPが実際に何を解決しているのかよく分からない。個人的には、ノートブック上で何かを素早くプロトタイピングするときの役割くらいしか思い浮かばない。ローカルプログラムを作るなら、LLMがアクセスできるツールセットをもっと細かく制御したい。たとえばGoogle Calendar向けMCPサーバーを考えても、MCPが大きく時間を節約してくれるわけではない。同じAPIを自分で直接使うこともできるし、LLMにGoogle Calendarをいつどう呼ぶか明示的に教える必要もあるので、第三者に委ねたくない。また、MCPがどの言語で書かれているかにかかわらず、自分の環境で任意のプロセスを起動するのも負担だ。こちらがPythonなのに、ユーザーへ追加でTypeScriptランタイムを要求しなければならないなら困ることもある。MCPラッパーに脆弱性が生じたらセキュリティ上の懸念もある。サーバー環境では正当化がさらに難しい。異なるマシン同士で実装の詳細を知らなくても呼び出せる優れた方法なら、すでにRPCがある。MCPはその上に強い意見を持つミドルウェアとセキュリティ問題を足しているだけのように感じる
    • 自分が理解できないのは、これまで見てきたMCPがなぜすべてコマンドベースで、HTTPインターフェースを使っていないのかということ。HTTP方式ならサーバーを1台立てて組織全体で共有できるし、それぞれがツールチェーンを設定しなくても使える
    • バックエンドが固定フローを強制する従来方式と違って、MCPを使えばLLM自身が直接オーケストレーションを行えるのが利点。たとえばWeb検索なら、目的の情報が見つかるまでクエリを修正して再試行できる。CLIで特殊な問題を解くときも、複数のツールを適切な順序で使える。これは固定フローではできないオーケストレーション
    • MCPが解決するのは、LLM中心の世界でagentにtoolなどのさまざまな機能を標準化されたプロトコルで接続すること
    • そこには自分も強く共感する部分がある。実際に使ってみるとものすごく遅く感じる。自分は2年前にLLMクライアントを開発しようと仕事を辞めたのに、いまだにGoogle Calendar連携すらできていない。それでもユーザーの立場では、こうした一時的な穴を埋められるのがMCPの価値なのだと思う。昔、iPhoneのホーム画面は上3段は似ていても一番下の段だけは人によってまったく違っていたという話を思い出す。今後もIT部門や開発チームは、それぞれの業務に合わせたMCPサーバーを作り続けるだろうという予感がある