Limite de Requisições

O servidor MCP compartilha os mesmos limites da API REST, contados por token.

Uma chamada de tool nunca é mais barata que o endpoint que ela espelha: a requisição é contada uma vez no bucket do próprio MCP e, quando é um tools/call, de novo pelo bucket do endpoint para onde ela despacha. Isso é deliberado — um agente que varre listagens em laço não deve conseguir contornar o limite que a mesma varredura pagaria por REST.

Tentativas com token inválido são estranguladas por IP, não por token, do mesmo jeito que na borda REST: um token que não verifica não pode ter bucket próprio. Uma requisição sem token nenhum — o primeiro passo de todo cliente, antes do OAuth — não conta como tentativa.

Quando o limite é atingido

O servidor responde 429 — a mensagem JSON-RPC não chega a ser processada:

HTTP/1.1 429 Too Many Requests
Retry-After: 37
Content-Type: application/json

{ "error": { "code": "TOO_MANY_REQUESTS", "message": "Rate limit exceeded" },
  "retry_after": 37 }

Espere os segundos de Retry-After antes da próxima requisição. Os limites por conta e por tipo de requisição estão na página de limites da API — são os mesmos.

Gastando menos

Um agente consome o mesmo orçamento que o seu backend, e ainda paga contexto por linha que traz. Dois hábitos resolvem quase tudo:

• Filtre antes de paginar. billing_invoices_list { status: "open", due_date_lte: "2026-09-30" } custa uma requisição; varrer todas as faturas para filtrar no modelo custa dezenas.
• Peça só as colunas que interessam. fields: ["number", "total", "due_date"] não reduz o número de requisições, mas reduz muito o contexto gasto — veja Listagem, ordenação e campos.