この症状は、少なくとも今回渡された 2 件の issue では、Claude Desktop 側の MCP クライアントが出しているメッセージとして報告されています。サーバーが本当に落ちていると断定できる材料はありません。むしろ、#83908 では「チャットを切り替えた瞬間に tool/call が破棄され、サーバーには何も書き込まれない」と説明されています。つまり、見えているエラー文のわりに、原因がサーバー側とは限らない、というのが出発点です。
#91898 でも、約 240 秒の無応答のあとに同種のメッセージが出た一方で、同じ対象へのメタデータ probe は即時に返ってきたと報告されています。そこでは「タイムアウトしているのはクライアント側の都合で、サーバーの状態をクライアントが知っているわけではない」と問題提起されています。
今回の私の環境では、再現手順やログは取得していません。手元で実際に確認できたのは環境情報だけです。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-19T08:51:24+09:00
なので、ここでは「何を疑うべきか」を issue の報告ベースで絞ります。まず、メッセージどおりに MCP server の死活確認へ飛びつく前に、Claude Desktop の UI 操作や待ち時間の挙動を疑う余地があります。#83908 では、プロンプト送信から dispatch まで 5〜45 秒のずれがあり、その間に別チャットを開くと call が捨てられるとされています。これが事実なら、サーバーは正常でも、結果だけが失われます。
一方で、#91898 の報告は、約 4 分待ったあとにクライアントがタイムアウト文を出すというものです。しかもその文言は「server may be unresponsive, crashed, or not running」と、サーバー断定寄りです。報告者はこれを「クライアントが知りようのない状態を断定している」と見ています。ここから言えるのは、少なくともこの症状は「サーバー停止」だけでは説明できない、ということです。
自分のケースが近いかを見るなら、まず次の 2 点です。
1つ目は、別のチャットに切り替えた直後に tool call が消えるか。#83908 と同じなら、UI の切り替えタイミングが関係していそうです。
2つ目は、約 4 分の無音のあとに同じメッセージへ落ちるか。#91898 と同型なら、少なくともクライアント側のタイムアウト挙動を疑うのが自然です。
現時点では、この症状に対する確立した回避策は渡された材料の中にはありません。少なくとも issue の本文からは、Claude Desktop 側の不具合として扱うのが妥当そうです。サーバー再起動だけで片づく話とは限りません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-19T08:51:24+09:00