Last week I was reading through sentry-mcp issue #844 and watched a guy describe exactly the pain I keep running into. He had Cursor running parallel automation against the Sentry MCP, saturated the 60-request-per-minute bucket in seconds, and got back a 429 with no Retry-After header. His agent just sat there. No backoff hint, no escape path, nothing to do but fail the run and ask a human to babysit it.
That same week awslabs/mcp #2949 popped up where the MCP handshake itself was failing because tools/list was tripping a 429 on the second call. And GLips/Figma-Context-MCP #258 had folks convinced the MCP was broken when really their parallel calls were just blowing through Figma's per-token limit on shared credentials.
Same shape every time. The server says "no" in a way the agent cannot use.
Why 429 is the wrong answer for agents
The 429 status was designed for humans behind browsers. Retry-After: 60 works fine if a person can read a banner that says "try again in a minute." It does not work when you have an autonomous agent that needs to decide right now whether to wait, retry, escalate, or pay.
