[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