fix(mcp): surface the real cause on MCP loss and recover parked servers faster

[Revelation-Agency]

Hi — a small reliability patch to tools/mcp_tool.py, offered from production experience.

What happened to us. A client-facing agent ran ~53 hours with zero MCP tools and nothing alerted. The MCP server had dropped, its tools were deregistered, and the agent carried on answering from memory rather than saying it had lost the ability to act. When we went looking, the log said unhandled errors in a TaskGroup (1 sub-exception), which didn't tell us what actually broke.

What this changes (all in tools/mcp_tool.py):

1. Surface the real cause. _flatten_exc() unwraps ExceptionGroup / TaskGroup sub-exceptions — bounded at depth 4 and the first 5 sub-exceptions — so the underlying failure reaches the log instead of the wrapper message.

2. Make total tool loss loud. Parking now logs at ERROR and names the server plus how many tools were lost, and _deregister_tools(reason=...) emits an ERROR on the transition to zero tools. It stays quiet on ordinary shutdown, so clean exits don't get noisy. An agent that can no longer act felt worth an ERROR rather than a WARNING.

3. Recover faster. _PARKED_RETRY_INTERVAL 300s → 30s. At five minutes a parked server turns a blip into an outage; 30s took our recovery from ~9 minutes down to ~60–90s.

Beyond log levels/content and that retry cadence there's no behaviour change, and no public API change.

Happy to adjust any of this to your conventions — split it into separate commits, reword the log lines or dial the levels back, make the retry interval configurable instead of a constant, or drop any part you'd rather not carry. Just say which and I'll rework it.

[spfcraze]

This was generated by AI during triage.

Summary:
The premise of change 1 is already handled on main: tools/mcp_tool.py:3238 unwraps TaskGroup errors before the log lines this PR edits, so the one-sub-exception log the description cites already shows its root cause.

Problems:

• tools/mcp_tool.py:3238 already runs root = _unwrap_exception_group(exc) — helper defined at tools/mcp_tool.py:980, whose docstring quotes the same "unhandled errors in a TaskGroup" string — before the parking and reconnect logs this PR changes, and those logs already print the unwrapped root cause. For the cited one-sub-exception case _flatten_exc(exc) re-adds the wrapper text around the same cause; its real delta is the multi-leaf rendering (up to 5 sub-exceptions, depth 4). The same string is reported on the initial-connect path in open issue [Bug] /reload-mcp drops ALL stdio MCP servers — every initial connection fails with "unhandled errors in a TaskGroup" and servers park permanently #78426, which this PR does not touch.
• The motivation for change 2 — an agent running with zero MCP tools while nothing alerts — is the subject of open issue [Feature/Bug]: No signal exposed to indicate whether a completed run's tool calls actually succeeded - a session with zero working tools can still return a confident, well-formed disposition #73389 (zero working tools still yield a confident, well-formed disposition, with no signal exposed), which the description does not reference; the ERROR log is a diagnostic step toward it, not the run-visible signal that issue asks for. The alert it adds fires only on the degraded-to-parked path: the permanent-error park (tools/mcp_tool.py:3354-3367) deregisters a previously-working server's tools via a bare self._deregister_tools() call, so the transition item 2 says is worth an ERROR remains a WARNING there.
• The description names one retry-cadence change (_PARKED_RETRY_INTERVAL, item 3) and states there is "no behaviour change" beyond it; the diff also shortens _CIRCUIT_BREAKER_COOLDOWN_SEC 60.0 to 15.0 (tools/mcp_tool.py:3623), which shrinks the model-facing "Auto-retry available in ~Ns" window (tools/mcp_tool.py:4904) — a second behavior change the body does not name.

Solution:
Keep the existing type(root).__name__, root lines and drop _flatten_exc, or scope it to the multi-sub-exception case; name _CIRCUIT_BREAKER_COOLDOWN_SEC in the description or revert it; reference #73389 if change 2 targets that issue; and pass a reason at the permanent-error park if every zero-tool transition is meant to alert.

---

Checked against 4acbc10 — the tip of fix/mcp-resilience-0030 when this was written — and 20e01f9, main at the same moment.