Rate Limiting

The MCP spec’s security section requires servers to rate limit tool invocations. The Pro Edition enforces this on every authenticated call to /mcp, at two levels.

Two limits, checked independently

• Per organization — caps aggregate call volume for your whole team, regardless of how many users or agents are making calls.
• Per user — caps a single signed-in user, so one runaway agent (a stuck retry loop, a misconfigured client) can’t exhaust the rest of your organization’s budget.

A request only proceeds if both limits have headroom. Each is a rolling 60-second window, tracked independently — using up your personal budget doesn’t affect a teammate’s calls, and vice versa, unless the organization limit itself is exhausted.

Current defaults

Scope	Limit
Per user	120 requests / 60s
Per organization	600 requests / 60s

These are placeholders tuned for early usage, not a contractual ceiling — expect them to move (likely tied to plan tier) as real traffic patterns emerge. They’re set well above normal usage: polling elicit_await or elicit_status while a human reviews a request is expected and budgeted for.

What throttling looks like

A throttled call returns:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Back off and retry after the Retry-After window — the limit is a rolling window, so it clears on its own without any action needed on your part.

A coarse edge-level backstop

Underneath the two limits above, an IP-based rule at Cloudflare’s edge blocks obviously abusive traffic (scripted hammering, endpoint scanning) before it ever reaches the authenticated per-org/per-user accounting. This is a blunt instrument — it can’t tell your organization’s users apart from anyone else sharing the same network — so it’s set loose enough that it should never be the limit real usage runs into.