Rate limiting

The MCP server shares the same buckets as the REST API, enforced per person within the organization (the JWT sub and org claims together) — never per token, so a new token does not reset the budget. A tool call is never cheaper than the endpoint it dispatches to: the request is counted once, at the MCP layer, and the dispatched handler does not count it again.

Tier	Reads/min	Writes/min	Burst
Default	600	60	100
Premium	3000	300	500

Every response carries:

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 587
X-RateLimit-Reset: 1715961240

Header	Meaning
X-RateLimit-Limit	Requests allowed in the current window.
X-RateLimit-Remaining	Requests left in the current window.
X-RateLimit-Reset	Unix timestamp when the window resets.

When exceeded, the server answers HTTP 429 with rate_limited and a Retry-After header in seconds — the JSON-RPC message is not processed at all.

Attempts with an invalid token are throttled per client IP, not per token — a token that does not verify cannot have a bucket of its own — and refused with the same 429 once over the limit. A request with no token at all, the first step of every client before the OAuth flow, is not counted as an attempt.

tip

An agent that lists in a loop burns the same budget as your backend. Ask for the smallest useful limit, and follow meta.next_cursor only while you still need more — see Pagination.