【要約】MCPサーバの`GET /mcp`を200で返したら、Cloudflareの無料枠10万リクエストが7時間で溶けた話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が公開したMCPサーバが、仕様に反する応答を返した。その結果、クライアントが無限リトライを繰り返し、Cloudflareの無料枠を短時間で使い果たした。
- ・原因：
GET /mcpに対し、SSEではなくJSONを200 OKで返したこと。 - ・現象：クライアントが接続切断と判断し、0.2秒間隔で再接続を繰り返した。
- ・影響：15分で1.1万リクエスト、1日換算で100万リクエストの負荷が発生した。
// Approach
MCPのStreamable HTTP仕様に基づき、応答を修正した。SSEを提供しない場合の正しい挙動を実装することで、ループを停止させた。
- ・仕様準拠：
GET /mcpに対し、405 Method Not Allowedを返す。 - ・UX維持：ブラウザの
acceptヘッダを見て、紹介ページへリダイレクトする。 - ・監視強化：CloudflareのObservabilityを有効化し、ログを可視化した。
// Result
修正により、リクエスト数は劇的に減少した。不自然なリトライが消え、実用的な通信のみが残った。
- ・定量効果：15分間のリクエスト数が11,000件から十数件へ減少した。
- ・改善内容：リクエストが人間の操作や実際のMCP利用に紐づくようになった。
Senior Engineer Insight
> プロトコル実装における「独自の解釈」の危険性を示す事例だ。仕様で定義されたメソッドに独自の応答を返すと、予期せぬ挙動を招く。特にエラー率0%のままリソースを食いつぶすパターンは厄介だ。リクエスト数やCPU時間などの多角的な指標で異常を検知すべきである。