Are Rate Limits the Biggest MCP Problem Nobody's Talking About?

Twelve months ago, the hot takes about the Model Context Protocol centred on discovery: how do AI assistants even find your server? Six months ago, the conversation shifted to authentication: who's protecting those endpoints? Both problems are real, and they've attracted genuinely good thinking. But there's a third failure mode that's quietly breaking production deployments in 2026, and it shows up in GitHub issue trackers more than anywhere else: rate limiting.

Not the rate limits your server enforces. The rate limits everyone else enforces — and what happens when your agent runs into them.

Where does this data come from?

This post draws on three production incident reports filed as GitHub issues against live MCP servers in 2026: the AWS Knowledge MCP server, the Sentry MCP server, and the Atlassian Rovo MCP server. These aren't synthetic benchmarks. They're real sessions, real traffic, real 429 responses. No figures have been extrapolated.

Are the limits that exist wildly inconsistent?

The first thing that jumps out when you look at documented MCP servers is how uneven the rate limits are. The AWS Knowledge MCP server enforces roughly one request per fifteen seconds per IP address — that's four requests per minute. The Sentry MCP server gives each user sixty requests per minute, fifteen times more generous, and reserves three hundred per minute for IP-based limits. These are servers in the same ecosystem, used for similar agentic tasks, with limits that differ by a factor of seventy-five.

Why does this matter? Because an AI agent doesn't know what server it's talking to until it's already inside the session. It can't negotiate a request budget upfront. It just starts sending tool calls — and if the server has a four-per-minute cap, the agent will hit it before it finishes the standard MCP initialization handshake, which itself requires several back-and-forth messages.

That's exactly what happens with the AWS Knowledge server. Users reported that the client sends tools/list immediately after connecting — a lightweight startup call, not a data query — and gets a 429 in response. The session never gets off the ground. From the user's perspective, the MCP integration is broken. From the server's perspective, it's working exactly as designed.

Is volume even the right thing to limit?

Here's where things get more interesting. The Atlassian case shows that even careful volume management might not be enough. A team running agent workflows against the Atlassian Rovo MCP server logged 348 calls to a single tool (getConfluencePage) across an entire 24-hour window — fewer than fifteen calls per hour on average. Well under any reasonable volume cap.

And they still hit rate limits. At peak they got twelve 429 errors in a single interval — not because they'd sent too many requests overall, but because around twenty to twenty-five calls were in-flight simultaneously. The server appears to be enforcing a concurrency cap, not a per-hour cap. But that constraint isn't documented anywhere in the public API reference.

The practical consequence is uncomfortable: you can architect a system that comfortably stays under a volume ceiling and still get throttled. The "safe" call rate you've calculated from the documentation is irrelevant if the server's actual constraint is parallelism.

What happens when rate limits fire but nobody logs it?

The Sentry MCP server case adds another layer to this. Three or four parallel automation runs — a perfectly reasonable thing to do if you're running multi-threaded agent workflows — can saturate its sixty-per-minute per-user limit in seconds. That's a fast failure, and in isolation it sounds easy to spot.

Except the Sentry team's own issue tracker notes that there are currently no Sentry events or metrics emitted when a rate limit fires. The 429 is returned to the calling agent, but nothing is logged on the server side. If you're the one running those parallel runs, you see errors. If you're the platform team monitoring that MCP server, you see nothing at all.

This is an observability gap that compounds the rate limit problem significantly. You can't tune limits you can't measure. You can't build alerting for a failure mode that leaves no trace. The MCP specification doesn't mandate any particular logging behaviour when rate limits fire, so this is left to individual implementers — and several clearly aren't prioritising it.

Does the token consumption problem compound this?

Rate limits are one kind of resource constraint. Token consumption is another, and for browser-based MCP tools — the kind that navigate and read web pages on the agent's behalf — context depletion often becomes the binding constraint before rate limits even have a chance to bite.

A single page read via a browser automation tool can consume anywhere from fifty thousand to five hundred thousand tokens depending on the complexity and size of the page. That range is wide. A dense documentation page and a simple landing page might differ by a factor of ten in token cost.

After two or three navigations running near the upper end of that range, a session has exhausted a standard context window. The session doesn't fail with a clean rate-limit error — it just becomes increasingly context-constrained. The agent starts losing track of earlier findings and making worse decisions. It's a slow degradation rather than a hard stop, which makes it significantly harder to diagnose than a straightforward 429.

What should site owners do about this?

A few practical conclusions fall out of this data:

Assume concurrency limits exist even when they aren't documented. The Atlassian case shows that a server can throttle on parallel calls without advertising that anywhere. Design your agent workflows with a conservative concurrency cap — start at five simultaneous tool calls or fewer and stress-test upward from there rather than downward from failure.

Watch for startup throttling specifically. If your MCP integration fails intermittently on first connection rather than mid-session, check whether the server has per-IP limits that catch the initialization handshake. The AWS Knowledge pattern — failing on tools/list before any data call — is easy to misread as a transient network issue rather than a rate limit problem.

Instrument your own tool call layer. Don't rely on the MCP server to tell you when you've been throttled. Build your own counters and timers around tool calls. If 429s are appearing, you want that reflected in your own dashboards with timestamps and context, not just as a stack trace in a log file that nobody checks until something breaks.

For browser tools, decide on a page budget upfront. If you're using browser automation MCP tools, set a hard limit on how many page reads a session is allowed to make. At the lower bound of token consumption, four to five pages can fill a typical context window. Build that constraint into your agent's planning, not just your error handling.

The MCP ecosystem is still working out what production-ready actually means. Rate limits are part of that definition — but they haven't made it into most getting-started guides yet, which is why the evidence keeps showing up in issue trackers instead.