#2442·inspector

[Discussion] Proactively detect and surface server-side rate limiting

Author: CloneOfAlexCreated Sep 18, 2026Updated Sep 18, 2026
Labelsenhancementv2

Which client?

All / shared core

The problem

When a connected server starts rate-limiting requests, the Inspector currently just shows the raw error/timeout, without any recognition that a batch of failures might be rate-limit-shaped (e.g. repeated 429s or a consistent latency cliff), leaving distinguishing 'server down' from 'server throttling' up to the user.

Solution you have in mind (optional)

Recognize common rate-limit signals (429 status, Retry-After header) and surface a specific, actionable message with the retry timing instead of a generic error. Flagging as a discussion since it touches error-handling UX across all three clients.

Alternatives or workarounds you have tried

No response

Already built it locally?

No response

Before you submit

  • I searched existing issues and this is not a duplicate.
  • This is a request for the Inspector itself, not for the MCP specification or an SDK.

Source: modelcontextprotocol/inspector