本番MCPスタックには、transport、プロトコル処理、認証、routing、ツール定義、認可ポリシー、実行認証情報、バックエンドAPI、操作状態、テレメトリーが含まれます。小規模なデプロイでは複数レイヤーを一つのプロセスにまとめられますが、各責務には一つの責任箇所が必要です。
多くの障害は、隠れた境界から生まれます。一つのhandlerがtokenを検証し、テナントアクセスを判断し、プロバイダー呼び出しを再試行し、結果を記録すると、どのルールが失敗したのか誰にも分かりません。
スタックの全体像
flowchart TD
C[MCP clients] --> T[Transport edge]
T --> S[Protocol server]
S --> G[Authentication and routing]
G --> R[Tool registry]
R --> P[Authorization policy]
P --> E[Tool executor]
E --> K[Credential broker]
K --> B[Backend APIs and data]
E --> O[Operation state]
S --> X[Telemetry and evaluations]
P --> X
E --> X
B --> X
これは責務のマップです。11個の別々のプロダクトを必要とするわけではありません。
transport edge
edgeはリモートサーバーのHTTPSを終端し、リクエストサイズとoriginを検証し、接続数を制限し、Streamable HTTP sessionをroutingします。ローカルのstdioサーバーは、ローカルプロセスとOSの境界を引き継ぎます。
MCP transport仕様は、stdioとStreamable HTTPの動作を定義します。テナントのrate limitやアプリケーション認可は提供しません。
プロトコルサーバー
サーバーは初期化、機能の折衝、JSON-RPC message、pagination、cancel、notificationを処理します。実装で宣言したツール、リソース、プロンプトを公開します。
プロトコルエラーはドメインの失敗と分けます。不正なtools/callリクエストと、有効なcreate_invoice呼び出しをビジネスポリシーが拒否することは別です。
認証とrouting
認証はクライアントと代理対象のユーザーを確立します。routingは適切なサーバー、テナントコンテキスト、ツールグループを選びます。ゲートウェイは複数のMCPサーバーで接続制限とauth discoveryを一元化できますが、小規模なデプロイで別サービスにする必要はありません。
MCP認可ガイドでは、リモートOAuthフローとaudience検証をここに置く理由を説明しています。
ツールレジストリ
レジストリには、クライアントから見える正確な名前、説明、スキーマ、出力契約、annotationが含まれます。テナント、role、機能、環境によって一覧をfilterする場合もあります。
ツール選択とリソース認可を分けてください。ツールを隠すことでモデルは選択しやすくなりますが、禁止されたリクエストは引き続きバックエンドで拒否します。
MCPツール設計ガイドには、このレイヤー向けの選択専用評価が含まれます。
認可ポリシー
ポリシーは、代理対象のIDが現在、このテナント、リソース、アクションに対してツールを使えるかを判断します。承認が必要かどうかも決めます。
広範なビジネスルールは、リソースを所有するサービスに置きます。中央のポリシーレイヤーで早期に拒否できますが、あるユーザーが別ユーザーの請求書を読めないことを知る唯一の場所にしてはいけません。
ツールexecutorとcredential broker
executorは入力を検証し、内部コードまたは上流APIを呼び出し、結果を整形します。credential brokerは、利用可能な中で最も狭いscopeの上流認証情報を提供します。
モデルへその認証情報を渡してはいけません。MCPのシークレット処理ガイドでは、プロンプト、ログ、エラー、生成成果物からの漏えいをテストする方法を紹介しています。
バックエンドと操作状態
バックエンドはデータ整合性と最終的な認可を強制します。操作状態は、論理書き込み、試行、冪等性キー、プロバイダーrequest ID、結果を記録します。セッション状態とchat履歴はこの台帳を代替しません。
タイムアウト後、executorはプロバイダーを再度呼び出すか決める前に操作状態を読みます。
テレメトリーと評価
テレメトリーはユーザーリクエストをツール呼び出しとバックエンドへの効果へ結び付けます。評価は、変更を越えてモデルが正しいツールを選び、ツールを使わないケースを尊重するかをテストします。
安定したIDと範囲を限定した結果分類を記録します。認証情報、生の機密データ、無制限のプロバイダーpayloadは除外します。
境界が役立つ場合だけ分割する
独立した信頼、scaling、所有権、release動作が必要な場合に、レイヤーを別サービスへ分けます。アーキテクチャ図にゲートウェイの箱があるというだけで追加してはいけません。
以下のプロンプトは、既存デプロイの責任箇所を整理し、セキュリティまたは復旧に実際のリスクを生む最初の混在責務を見つけます。