Solutions Choose your path
For individuals Build, learn, and create with simple usage-based access. For business Scale teams, billing, governance, and model workflows. More English 繁體中文 日本語 한국어 Français Deutsch Español Italiano Português Русский العربية ไทย Tiếng Việt Bahasa Indonesia Bahasa Melayu Türkçe Polski Nederlands Danish Norsk Қазақ اردو
無料で始める 無料で始める
500+ AI Model API, All In One API.
Just In CometAPI © 2026 CometAPI · All rights reserved
Home Blog MCP 2026-07-28 移行ガイド: ステートレスサーバー MCP 2026-07-28 移行ガイド: ステートレスサーバー - CometAPI
technology / CometAPIリサーチ
MCP 2026-07-28 移行ガイド: ステートレスサーバー MCP 2026-07-28 への移行方法について、ステートレスなトランスポート、MRTR、ルーティングヘッダー、キャッシュ、OAuth の変更点、SDK のアップグレードを含めて学ぶ
MCP 2026-07-28 への移行方法について、ステートレスなトランスポート、MRTR、ルーティングヘッダー、キャッシュ、OAuth の変更点、SDK のアップグレードを含めて学ぶ
この要約で素早く答えを把握し、ガイドで背景、例、実装詳細を確認してください。
from openai import OpenAI
client = OpenAI(
api_key="YOUR_COMETAPI_KEY",
base_url="https://api.cometapi.com/v1",
)
response = client.chat.completions.create(
model="gpt-5-mini",
messages=[{"role": "user", "content": "Build this workflow."}],
)
print(response.choices[0].message.content)要約: MCP 2026-07-28 はプロトコルレベルのセッションと必須の初期化ハンドシェイクを削除しました。プロダクションチームは隠れたセッション依存を見つけ、リクエスト単位のプロトコルメタデータを採用し、Multi Round-Trip Requests（MRTR）を実装し、ゲートウェイポリシーを更新し、レガシー動作を廃止する前に新プロトコルをカナリア展開してください。
2026年7月28日にリリースされた Model Context Protocol 仕様は、リモートトランスポート対応が追加されて以来、MCP における最大のアーキテクチャ変更を導入しました。
プロトコルはステートレスなリクエスト／レスポンスコアを採用しました。必須だった initialize および notifications/initialized のやり取りは削除され、Mcp-Session-Id は廃止され、各リクエストが処理に必要なプロトコル情報を持ち運びます。
同時に、Multi Round-Trip Requests、HTTP ルーティングヘッダー、キャッシュ可能な一覧レスポンス、より厳格な認可挙動、拡張フレームワーク、正式な非推奨ライフサイクルも導入されています。プロトコルレベルの詳細は、
明確性、出典の帰属、最新のAPI用語について確認済みです。
これらの変更により、標準的な HTTP インフラの背後でリモート MCP サーバーをスケールしやすくなります。ただし、既存アプリケーションが自動的にステートレスになるわけではありません。
本番サーバーは依然として、メモリ内ワークスペース、スティッキーなルーティング、セッションに紐づく認証情報、長寿命のストリーム、サーバー主導の対話などに依存している可能性があります。本ガイドは、それらの依存を見つけて置き換えることに焦点を当てます。
誰が移行する必要があるか？ 必要な作業量は、システムにおける MCP の使われ方によって異なります。
ワンショットツールのみのローカル stdio サーバー 低 SDK をアップグレードし、プロトコルネゴシエーションをテスト リモート HTTP サーバー（リクエスト間の状態なし） 中 最新メタデータ、ディスカバリ、HTTP ヘッダーを追加 業務状態に Mcp-Session-Id を使用するサーバー 高 隠れた状態を明示的ハンドルまたは共有ストレージに置換 ルーティングのために JSON-RPC ボディを解析するゲートウェイ 中～高 MCP ルーティングヘッダーの追加と検証 呼び出し途中に情報取得や承認を要求するツール 高 対話を MRTR に移行 Dynamic Client Registration を使うクライアント 高 発行者ハンドリングを強化し CIMD に備える レガシーの HTTP+SSE を使用するサーバー 高 Streamable HTTP へ移行 実験的 Tasks を使うワークフロー 高 公式の Tasks エクステンションを採用
リクエスト間の状態を保持しないローカルサーバーは、SDK のアップグレードと互換性テストのみで済む可能性があります。
セッション、OAuth、ストリーミング、サーバー主導のリクエストを使用するリモートデプロイでは、段階的な移行が必要です。
MCP 2026-07-28 で何が変わったか？ 初期化 必須の initialize ハンドシェイク 必須ハンドシェイクなし モダンリクエストの初期化ゲートを削除 セッション Mcp-Session-Id プロトコルレベルのセッションなし 必要な状態を明示化 ディスカバリ 初期化中にネゴシエート 任意の server/discover 呼び出し ディスカバリとバージョンネゴシエーションを実装 リクエストコンテキスト 接続上に保存 リクエストの _meta に含める リクエストごとにプロトコルメタデータを送信 HTTP ルーティング ゲートウェイが JSON ボディを解析 Mcp-Method と Mcp-Name ヘッダー ルーティング・ポリシー・可観測性を更新 呼び出し途中の対話 サーバー発の JSON-RPC リクエスト Multi Round-Trip Requests input_required とリトライに対応 一覧のキャッシュ カタログを繰り返し取得 ttlMs、cacheScope、決定的順序 認可対応キャッシングを追加 通知 GET ストリームとリソース購読 subscriptions/listen 変更通知を新ストリームへ移行 認可 DCR 中心の登録 より強い発行者ルールと CIMD 方向性 OAuth クライアントと資格情報保管を監査 長時間処理 コアの実験的 Tasks io.modelcontextprotocol/tasks 拡張 拡張コントラクトへ移行
1. 既存実装の監査 アップグレード前に、クライアント、サーバー、ゲートウェイ、デプロイ設定から古いプロトコル前提を検索します。
Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID
初期化完了までサーバーは呼び出しを拒否しているか？
セッション ID はユーザー、資格情報、ワークスペース、会話の選択に使われているか？
別のサーバーインスタンスが、最初のインスタンスが開始したワークフローを継続できるか？
ロードバランサーはセッションアフィニティを要求しているか？
ツールは確認を要求する前に副作用を実行していないか？
ゲートウェイはメソッドやツールの識別にボディを解析していないか？
OAuth 資格情報は発行した認可サーバー情報なしで保存されていないか？
クライアントは SSE の再接続やメッセージ再配送に依存していないか？
ツールやリソースの一覧は接続ごとに変わらないか？
どの非推奨機能が本番トラフィックを受けているか？
アプリケーションが Mcp-Session-Id の背後に何を保存しているかを理解するまでは、Mcp-Session-Id を削除しないでください。
ヘッダーを削除しながら状態をローカルメモリに保持したままのサーバーは、開発中は動作しても、複数インスタンスにリクエストが分散されると断続的に失敗する可能性があります。
2. 隠れたセッション状態の置換 MCP 2026-07-28 で削除されるのはプロトコルレベルのセッションであり、アプリケーション状態ではありません。
呼び出し間で必要な状態は、次のいずれかのパターンを使用してください。
明示的ハンドル あるツールからサーバー発行のハンドルを返し、後続の呼び出しでそれを必須引数にします。
{
"resultType" : "complete" ,
"content" : [
{
"type" : "text" ,
"text" : "Workspace created."
}
] ,
"structuredContent" : {
"workspaceHandle" : "ws_7f93a2"
}
}
後続のリクエストは通常の引数としてハンドルを渡します：
{
"name" : "update_workspace" ,
"arguments" : {
"workspaceHandle" : "ws_7f93a2" ,
"status" : "approved"
}
}
これにより依存がツールコントラクトで可視化され、互換性のある任意のサーバーインスタンスがリクエストを処理できるようになります。
共有ストレージ 以下の場合はデータベース、分散キャッシュ、オブジェクトストア、耐久タスクシステムを使用します：
複数のワーカーが同一状態を必要とする
ワークフローが再起動に耐える必要がある
ハンドルには大きすぎる状態である
ワークフローが単一リクエストより長い
トランザクションまたは単回使用の挙動が必要
保護された requestState MRTR は、不透明な requestState 値を返し、クライアントは元のリクエストを再試行する際にそれをエコーできます。
この値はクライアントを経由するため、HMAC または認証付き暗号で保護してください。認証済みプリンシパル、元の操作、重要なパラメータ、有効期限、リプレイ防止が必要な場合はノンスにバインドします。
クライアントが変更せずに返したという理由だけで、署名されていない requestState を信用しないでください。
3. 自己完結型リクエストとディスカバリの採用 最新の MCP リクエストは、プロトコルコンテキストを _meta に含みます。
Streamable HTTP のツール呼び出しは次のようになります：
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
"jsonrpc": "2.0",
"id": "req-101",
"method": "tools/call",
"params": {
"name": "search",
"arguments": {
"query": "stateless MCP migration"
},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "example-client",
"version": "2.0.0"
},
"io.modelcontextprotocol/clientCapabilities": {
"elicitation": {}
}
}
}
}
新しいプロトコルを対象とするサーバーは server/discover を実装し、対応バージョン、機能、サーバーアイデンティティを広告する必要があります。クライアントは別の操作の前に呼び出したり、レガシーフォールバックが必要かどうかの判断に使えます。
レスポンスコントラクトは、公式の server/discover documentation を参照してください。
TypeScript SDK のバージョンネゴシエーション TypeScript SDK のアップグレードのみでは、クライアントが新プロトコルへ自動移行されるわけではありません。
v2 SDK を使うクライアントは明示的にオプトインする必要があります：
const client = new Client (
{
name : "my-client" ,
version : "1.0.0"
},
{
versionNegotiation : {
mode : "auto"
}
}
);
await client.connect (transport);
自動モードでは、SDK は server/discover でプローブし、レガシーサーバーに到達した場合は古い初期化フローへフォールバックできます。
4. サーバー発リクエストを MRTR に置換 従来の MCP 実装では、elicitation/create、sampling/createMessage、roots/list のようなリクエストをサーバーからクライアントに送信できました。
新プロトコルはこのモデルを Multi Round-Trip Requests に置き換えます。
クライアントが元のリクエストを送信する。
サーバーが resultType: "input_required" を返す。
クライアントが要求された情報または承認を収集する。
クライアントが新しい JSON-RPC ID を使って元の操作を再試行する。
再試行には inputResponses と元の requestState を含める。
サーバーがリクエストを完了させるか、次のラウンドを開始する。
{
"jsonrpc" : "2.0" ,
"id" : "delete-1" ,
"result" : {
"resultType" : "input_required" ,
"inputRequests" : {
"confirm_delete" : {
"method" : "elicitation/create" ,
"params" : {
"mode" : "form" ,
"message" : "Delete project project_123?" ,
"requestedSchema" : {
"type" : "object" ,
"properties" : {
"confirmed" : {
"type" : "boolean"
}
} ,
"required" : [ "confirmed" ]
}
}
}
} ,
"requestState" : "protected-expiring-state"
}
}
{
"jsonrpc" : "2.0" ,
"id" : "delete-2" ,
"method" : "tools/call" ,
"params" : {
"name" : "delete_project" ,
"arguments" : {
"projectId" : "project_123"
} ,
"inputResponses" : {
"confirm_delete" : {
"action" : "accept" ,
"content" : {
"confirmed" : true }
}
} ,
"requestState" : "protected-expiring-state"
}
}
本番の MRTR 実装では、以下を定義してください：
最大ラウンド数
リクエスト状態の有効期限
キャンセルと拒否の挙動
レスポンススキーマ検証
すべての再試行における認可チェック
リプレイ防止
副作用のべき等性
クライアントが要求機能をサポートしない場合の挙動
購入、削除、クレジット控除、外部書き込みを input_required を返す前に完了させることは避けてください。
段階的な操作や冪等性キーを使用し、再試行でアクションが重複しないようにします。完全な対話モデルは公式のMRTR 仕様 を参照してください。
5. ゲートウェイ、キャッシュ、認可の更新 インフラ変更は密接に関連しているため、まとめてテストするべきです。
MCP ルーティングヘッダーの検証 Streamable HTTP の POST リクエストには次が含まれます：
MCP-Protocol-VersionMcp-MethodMcp-Name これらのヘッダーにより、ゲートウェイはすべての JSON ボディを解析せずにトラフィックをルーティング、メータリング、認可、レート制限できます。
ツール固有のレート制限
一覧系と実行系メソッドのポリシー分離
高コストツール向けの専用ワーカープール
高リスク操作へのアクセス制限
ツールごとのレイテンシ／エラーメトリクス
インフラコストのアトリビューション
これらの値はクライアントが供給する点は変わりません。ポリシー適用前に JSON-RPC ボディと照合してください。
Mcp-Name で低リスクツールを装いながら、ボディで別ツールを呼び出すようなリクエストは許容してはいけません。ヘッダーとボディの不一致は拒否し、ログに記録すべきです。
認可対応のキャッシュキーを使用 新プロトコルでは、次のキャッシュ可能な結果に ttlMs と cacheScope が追加されました：
tools/listprompts/listresources/listresources/templates/listresources/read protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
TTL が未満でも、ユーザーやテナントをまたいでプライベートキャッシュエントリを再利用しないでください。
決定的なツール順序も重要です。安定したカタログは不要なキャッシュミスを避け、ツール定義をプロンプトに挿入する場合にモデルのプロンプトキャッシュ再利用を改善する可能性があります。
OAuth 発行者ハンドリングの強化
返却された iss を、そのフローで記録した発行者と照合して検証
保存するクライアント資格情報を発行者でキーイング
資格情報を他の認可サーバーで再利用しない
DCR 中に適切な application_type を設定
新規統合で Client ID Metadata Documents に備える
Dynamic Client Registration は後方互換のために利用可能ですが、推奨登録方法としては非推奨です。
6. 通知、Tasks、非推奨機能の移行 従来の HTTP GET 通知パスと resources/subscribe／resources/unsubscribe は subscriptions/listen に置き換えられました。
クライアントは長寿命の POST レスポンスストリームを開き、必要な通知カテゴリにオプトインします。リクエスト固有の進捗とログ通知は、それを記述するリクエストのレスポンスストリームに紐づいたままです。
マルチインスタンスデプロイでは、あるサーバーインスタンスで生成された通知が別のインスタンスに接続された購読に届く必要がある場合、共有イベントバスを使用します。
Tasks 拡張 長時間処理はコアの実験的プロトコルから次へ移動しました：
io.modelcontextprotocol/tasks
tasks/get によるポーリングtasks/update によるクライアントからサーバーへの更新耐久タスクハンドル
subscriptions/listen によるオプトイン更新 従来の tasks/result と tasks/list パターンは新実装に持ち込まないでください。
非推奨機能 Roots ディレクトリはツール引数、リソース URI、設定で渡す 必須ハンドシェイクなし モダンリクエストの初期化ゲートを削除 Sampling モデルプロバイダ API と直接統合 プロトコルレベルのセッションなし 必要な状態を明示化 Logging 開発は stderr（stdio）、本番は OpenTelemetry を使用 任意の server/discover 呼び出し ディスカバリとバージョンネゴシエーションを実装 Dynamic Client Registration Client ID Metadata Documents へ移行 リクエストの _meta に含める リクエストごとにプロトコルメタデータを送信 レガシー HTTP+SSE Streamable HTTP へ移行 Mcp-Method と Mcp-Name ヘッダー ルーティング・ポリシー・可観測性を更新 非推奨 includeContext 値 フィールドを省略するか "none" を使用 Multi Round-Trip Requests input_required とリトライに対応 一覧のキャッシュ カタログを繰り返し取得 ttlMs、cacheScope、決定的順序 認可対応キャッシングを追加 通知 GET ストリームとリソース購読 subscriptions/listen 変更通知を新ストリームへ移行 認可 DCR 中心の登録 より強い発行者ルールと CIMD 方向性 OAuth クライアントと資格情報保管を監査 長時間処理 コアの実験的 Tasks io.modelcontextprotocol/tasks 拡張
非推奨機能は非推奨期間中は利用可能ですが、新規実装で採用すべきではありません。MCP のライフサイクルポリシーは、最低12か月の非推奨期間を提供しますが、すべての機能の確定削除日が同一であることを意味しません。
7. 安全な移行のロールアウト クライアント、サーバー、ゲートウェイ、キャッシュ、認可を、観測なしの1リリースで変更しないでください。
推奨移行順序
プロトコルバージョン、SDK、セッション、SSE トラフィック、DCR クライアント、非推奨メソッドの棚卸し
非本番 SDK のアップグレード
server/discover とバージョンネゴシエーションの追加隠れたセッション依存の置換
MRTR の実装とセキュリティ対策
検証済みルーティングヘッダーとスコープ付きキャッシュの追加
認可発行者境界のテスト
レガシーパスと並行してモダンプロトコルをカナリア展開
テレメトリの確認後にのみ旧挙動を廃止
カナリア中の互換性 Modern client + modern server
→ Use MCP 2026-07-28
Modern client + legacy server
→ Probe and fall back when supported
Legacy client + dual-version server
→ Continue on the legacy path
Unsupported combination
→ Return a clear protocol-version error
新しい MCP 仕様のリリースは、エコシステム全体の一斉切り替えではありません。クライアント、サーバー、SDK、ホストプラットフォームは異なる速度で移行します。
記録すべきテレメトリ リクエストごとのプロトコルバージョン 採用状況と非互換な組み合わせ ディスカバリ成功率とフォールバック率 バージョンネゴシエーションの挙動 欠落または不正な MCP ヘッダー 古いクライアントまたはゲートウェイの不具合 ヘッダー／ボディ不一致 クライアントのバグまたはポリシー回避試行 MRTR の要求と完了 対話型ワークフローの信頼性 MRTR の拒否またはタイムアウト ユーザーとクライアントの失敗パス リクエスト状態の検証失敗 改ざん、リプレイ、期限切れ 重複操作の防止 冪等性制御の有効性 スコープ別キャッシュヒット率 安全なトラフィック削減 発行者検証の失敗 OAuth 構成の問題 HTTP+SSE トラフィック 残るトランスポート移行作業 非推奨メソッドのトラフィック 廃止計画の根拠 ツールのレイテンシと受理タスク率 ユーザーが見える信頼性
成功するワンショットの tools/call だけでは移行を測定できません。繰り返しタイムアウトし、不必要な入力を要求し、外部書き込みを重複させるワークフローは、本番では依然として失敗です。
MCP はモデル API の代替ではありません。両レイヤーは異なる統合課題を解決します。
MCP エージェントをツール、リソース、プロンプト、承認、タスクに接続 統一モデル API アプリケーションをモデル、認証情報、使用量、課金に接続 アプリケーションオーケストレーション モデルやツールの呼び出しタイミングと方法の決定
Application or agent
↓
MCP clients and servers
Tools, resources, approvals, tasks
↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models
MCP は、エージェントがツールやコンテキストと対話する方法を標準化します。モデルの価格、プロバイダ資格情報、推論エンドポイント、プロバイダフェイルオーバーは標準化しません。
この分離は、非推奨となった Sampling 機能から移行する際に特に有用です。MCP サーバーまたはそれを消費するエージェントが引き続きモデル推論を必要とする場合、アプリケーションは旧来の MCP Sampling フローに依存するのではなく、モデル API を直接呼び出せます。
統一モデルゲートウェイが役立つ場面 統一モデルゲートウェイは、次の場合に運用作業を減らせます：
複数の MCP サーバーが異なるモデルプロバイダへのアクセスを必要とする
ツールごとに異なるモデルが必要
プロバイダ固有の統合を書き直すことなくモデルを切り替えたい
資格情報、使用量、課金を一元管理したい
MCP トランスポート変更からモデルアクセスを独立させたい
CometAPI は OpenAI 互換エンドポイントを提供し、MCP アプリケーション背後のモデルアクセス層として使用できます。これにより、モデルプロバイダロジックを MCP のツール・リソース・タスクオーケストレーションから切り離せます。
例えば、MCP ツールはアプリケーションの他の場所で使用しているのと同じ OpenAI 互換クライアントを通じてモデルを呼び出せます：
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.COMETAPI_KEY,
baseURL: "https://api.cometapi.com/v1"
});
export async function summarizeResource(content: string) {
const response = await client.chat.completions.create({
model: "your-selected-model",
messages: [
{
role: "system",
content: "Summarize the supplied resource clearly and concisely."
},
{
role: "user",
content
}
]
});
return response.choices[0]?.message?.content ?? "";
}
MCP サーバーはツールコントラクト、認可、状態、結果処理を担当します。モデルゲートウェイはモデル選択、プロバイダアクセス、推論レスポンスを担当します。
これらのレイヤーを分離することで、実務上の利点が2つあります：
MCP クライアントとサーバーは、モデル統合レイヤーを変更せずに新プロトコルへ移行できる。
モデルプロバイダを変更しても、MCP ツールやトランスポートの設計を改める必要がない。
MCP 2026-07-28 移行チェックリスト
クライアント
互換 SDK にアップグレード
最新のバージョンネゴシエーションを有効化
server/discover をサポートすべてのリクエストにプロトコルメタデータを含める
resultType を処理MRTR をサポート、または明示的に拒否
再試行では新しい JSON-RPC ID を使用
requestState を保持して返却OAuth 発行者を検証
資格情報を発行者単位で保管
キャッシュヒントに従う
必要に応じて subscriptions/listen をサポート
サーバー
モダンリクエストの初期化ゲートを削除
Mcp-Session-Id への依存を除去server/discover を実装隠れた状態をハンドルまたは共有ストレージに置換
resultType を返却サーバー発リクエストを MRTR に置換
requestState を保護すべての inputResponses を検証
副作用に冪等性を追加
決定的な一覧を返却
控えめなキャッシュヒントを公開
長時間処理を Tasks 拡張へ移行
ゲートウェイとインフラ
MCP リクエストヘッダーを検証
ヘッダーとボディを照合
不要なスティッキールーティングを削除
複数インスタンス間でリクエストをテスト
認可境界でキャッシュを分割
必要な場合は共有通知バスを追加
レガシー／非推奨トラフィックを追跡
カナリア中のロールバックパスを維持
FAQ
MCP 2026-07-28 とは？ MCP 2026-07-28 は 2026年7月28日にリリースされた Model Context Protocol 仕様です。ステートレスなプロトコルコア、Multi Round-Trip Requests、HTTP ルーティングヘッダー、キャッシュ可能な結果、認可変更、拡張、正式な非推奨ライフサイクルを導入します。
Mcp-Session-Id は削除されたか？はい。新しい Streamable HTTP プロトコルでは Mcp-Session-Id は使用しません。
アプリケーションは、明示的ハンドル、共有ストレージ、耐久タスク、保護されたリクエスト状態値を通じて状態を保持できます。
MCP の初期化ハンドシェイクは削除されたか？ はい。最新のリクエストでは initialize と notifications/initialized のやり取りは不要です。
サーバーは server/discover を実装する必要がありますが、クライアントは毎回呼び出す必要はありません。
ステートレスな MCP はツールが状態を保持できないという意味か？ ツールは依然として状態を保存できますが、処理が隠れたトランスポートの親和性や特定のサーバープロセスに依存してはなりません。
MRTR とは？ Multi Round-Trip Requests は、常時開いた双方向接続上でのサーバー発リクエストを送らずに、サーバーが追加のクライアント／ユーザー入力を要求できる仕組みです。
サーバーが input_required を返し、クライアントが要求された応答を付与して元の操作を再試行します。
HTTP+SSE は直ちに削除されるか？ 新サーバーは Streamable HTTP を使用し、既存システムは残存する HTTP+SSE トラフィックを計測して移行してください。
TypeScript SDK v2 クライアントは自動的に MCP 2026-07-28 を使用するか？ いいえ。TypeScript v2 SDK で新プロトコルを使用するには、明示的なバージョンネゴシエーション設定が必要です。
モダンとレガシーの両サーバーで動く必要があるクライアントでは自動ネゴシエーションを使用してください。
最終提言 MCP 2026-07-28 は、リモート MCP インフラのスケーリング、ルーティング、キャッシュ、可観測性を容易にします。主要な移行リスクは、ヘッダーやハンドシェイクの削除そのものではありません。それらに依存していた隠れたアプリケーション状態と対話ロジックです。
初期化と Mcp-Session-Id への依存をすべて洗い出してください。
必要な状態を明示的ハンドルまたは共有ストレージへ移す。
MRTR を有効期限、リプレイ防止、冪等性付きで実装する。
MCP ヘッダーを JSON-RPC ボディと照合して検証する。
キャッシュをテナントと認可スコープで分割する。
OAuth 発行者検証を強化する。
非推奨機能とレガシートランスポートのトラフィックを計測する。
レガシーとモダンのプロトコルパスをカナリアで並行提供してから廃止する。
移行は単なる SDK アップグレードではなく、インフラ変更として扱ってください。
MCP レイヤーがステートレスかつ可観測になったら、モデルアクセスは別インターフェースの背後に置いてください。これにより、ツールプロトコルとモデルプロバイダ層を独立に進化させることができます。
Roots、Sampling、Logging、HTTP+SSE
旧機能 Roots、Sampling、Logging、HTTP+SSE 非推奨 新規採用停止と既存利用の計測
