MCP Servers v2.0.0、レガシークライアントを維持しつつモダンプロトコルをサポート

MCP Servers v2.0.0は、レガシークライアントのサポートを維持しながら、プロジェクトのリファレンスサーバーをモダンプロトコル向けにリファクタリングした。10月19日にリリースされたこの更新は、AIアプリケーションをツールやデータに接続するModel Context ProtocolであるMCPの異なる世代を橋渡しする。互換性の約束には明確な境界がある。旧来のクライアントは引き続きサポートされる一方、TypeScriptサーバーにはNode.js 24が必要になった。

この区別は、既存の統合を維持する開発者に負担をかける。クライアントが古いプロトコルを使用し続けられても、そのツールを支えるソフトウェアには新しいランタイムが必要となる場合がある。そのためアプリケーションチームは、サーバーパッケージ、実行環境、プロトコル動作について、それぞれ別個に判断する必要がある。

中心にある緊張関係は、モダナイゼーションと継続性の両立だ。メンテナーは、接続されるすべてのアプリケーションに同時移行を求めることなく、例示コードを新しいアーキテクチャへ移そうとしている。Claude Desktop、VS Code、あるいはカスタムAIアプリケーションを利用する開発者にとって、当面の問いは、この移行でどの前提が維持されるかにある。バージョン番号だけでなく、接続設定、ファイル権限、アプリケーション状態の存続期間にも注意を払う必要がある。

MCP Servers v2.0.0で実際に変わること

このリリースは、より広範なMCPコミュニティにあるすべてのサーバーではなく、定義されたリファレンス実装の集合を更新するものだ。

リリースパッケージ一覧では、バージョン2.0.0として公開された4つのTypeScriptパッケージが示されている。対象はEverything、Filesystem、Memory、Sequential Thinkingだ。TypeScriptは、JavaScriptに型チェックを追加するプログラミング言語である。

同じリリースには、Fetch、Git、Timeという3つのPythonパッケージも掲載されている。これらには日付ベースのバージョン2026.10.19が付与されている。リポジトリのリリースタグが各パッケージのバージョンになるわけではないため、チームが依存関係を棚卸しする際には、この違いが重要になる。

メンテナーはこの更新を、レガシークライアントへの応答を継続しながら、モダン仕様をサポートするリファクタリングだと説明している。これは、含まれるサーバーに関する実装上の主張である。関連のないコミュニティ統合や、MCP経由で接続するすべてのアプリケーションとの互換性を保証するものではない。

ここでは、複数のバージョン体系が別々に機能している。リポジトリのリリースはv2.0.0を使う一方、プロトコルは日付ベースの識別子を使う。パッケージバージョンは出荷されたソフトウェアを識別し、プロトコル識別子はそのソフトウェアが対応する通信ルールを表す。

これらの識別子を混同すると、アップグレードへの期待を誤らせかねない。2.0.0と表記されたパッケージをインストールしても、アプリケーションが自動的に新しいプロトコル機能をすべて採用するわけではない。クライアントが引き続き、サポートされる通信動作のうちどれを使用するかを決定する。

このため、MCPサーバーの互換性はコンポーネント間の関係として捉える必要がある。サーバーパッケージは複数のプロトコルリビジョンをサポートでき、接続先アプリケーションは以前のリビジョンを引き続き使用できる。逆に、新しいサーバーソフトウェアを導入しても、クライアントに欠けている機能を補うことはできない。

エンジニアリングマネージャーにとって、このリリースは可用性と準備完了を区別するうえで有用だ。公開されたパッケージは実装が利用可能であることを示す。準備完了かどうかは、周辺アプリケーション、起動環境、権限、期待される動作が連携するかに左右される。

実務的な意義は、これらのパッケージを直接実行する人々にとどまらない。リファレンス実装は、ほかの開発者が学び、改変する例を提供する。そのアーキテクチャ上の選択は、リファレンスパッケージ自体が本番の依存関係に入らなくても、カスタム統合に影響を及ぼし得る。

その影響については慎重な表現が必要だ。例はパターンを示せても、そのパターンがすべてのデプロイに適合することを証明するものではない。このリリースは具体的な実装材料を提供する一方、どの部分が自社システムに適合するかを判断する責任はアプリケーション所有者に残る。

したがって、このニュースはMCPが広く変更されたという発表よりも具体的なものだ。メンテナーは、新しいプロトコル動作と旧世代クライアントの既存基盤を接続する更新済みの例を出荷した。次の問いは、それらの例を実行するために必要なインフラに関わる。

旧来のクライアントはサポートされるが、旧来のランタイムは対象外

プロトコル互換性は、以前の実行環境を維持することを意味しない。

リリースのNode.js要件により、TypeScriptサーバーの最低Node.jsバージョンは24に引き上げられた。Node.jsは、ブラウザの外部でJavaScriptを実行するランタイムである。この変更はEverything、Filesystem、Memory、Sequential Thinkingに適用される。

関連するメンテナンス記録は、この要件に注意を要する理由を説明している。パッケージ宣言、ドキュメント、自動チェックは、それまで異なるサポート期待を示していた。この修正により、宣言された最低要件、ドキュメント、検証設定が新しいランタイムにそろえられた。

これは、ローカルAIアプリケーションにとって具体的な移行課題を生む。ユーザーはサーバーパッケージを更新しても、アプリケーションの起動環境を変更しないかもしれない。クライアントのプロトコルは受け入れ可能であっても、サーバーはそのプロセスで利用可能なランタイムに依存する。

開発環境とデスクトップアプリケーション環境が分かれた、例示的なエンジニアリングワークステーションを考えてみよう。端末で期待されるランタイムが報告されても、別の場所から起動されたアプリケーションは異なる設定を継承する可能性がある。端末で正常に実行できても、デスクトップアプリケーションが同じサーバーを起動できるかは判断できない。

この例は、リリースで報告された不具合ではなく、デプロイ時の考え方を示している。より広い含意は、新たな最低要件から直接導かれる。チームは、実際にパッケージを起動する環境についての証拠を得る必要がある。

最も直接的に影響を受けるのは、設定を配布する開発者、管理対象ワークステーションを維持する管理者、社内アシスタントをパッケージ化するチームだ。彼らの責任には、ツールが宣言するインターフェースだけでなく、ツールを起動するソフトウェアも含まれる。

こうしたチームにとって、後方互換性は調整作業を減らせても、それをなくすわけではない。必ずしも旧来のクライアントを直ちに書き直す必要はないが、新しいサーバーの要件は考慮しなければならない。

この違いは、障害の解釈も変える。起動できないプロセスは、実行中のサーバーがリクエストを拒否する場合とは別の問題だ。両方をプロトコル互換性の問題として扱うと、調査対象を誤ったコンポーネントに向けることになる。

同じ考え方はサポートドキュメントにも当てはまる。レガシークライアントが引き続きサポートされると書くなら、ランタイム要件に関する文脈を近くに置く必要がある。そうしなければ、読者はメンテナーが実際に示しているより広い約束を合理的に推測しかねない。

依存関係を選択したバージョンに固定するパッケージピン留めは、目に見える結果を伴う運用上の選択となる。チームは、予期しないパッケージ変更と環境変更を同時に起こすのではなく、新リリースを意図的に評価できる。

これは、更新を遅らせるべきだという一般論を示すものではない。更新する理由を区別する必要性を示している。モダンプロトコル動作を求めるチームと、既存ワークフローを維持するチームでは、直近の目的が異なる。

このリリースは両方のチームに前進する道を提供するが、その検証は異なる目的を反映すべきだ。旧来のクライアントを維持するなら継続的な動作を確認する。新しいクライアントを採用するなら、そのリクエストを処理するアーキテクチャも検討する必要がある。

互換性ブリッジはリクエストがコンテキストを保持する方法を変える

可視的なツールがなじみ深いままでも、新しいアーキテクチャでは通信コンテキストの置き場所が変わる。

現在のプロトコルバージョニング規則では、プロトコルリビジョンは2026-07-28となっている。リクエストは、リクエストに付随する説明情報であるメタデータを通じて、プロトコルバージョンを宣言する。サーバーはサポート対象バージョンに基づき、リクエストごとに受け入れまたは拒否する。

クライアントは、サーバーの識別情報、対応バージョン、機能を返すディスカバリーリクエストであるserver/discoverを使用できる。これより古いプロトコルリビジョンでは代わりに、接続の動作コンテキストを確立する最初のやり取りである初期化ハンドシェイクを使用する。

モダンプロトコル実装は、両方のアプローチをTypeScriptのリファレンスサーバーにもたらす。ローカル接続では、最初のメッセージがプロトコル世代を選択する。旧来のクライアントはinitializeで開始し、モダンクライアントはディスカバリーまたは新しいリクエストメタデータを使用する。

この実装では、セッション識別子で索引付けされたサーバー状態からも移行している。接続固有の状態はサーバーインスタンス上に置かれる。モダンなリクエストをまたいで保持する必要がある情報には、その情報を参照するためにサーバーが発行する識別子であるハンドルを使用する。

「ステートレス」は誤解されやすいため、これらの詳細は重要だ。プロトコルセッションへの依存をなくすことは、アプリケーションが各リクエスト後にすべてを忘れることを意味しない。情報がどこに存在し、後続の処理がそれをどのように参照するかを、開発者が明示的に特定する必要があるということだ。

カスタム統合では、この違いがアーキテクチャレビューに影響する。開発者は、リクエストに属する情報と、接続に属する情報、または保存済みアプリケーションデータを分ける必要がある。それらの存続期間は一致するとは限らない。

プロジェクトに関する事実を保持するアシスタントには、ツールが一時的な進捗を保持する場合とは異なる要件がある。永続的な情報は、製品のストレージ規則に従って存続すべきだ。一時的な情報は、意図された操作または対話の期間だけ利用可能であるべきだ。

Memoryサーバーはこの違いを示している。エンティティを関係性で接続する構造であるナレッジグラフは、永続的な情報を提供する。そのドキュメントでは、基盤となるツールとリソースを維持しつつ、モダンおよびレガシークライアント向けに異なるサブスクリプション機構が説明されている。

サブスクリプションとは、情報が変化した際に更新を受け取るためのリクエストである。重要なプロダクト上の問いは、アプリケーションがそれらの更新を受け取り続けるかどうかだ。最初の読み取りが成功しても、後の変更が期待どおりに表示されることは確認できない。

Sequential Thinkingは、別の存続期間の違いを示す。そのドキュメントでは、どちらのプロトコル世代でも、思考履歴が接続の間存続すると説明されている。この動作は、永続メモリ一般を約束するものではなく、ツールの作業コンテキストに関するものだ。

Everythingはさらに異なる目的を担う。モダンなリクエストおよび通知動作を含め、クライアント構築者向けにプロトコル機能を検証する。その価値は、単純なツール呼び出しの成功だけでは検証されない統合動作を可視化することにある。

これらの例を総合すると、MCPサーバーの移行がインポートやパッケージ名の変更だけにとどまらない理由が分かる。目に見える機能は認識可能なままでも、周辺の通信モデルは変わり得る。リファレンスコードを適応する開発者は、両方の層を理解する必要がある。

そこにこそ、この互換性アプローチの意義がある。旧来のクライアントをサポートすることで、アプリケーションチームは時間を確保できる。しかし、新しい動作を採用する前に、新しいアーキテクチャを理解する必要までなくなるわけではない。

ファイルシステムアクセスは動作上の違いを具体化する

同じサーバーパッケージでも、クライアントのプロトコル世代によって必要な権限設定は異なり得ます。

Filesystem serverは、その挙動がツールからアクセスできるローカルディレクトリを左右するため、最も分かりやすい例です。許可リストとは、アクセスを許可する場所を明示的に定めたものです。サーバーのモダンな接続では、プロセス起動時に指定されたディレクトリを使用します。

タグ付きのディレクトリアクセス制御ドキュメントでは、プロトコルのバージョンを問わず、これらの起動引数を推奨しています。古いクライアントでは、ファイルシステム上の場所を記述するクライアント提供の仕組みであるRootsも使用できます。モダンな接続では、このレガシー情報を要求しません。

したがって、許可済みディレクトリを指定せずに起動したサーバーは、接続経路によって異なる挙動を示します。モダンなツール呼び出しでは、ディレクトリ設定の不足を説明するエラーがドキュメントで示されています。プロセスに接続しただけでは、実用的なファイルアクセスは確立されません。

レガシークライアントについては、ドキュメントにアクセス権の更新と取り消しも記載されています。Rootsの更新が保留中の場合、ツール呼び出しは待機します。クライアント提供のルートが有効になった後、有効なルートを含まない更新が行われると、有効なルートが戻るまでアクセスは失われます。

製品面での意味は明快です。接続の成功と権限付与の成功は別の結果です。クライアントは、対象ファイルへの有効な経路がなくても、サーバーを検出し、そのツールを認識できます。

たとえば、エンジニアがローカルの設計文書を比較するのを支援するアシスタントを考えてみましょう。クライアントのアップグレード前後で、ユーザーの依頼文は同一に聞こえます。しかし、アプリケーションは異なるプロトコル経路に入り、異なる設定要件に直面する可能性があります。

従来の構成がクライアント提供のRootsに依存していた場合、モダンな経路への移行では起動時のディレクトリ指定に注意が必要です。ユーザーの言葉だけから、この依存関係は分かりません。ファイル操作が存在することを示すツール一覧からも同様です。

だからこそ、権限は脚注ではなく移行分析に含めるべきです。ファイルアクセスは、プロトコルの挙動とユーザーの期待を直接結び付けます。設定の不一致は、ユーザーには知識不足や、アシスタントが依頼を理解できていない問題として映る可能性があります。

また、トラブルシューティングを複雑にすることもあります。根本的にはツールが意図した場所へアクセスできないにもかかわらず、チームが情報検索の品質、すなわちソフトウェアが関連情報をどれほど効果的に見つけられるかを調査するかもしれません。リリースのドキュメントは、こうした可能性を切り分ける助けになります。

ナレッジワークフローでは、チームはコネクターのアクセス境界と、そこから得られる情報システムの品質を区別すべきです。検索可能なナレッジベースは、関連文書が利用可能であり、整理され、検索可能であることに依存します。プロトコル対応は、その連鎖の一部にすぎません。

この例は、開発者が後方互換性から推論すべき範囲も示しています。レガシー動作が継続していても、モダンクライアントで同一の権限設定が使えるとは限りません。両方の経路をサポートしながら、異なる仕組みに依存することは可能です。

アシスタントを評価する組織にとって、この違いは具体的な購買上の問いを生みます。アクセス可能な場所を定義するのはどのコンポーネントであり、アプリケーションは不足または取り消されたアクセスをどのように伝えるのでしょうか。回答では、対応規格を列挙するだけでなく、実際の挙動を説明すべきです。

リファレンス実装がその境界を文書化しているため、このリリースによってこの問いは調査しやすくなっています。他の統合については、依然としてそれぞれ独自の根拠が必要です。プロトコル名を掲げるだけでは、同等のアクセスルールを適用していることにはなりません。