Limite de requisições

O servidor MCP compartilha os mesmos buckets da API REST, aplicados por pessoa dentro da organização (as claims sub e org do JWT, juntas) — nunca por token, então um token novo não zera o orçamento. Uma chamada de tool nunca é mais barata que o endpoint para o qual ela despacha: a requisição é contada uma vez, na camada MCP, e o handler despachado não conta de novo.

Plano	Leituras/min	Escritas/min	Burst
Padrão	600	60	100
Premium	3000	300	500

Toda resposta carrega:

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

Header	Significado
X-RateLimit-Limit	Requisições permitidas na janela atual.
X-RateLimit-Remaining	Requisições restantes na janela atual.
X-RateLimit-Reset	Timestamp Unix em que a janela reinicia.

Ao exceder, o servidor responde HTTP 429 com rate_limited e um header Retry-After em segundos — a mensagem JSON-RPC nem chega a ser processada.

Tentativas com token inválido são limitadas por IP do cliente, não por token — um token que não passa na verificação não pode ter um bucket próprio — e recusadas com o mesmo 429 quando passam do limite. Uma requisição sem token nenhum, o primeiro passo de todo cliente antes do fluxo OAuth, não conta como tentativa.

dica

Um agente que lista em loop queima o mesmo orçamento que o seu backend. Peça o menor limit útil e siga o meta.next_cursor só enquanto ainda precisar de mais — veja Paginação.