登場人物と、やりとりの形 ― ホスト・クライアント・サーバー

つなぐ相手1つにつき、クライアントを1つ作る

ここは最初に引っかかるところです。ホストは1つですが、クライアントはサーバーの数だけ作られます。ファイル用のサーバーに繋いだらクライアントが1つ、課題管理のサーバーにも繋いだらもう1つ増えます。

なぜ1つにまとめないのか。接続ごとに、話す相手も、使える機能も、資格情報も違うからです。1本の接続に混ぜると、どのサーバーが何を許されているのかが追えなくなります。

向きにも決まりがあります。サーバーからクライアントへリクエストを投げることはできません。リクエストを出すのは常にクライアント側で、サーバーが返すのは応答と通知だけです。サーバーが利用者に何か尋ねたいときは、応答の中で「入力が要る」と伝える形を使います。

手元で動くサーバーは普通1つのクライアントだけを相手にし、遠くのサーバーは多数のクライアントを相手にします。

MCPは2つの層でできている

MCPを読むときは、2つの層に分けて考えると一気に楽になります。

データ層（内側） は「何を話すか」です。道具の一覧の尋ね方、呼び出し方、結果の形。JSON-RPC 2.0 というルールに沿ったメッセージの中身が、ここに当たります。

トランスポート層（外側） は「どう届けるか」です。標準入出力で流すのか、HTTPで送るのか。接続の張り方、メッセージの区切り方、認証の載せ方が、ここに当たります。

大事なのは、内側は外側に影響されないことです。手元のプロセスで話していても、遠くのHTTPサーバーと話していても、tools/call の形はまったく同じです。だから運び方だけを後から差し替えられます。

仕様を読むときは「これはどっちの層の話か」を毎回問いましょう。混ざると理解が止まります。

データ層は JSON-RPC 2.0 で話す

やりとりの形は、JSON-RPC 2.0 という既存の決まりをそのまま使っています。新しい独自フォーマットを発明していない、というのが地味に効いています。

覚えることは3つだけです。

- リクエスト：method と params を送り、id を付ける
- レスポンス：同じ id を付けて result か error を返す
- 通知（notification）：id が無いもの。返事は来ないし、期待もしない

id が対応付けの鍵です。複数の呼び出しが同時に飛んでいても、id があるのでどの応答がどの依頼のものか分かります。

メッセージは UTF-8 で符号化しなければならないと決まっています。向きの制限もここに効きます。クライアントが送るのはリクエストと通知、サーバーが送るのは応答と通知です。

毎回のリクエストが、それだけで完結している

ここが 2026-07-28 版でいちばん変わったところです。MCPは状態を持たないプロトコルになりました。

どういうことか。リクエストの _meta に、次の情報が毎回入ります。

つまりサーバーは、前のリクエストを何も覚えていなくても、1通を見るだけで処理できます。

これは運用上かなり効きます。サーバーを複数台に並べても、どの台に届いても同じように処理できる。プロセスが再起動しても、クライアントは同じリクエストを投げ直すだけで済む。「接続が生きているか」を気にする設計が要らなくなります。

古い版を知っている人へ。以前は接続ごとにセッションがありました。いまは無い、と読み替えてください。

何ができるかは、尋ねれば分かる

相手が何をできるのかを知る入り口が server/discover です。すべてのサーバーが実装しなければならないリクエストで、返ってくるのはこんな内容です。

- supportedVersions — 受け付けられる版の一覧
- capabilities — 使えるもの（tools / resources / prompts と、変更通知に対応するか）
- serverInfo — 名前と版
- ttlMs / cacheScope — この答えをどれだけ使い回してよいか

面白いのは、呼ぶ側に義務が無いことです。どのリクエストにも版と能力が載っているので、いきなり tools/list を投げて、版が合わなければエラーで教えてもらう、という進め方もできます。server/discover は「1回でまとめて聞ける便利な入り口」という位置づけです。

答えはキャッシュできます。ttlMs が5分なら5分は聞き直さなくてよい、という意味です。毎回の問い合わせを減らせます。