読んでまず思ったのは、MCPまわりの失敗って、派手なバグというより「HTTPの約束をちょっと外しただけ」で簡単に壊れるんだな、ということでした。404、406、415、400、405、402が並ぶと身構えるけれど、記事を追うとどれもわりと地味で、しかも地味だからこそハマる。そこを一つずつ、エラーコードごとに切り分けているのがありがたいです。
特に腑に落ちたのは、/sse を足してしまう話です。昔のHTTP+SSEの感覚が残っていると、つい「まずSSEを開くもの」と思ってしまうけれど、Streamable HTTPではURLがひとつで済む。仕様が変わったのに、クライアントやブリッジが昔の癖を引きずると404になる。この手の事故は、コードの中身というより“前提のズレ”で起きるので、デバッグしていて妙に疲れるんですよね。記事はそこを「URLを勝手に補完するな」とかなりはっきり言っていて、実務で効く感じがしました。
もう一つ面白かったのは、402の扱いです。ふつうのWeb開発だと 402 Payment Required はほとんど見ないので、エラーとして出てくるだけで少し特殊に感じます。しかも単に「課金エラー」ではなく、tool result の中に価格見積もりが入ってくる、という見方をしているのがMCPらしい。失敗を失敗として終わらせず、次の行動に必要な情報を返す設計になっているのは面白いと思いました。とはいえ、これは標準的な“エラーコードの読み方”からは少し外れているので、初見の人はかなり戸惑うはずです。そこを「これは請求書みたいなもの」と割り切って読めるかどうかで、運用のしやすさが変わりそうです。
記事全体を通して感じたのは、MCPの接続トラブルって、プロトコルの話というより運用の話なんだなということでした。ヘッダーを明示する、session を保持する、タイムアウトを上げる、再接続する。どれも派手ではないけれど、こういう地味な確認を先に並べてくれる記事は本当に助かります。特に、クライアント側の実装を疑う前に「プロキシが Accept を落としていないか」「session を header で送っているか」を見ろ、という視点は、そのまま実戦メモになります。
参考: MCP connection errors explained: 404 on /sse, 406 Not Acceptable, session 400s, 402
