7件のMCPゲートウェイバグ：セッション漏洩、デッドSSE、およびゲートウェイモードのOAuth

ハッピーパスのデモの後、Redditユーザーが実際のクライアントとサーバーの間にMCPゲートウェイを配置した際に、7つの特定のバグに遭遇した。修正はプロンプトエンジニアリングではなく、明示的なセッション境界、ツールごとのタイムアウト、冪等性、構造化されたアクションログ、ゲートウェイレベルのトレース、同時ツール呼び出しに対するテストだった。その結果、並行ツールの壁時間が大幅に削減されたが、より大きな成果は障害がどこにあるかがわかったことだ。

実際に重要だった7つのバグ

• セッション状態がクライアント間で漏れる — セッション間で状態が共有され、データ汚染が発生。
• SSE接続が静かに切断される — サーバー送信イベントの接続が切れたときにエラーが表面化しなかった。
• ローカルテストでは動作するOAuthフローがゲートウェイモードで壊れる — リダイレクトURIやトークン検証がプロキシの背後で失敗。
• ディスカバリープローブが古いサーバーメタデータを返す — キャッシュされた機能がサーバーの更新を反映していなかった。
• SQLiteの書き込みが並行ツール呼び出しをブロックする — データベースロックが同時リクエストを直列化。
• リトライロジックがツールの副作用を重複させる — リトライが書き込みやAPI呼び出しなどのミューテーションを再実行。
• ツールのレイテンシがモデル呼び出しではなくゲートウェイ内に隠れる — モニタリングが時間を誤ったレイヤーに帰属。

修正：より良いプロンプトではなく、堅実なインフラ

著者の各バグへのアプローチ：

• 明示的なセッション境界 — クライアントごとに別々の状態、共有オブジェクトなし。
• ツールごとのタイムアウトポリシー — 個別のタイムアウトで、1つの遅いツールが他を妨げないようにする。
• 可能な限りの冪等性 — 重複排除キーやトランザクション動作でリトライを安全に。
• 構造化されたアクションログ — デバッグ用に、すべてのゲートウェイアクションの詳細で解析可能なログ。
• ゲートウェイレベルのトレース — 分散トレーシングでレイテンシを正しくレイヤーに割り当て。
• 同時ツール呼び出しに対するテスト — 並行リクエストを発行して競合状態を表面化する統合テスト。

これらは、本番環境でMCPゲートウェイを運用するすべての人にとって具体的で実践的なパターンである。この投稿の重要な洞察：難しい問題は、状態の分離、静かな障害、および観測可能性であり、モデルのプロンプトではない。