目的
Claude Desktop が MCP 2026-07-28 に対応した時点で、ブリッジの Desktop 側(stdio サーバー面)をどう扱うか決める。
現時点の結論は「やる必要が無い」。ただし前提が変わりうるので、判断そのものを記録し、再検討のトリガーを置く。
前提
ブリッジは二面を持ち、両面は独立している。
| 面 |
実装 |
版 |
| Claude Desktop に対してサーバー |
SDK v1 stdio (new Server) |
2025-11-25 まで |
| Worker に対してクライアント |
手書き fetch |
2024-11-05 を宣言 |
Worker 側のステートレス移行(#224 / 姉妹 #249)は Desktop 側と無関係に実施できる。本 issue はその 残り半分を扱う。
新仕様の適用範囲(stdio に何が掛かるか)
「ステートレス化」は一枚岩ではない。仕様変更履歴を面ごとに切り分けると:
| 変更 |
適用範囲 |
stdio に掛かるか |
セッションと Mcp-Session-Id ヘッダの廃止 |
Streamable HTTP 限定と明記 |
掛からない(stdio に元から無い) |
initialize / notifications/initialized ハンドシェイク廃止、毎リクエスト _meta |
トランスポート指定なし = 全体 |
掛かる |
server/discover の実装必須 |
全体。変更履歴が STDIO を名指しで言及 |
掛かる |
つまり Desktop 側を移行する場合の作業は「セッション管理の撤去」ではなく、ハンドシェイクの撤去と server/discover の実装になる。
現時点の判断 — 移行しない
- 得るものが無い。 新仕様の動機はサーバーレス / エッジへのデプロイとスケール(Anthropic 告知)。stdio は 1 クライアント 1 プロセスであり、どちらの問題も存在しない
- 片側だけでは動かない。 Claude Desktop の実測値は
2025-11-25(Claude_1.25927.0.0 / リリース 2026-08-04 / バンドル内に "2026-07-28" 文字列なし)。いま変えると疎通しなくなる
- 強制されない。 旧リビジョン自体に廃止期限は無い(
feature-lifecycle の適用対象は features であり、リビジョンの寿命は versioning guide 側)。SDK v1 も仕様からの撤去とは別軸で存続しうる
したがって「Worker は新仕様、ブリッジは Desktop に対して旧仕様」という構成は、過渡期の妥協ではなく 恒久的に成立する形である。
再検討のトリガー
以下のいずれかが観測された時点で本 issue を開き直す。
- Claude Desktop / Claude Code が 2026-07-28 対応を出荷し、かつ 旧リビジョンの受け入れを打ち切る兆候が出た
@modelcontextprotocol/sdk v1 系がメンテナンス終了を告知した
- Desktop 側でのみ得られる新仕様の機能(MCP Apps / Tasks 等の拡張)を本 repo が必要とするようになった
3 つ目が最も現実的な発火経路と見ている。1 つ目は仕様の廃止ポリシー上、当面起きにくい。
制約
関連
参照
目的
Claude Desktop が MCP 2026-07-28 に対応した時点で、ブリッジの Desktop 側(stdio サーバー面)をどう扱うか決める。
現時点の結論は「やる必要が無い」。ただし前提が変わりうるので、判断そのものを記録し、再検討のトリガーを置く。
前提
ブリッジは二面を持ち、両面は独立している。
new Server)2024-11-05を宣言Worker 側のステートレス移行(#224 / 姉妹 #249)は Desktop 側と無関係に実施できる。本 issue はその 残り半分を扱う。
新仕様の適用範囲(stdio に何が掛かるか)
「ステートレス化」は一枚岩ではない。仕様変更履歴を面ごとに切り分けると:
Mcp-Session-Idヘッダの廃止initialize/notifications/initializedハンドシェイク廃止、毎リクエスト_metaserver/discoverの実装必須つまり Desktop 側を移行する場合の作業は「セッション管理の撤去」ではなく、ハンドシェイクの撤去と
server/discoverの実装になる。現時点の判断 — 移行しない
2025-11-25(Claude_1.25927.0.0/ リリース 2026-08-04 / バンドル内に"2026-07-28"文字列なし)。いま変えると疎通しなくなるfeature-lifecycleの適用対象は features であり、リビジョンの寿命は versioning guide 側)。SDK v1 も仕様からの撤去とは別軸で存続しうるしたがって「Worker は新仕様、ブリッジは Desktop に対して旧仕様」という構成は、過渡期の妥協ではなく 恒久的に成立する形である。
再検討のトリガー
以下のいずれかが観測された時点で本 issue を開き直す。
@modelcontextprotocol/sdkv1 系がメンテナンス終了を告知した3 つ目が最も現実的な発火経路と見ている。1 つ目は仕様の廃止ポリシー上、当面起きにくい。
制約
関連
参照