Summary

External MCP/plugin calls can stall the main assistant reply path. When a third-party MCP server becomes slow, disconnected, or half-hung, the user sees a delayed or missing reply instead of a fast degraded response.

Why this matters

In real use, the main chat path should stay responsive even when optional external capabilities are unhealthy. Right now, a bad MCP can act like a shared choke point.

Observed behavior

Examples from production-like local setups:

• external memory MCP repeatedly reconnects / reports not connected
• reply generation becomes slow or appears stuck
• the underlying channel integration remains healthy, but the assistant reply is delayed by the MCP path
• users cannot easily tell whether the problem is the channel, the model, or the external MCP

Expected behavior

OpenClaw should treat external MCP/plugin capability as optional unless the current turn explicitly requires it.

Suggested behavior:

1. Per-tool / per-plugin timeout budget
2. Circuit breaker after repeated failures
3. Fast degrade path: skip the unhealthy MCP and continue the reply
4. Clear user-facing diagnostics: "channel healthy, external MCP degraded"
5. Main reply path should not block on optional MCPs beyond a short timeout

Proposed design ideas

• Add configurable timeout + failure threshold per MCP/plugin
• Mark capability state as healthy | degraded | unavailable
• Surface degraded state in status / logs
• Allow tools to declare optional=true so failure downgrades instead of blocking the turn
• Cache recent failures briefly to avoid reconnect storms

Real impact

This would prevent a whole class of "assistant looks dead but the channel is fine" incidents.