Why MCP needs limits more than REST
An LLM client doesn't know it's looping. A user asks "summarize my inbox" and a poorly-tuned agent calls list_messages two thousand times before giving up. REST clients have humans in the loop; MCP clients have probabilities. Limits are how you stay solvent.
Four layers of quota
- Per-tool concurrency — cap parallel invocations of expensive tools (e.g. search) to keep tail latency stable.
- Per-user rate — token bucket per
user_id, refilled every minute. Stops one agent from starving the workspace. - Per-workspace rate — daily ceiling per workspace. Stops one tenant from starving the platform.
- Cost cap — dollar ceiling per user per month. Returns 429 with a payment-required hint when breached.
Soft + hard
Page the operator at 80% (soft) and return 429 at 100% (hard). Surfacing limits before they bite is the difference between a feature and an outage.
What a good 429 looks like
Include Retry-After, a machine-readable code (rate_limited, quota_exceeded, cost_cap_reached), and a human message. Hosts use the code to decide whether to retry; humans use the message to know what to do.
FAQ
- Why rate-limit MCP servers at all?
- LLM hosts retry aggressively on ambiguous errors. Without limits, a single bad prompt can fan out to thousands of tool calls in seconds.
- Per-user or per-workspace?
- Both. Per-user stops a runaway agent; per-workspace stops a runaway tenant from starving others.
- What status code should I return?
- 429 with a Retry-After header in seconds. Hosts that respect MCP spec will back off; the rest at least see a clean error.
- Soft caps vs hard caps?
- Both. Soft caps page the operator and email the workspace owner; hard caps return 429. Never silently drop calls.