Claude Code v2.1.318でstdio MCPサーバーの再プローブを抑える：起動時の確認で落ちるときの切り分け

Claude CodeでMCPサーバーをいくつも登録していると、起動のたびに同じサーバーへ確認が走ることがあります。しかも、そのサーバーが短時間で終了するタイプだと、毎回「接続できなかった」と見えてしまいます。

このあたりは、MCPサーバーが壊れているとは限りません。Claude Code v2.1.318では、短時間で終了するstdio MCPサーバーの扱いが変わりました。

毎回version probeが走る

stdioのMCPサーバーは、Claude Codeから起動され、標準入出力で通信します。起動直後にバージョン確認をして終了するサーバーもあります。

このサーバーを登録していると、次の起動でも同じ確認が繰り返されます。確認が失敗したわけではないのに、ログだけ見ると接続エラーのように見えるのが困るところです。

claude mcp list

# 例
# local-tools: stdio  ✓ Connected

まずはこの一覧と、サーバー側の終了コードを分けて見てください。終了したこと自体が異常とは限りません。

Claude Code v2.1.318では、短時間で終了するstdioサーバーがversion probeを繰り返さないよう、legacy handshakeへ固定されるようになりました。

ここでいうlegacyは、古いからダメという意味ではありません。プローブを毎回やり直すより、サーバーの寿命に合わせた通信方法を選ぶためのものです。

私のように無人実行へMCPを組み込んでいると、起動時の余計な待ち時間や「また接続確認で止まったのか」という切り分けが減ります。これは地味ですが、意外と使えます。

接続が遅いからといって、すぐにタイムアウトを伸ばすのはおすすめしません。まず次の3つを確認します。

サーバーを常駐させる設計なら、そちらのログと比べてください。短時間で終了する設計なのに常駐前提で調べると、原因を取り違えちゃいます。

自動化で大事なのは、プロセスが終わったことと、処理に失敗したことを同じ扱いにしないことです。

run reportには、MCPサーバーの起動・probe・終了コードを残します。接続確認だけで終了するサーバーなら、終了後にClaude Code側が次の処理へ進めたかを検証すれば十分です。

逆に、実際のツール呼び出しで止まったなら、サーバーのstdout/stderrと設定を見直します。ログの1行だけで「MCPが壊れた」と決めないでください。

短時間で終了するstdio MCPサーバーは、毎回version probeが走ることで接続失敗のように見えることがあります。

Claude Code v2.1.318以降では、こうしたサーバーをlegacy handshakeへ固定する修正が入っています。まずバージョンとログを確認して、タイムアウトを伸ばす前に切り分けてみてください。

「終了したから失敗」と決めつけない。無人実行では、この線引きが大事ですね。