Limite de Requisições

O servidor MCP compartilha os mesmos limites da API REST, contados por pessoa e organização — o sub e o org do token, não o token em si.

Trocar de token não zera o orçamento: um token novo, seja de uma nova autorização OAuth ou um novo token pessoal, da mesma pessoa na mesma organização cai no mesmo bucket. A mesma pessoa em outra organização tem orçamento próprio.

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. dashboards_portal_users_list { status: "suspended" } custa uma requisição; varrer todos os usuários do portal para filtrar no modelo custa dezenas.
• Peça só as colunas que interessam. fields: ["email", "status", "last_login_at"] não reduz o número de requisições, mas reduz muito o contexto gasto — veja Listagem, ordenação e campos.