Skip to content

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

Closed
#2737
Closed
[Discussion] Proactively detect and surface server-side rate limiting#2442
#2737
Assignees
cliffhall
Labels
questionFurther information is requestedv2Issues and PRs for v2
Milestone
v2.12.0

Description

@CloneOfAlex
CloneOfAlex
opened on Sep 18, 2026

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.

Activity

  1. CloneOfAlex
    added
    enhancementNew feature request
    v2Issues and PRs for v2
    on Sep 18, 2026
  2. cliffhall
    added
    questionFurther information is requested
    and removed
    enhancementNew feature request
    on Sep 23, 2026

  3. cliffhall commented on Sep 23, 2026

    @cliffhall
    cliffhall
    on Sep 23, 2026
    Member

    Triage: Priority Low (total 3)

    • Severity 2: minor friction. Rate-limit errors already surface raw; this asks for a friendlier diagnosis.
    • Urgency 1: no time pressure. Self-described discussion, retyped `enhancement` → `question`.
    • Bonuses: none

    Board: #28, Status Incoming (awaiting maintainer review, no milestone yet).

  4. cliffhall
    added this to the v2.10.0 milestone on Sep 23, 2026
  5. cliffhall
    modified the milestones: v2.10.0, v2.11.0 on Oct 5, 2026
  6. cliffhall
    modified the milestones: v2.11.0, v2.12.0 on Oct 12, 2026
  7. cliffhall
    modified the milestones: v2.12.0, v2.13.0 on Oct 20, 2026
  8. propr-dev
    added a commit that references this issue on Oct 20, 2026

    I've implemented the transport diagnostics for issue #344. `npm test`…

    0c14f18
  9. integry
    added a commit that references this issue on Oct 20, 2026

    [344 by Claude Opus 5.5] Transport-level diagnostics for remote MCP s…

    4bf24ca
  10. cliffhall
    modified the milestones: v2.13.0, v2.12.0 on Oct 20, 2026
  11. cliffhall
    self-assigned this
    on Oct 20, 2026
  12. cliffhall
    linked a pull request that will close this issueRecognize HTTP 429 and surface the server's Retry-After #2737on Oct 20, 2026

  13. cliffhall commented on Oct 20, 2026

    @cliffhall
    cliffhall
    on Oct 20, 2026
    Member

    Shipped in #2737.

  14. cliffhall
    closed this as completedon Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

questionFurther information is requestedv2Issues and PRs for v2

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions