Servidor MCP: qual limite de taxa evita a conta estourada?

O limite que evita a conta estourada é o teto por operação, contado na camada que enxerga a chamada de ferramenta, não o teto por servidor MCP. O teto não é um número de proteção. É uma decisão de economia, e quem não a toma no projeto acaba tomando no meio do incidente, com o gráfico ainda subindo.

Às 2h40, o painel de operação mostra a curva de chamadas de ferramenta saindo da escala. Ninguém sabe se aquilo é um cliente pagante descobrindo um caso de uso novo ou um agente em laço. O gráfico só mostra o sintoma. A resposta está em quem o servidor acha que está chamando.

A especificação do Model Context Protocol, na revisão de 2026-07-28, exige que o servidor valide todas as entradas de ferramenta, implemente controle de acesso, limite a taxa de invocação de ferramentas e sanitize as saídas. O texto normativo tem quatro palavras: "Rate limit tool invocations". Unidade, número, janela e resposta não estão lá. O resto é engenharia de quem opera.

Pré-requisitos: o que existe antes do primeiro limite de taxa MCP

Antes de escolher um número, quatro coisas precisam existir: identidade por chamada, um contador que sobreviva à requisição, um log com uma linha por operação e um dono nomeado do teto. Sem os quatro, o limite de taxa MCP vira um número que ninguém contesta depois do incidente.

• Identidade por chamada: um contador sem sujeito conta o total do servidor. O sujeito é a credencial com audiência validada, e clientInfo é rótulo declarado, não identidade.
• Um contador que sobreviva à requisição e seja compartilhado entre réplicas: o protocolo ficou sem sessão, e nada garante que a chamada seguinte caia no mesmo processo.
• Um log com uma linha por operação, com ferramenta, chamador, resultado e duração.

O quarto item é o mais barato e o que mais falta: um dono nomeado do teto. Sem dono, o número sobe na primeira reclamação e ninguém registra o motivo.

Uma operação, aqui, é um tools/call admitido, um POST. Um input_required faz o cliente repetir com id novo, e o limitador cobra as duas: o teto conta requisição, não invocação lógica.

Os seis passos:

1. Escolha a unidade do teto.
2. Dimensione o teto de rpm pelo pior caso.
3. Calcule o custo por operação aceita.
4. Decida onde o teto roda.
5. Trate a recusa de cota como erro de negócio.
6. Defina a exceção de abuso antes do incidente.

Passo 1: escolha a unidade do limite de taxa por operação

A unidade decide o que o teto protege. Por servidor, ele protege a infraestrutura e deixa o agente gastar sozinho. Por agente, ele protege a conta e deixa o servidor exposto. Por operação, ele protege a fatura por chamada. A escolha é qual risco limitar primeiro.

Os três níveis de teto de gasto de chave e gasto por agente limitam o consumo do modelo; a tabela abaixo limita o tráfego de ferramentas. São duas contas.

Cada unidade engana de um jeito: o teto por servidor MCP segura a infraestrutura quando um agente é o maior consumidor, o por ferramenta cai quando o agente troca de ferramenta, o por agente cai quando dois times dividem a credencial, e o por operação cai quando a conta que importa é a do resultado.

Passo 2: dimensione o teto de rpm pelo pior caso, não pela média

O teto de rpm sai da concorrência e da latência da ferramenta, não da média do mês. Com N chamadas simultâneas e latência L em segundos, o servidor MCP recebe cerca de N vezes 60 dividido por L operações por minuto. Esse número é vazão em saturação de malha fechada, não pico observado.

Chamadas simultâneas: N. Latência da ferramenta: L, em segundos. Operações por minuto: N × 60 ÷ L.

Exemplo de conta, sem preço e sem medição: 40 chamadas simultâneas com 1,5 segundo de latência dão 1.600 operações por minuto, e a folga de 25% leva o teto de rpm a 2.000.

A folga não é simpatia, é o preço de não parar a operação legítima: teto alto demais documenta o estouro, e baixo demais recusa chamada boa.

O teto fica acima do pico legítimo e abaixo do que o orçamento sustenta, e o publicado é o menor dos dois. Gasto permitido por janela dividido pelo custo de uma operação aceita, que o passo seguinte define, dá quantas operações aceitas a fatura paga; dividir pela taxa de aceitação chega ao rpm admitido. O teto de rpm protege a disponibilidade, e o do orçamento protege a fatura: é ele que recusa o laço quando a fatura não paga a taxa legítima.

A janela é escolha: uma fixa de 60 segundos admite até o dobro do teto na virada, então use janela deslizante ou balde de tokens.

O teto conta operações de alguém, e a identidade do chamador no tráfego de agentes decide quem é esse alguém.

Passo 3: calcule o custo por operação MCP que devolveu resultado

O custo por operação é o gasto total dividido pelas operações que devolveram resultado utilizável. Ele inclui as tentativas que falharam, as repetições que o modelo pediu e a chamada de ferramenta que cobrou sem entregar. Operação tentada não é operação paga.

O gasto total tem dois lados. O da ferramenta é execução e chamada. O do contexto é o que a operação faz com a chamada de modelo seguinte: definição e resultado são entrada cobrada por token, e o tamanho do resultado é a alavanca. Listas com ttlMs e cacheScope, e ordem determinística, cortam o custo de atualização.

Taxa de aceitação é o multiplicador que ninguém vê.

A conta tem dois números: operações tentadas e aceitas. Um agente que tenta 1.000 operações e entrega 250 carrega o custo das outras 750: três operações falhas por operação aceita, e uma operação aceita custa quatro unidades de operação.

São contas diferentes: o custo operacional de um gateway de IA mede o overhead da camada em latência, memória e custo por requisição, e o custo por operação aceita mede a chamada que devolveu resultado.

O limite de taxa por operação tem uma armadilha: ele conta chamadas que o teto admitiu, e chamada admitida não é chamada que devolveu resultado.

Passo 4: decida onde o teto roda, no servidor MCP ou no roteador de LLM

O teto só vale onde a identidade chega. A RFC 6585, seção 4, deixa o critério de identificação em aberto: se o servidor identifica pela credencial e o gateway apresenta a própria, o contador conta o gateway inteiro, e a cota por agente deixa de existir ali.

A revisão de 2026-07-28 tornou o protocolo sem sessão, com credencial por requisição, e a camada de controle do tráfego de ferramentas é o único ponto que vê, na mesma requisição, a operação e quem a pediu; o servidor valida que o token foi emitido para ele e não o repassa adiante, como identidade do chamador já descreveu.

A camada identifica a operação pelos cabeçalhos: Mcp-Method em toda requisição e Mcp-Name em tools/call, espelhando o nome da ferramenta. Ela conta por ferramenta sem ler o corpo.

A troca de credencial não é falha de configuração: o dado que sustentava a cota por agente não atravessa a fronteira. A cota por agente morre ali. Quem opera a camada que vê a operação assume o teto por chamador.

O teto por servidor MCP continua onde sempre esteve: é o teto que existe sem intermediário no caminho, e por isso fica.

O Nexforce Router é um gateway de LLM com roteamento entre mais de 300 modelos, orçamento por chave, por agente e por projeto, e rastro de cada chamada, o que torna auditável o gasto de modelo por chamada.

A camada de roteamento mede e governa o lado do modelo e o gasto da chave, e nenhuma ferramenta decide o teto no lugar do dono da operação.

Passo 5: trate o erro de teto como erro de negócio, não como erro de ferramenta

A especificação define erro de execução pelo lugar onde ele é reportado, no resultado da ferramenta com isError: true, e recomenda que o cliente devolva esses erros ao modelo para permitir autocorreção. A recusa de cota, o erro de teto desta peça, não é resultado de ferramenta. Devolvê-la como erro de ferramenta ensina o agente a tentar de novo.

São três camadas. Erro de protocolo é objeto de erro JSON-RPC, que o cliente pode omitir do modelo. Erro de execução vai no resultado com isError: true. Recusa de cota é a terceira: no transporte ela chega como 429, o código da RFC 6585, seção 4, com detalhe e Retry-After opcional.

A separação vale para recusa do limitador, antes do despacho. Quando a ferramenta embrulha uma API de terceiro e o 429 dela volta como isError: true, o implementador traduz o sinal para erro de negócio.

A RFC 9110, seção 10.2.3, define Retry-After como data HTTP ou número inteiro de segundos, a única espera padronizada que o chamador obedece.

Reembalar a recusa como isError é o atalho caro: o modelo lê falha corrigível, tenta de novo, e a repetição consome a cota que o teto protegia. O chamador precisa do erro de negócio, com teto nomeado e espera.

E a espera precisa de jitter: um Retry-After em segundos inteiros sincroniza os chamadores e devolve a rajada na virada da janela. Orçamento de repetição e teto de chamadas em voo por chamador completam a resposta de recusa. Chamada em voo é a que ainda não voltou, e sem concorrência limitada um laço ocupa todas as conexões.

Repetição cega depois de recusa é o mesmo erro de leitura de tratar failover como balanceamento, como failover não é load balancer mostra.

Passo 6: defina a exceção de abuso antes do incidente

Laço de agente, lote legítimo e cliente abusivo produzem o mesmo sintoma e pedem respostas diferentes. A exceção é item de projeto: chave separada, teto próprio, validade declarada e dono nomeado, decidida com o sistema calmo, nunca no incidente, e a diferença só aparece no registro que a seção pede.

Sintoma idêntico: volume fora da curva no mesmo servidor MCP, recusa subindo, e um horário ruim para descobrir a diferença. O laço é bug. O lote legítimo pede janela agendada e teto próprio, e o abusivo pede limite contratual, não ajuste silencioso no painel.

O que precisa estar registrado:

• A chave separada e o teto próprio de cada exceção.
• A validade declarada, com data de revisão.
• O dono nomeado que aprova a renovação.

A exceção que ninguém revisa é um segundo teto, com o nome do primeiro.

Como verificar que o teto funciona

A verificação tem quatro leituras: o contador do gateway fecha com o do servidor MCP, a taxa de recusa por teto fica na faixa esperada, a latência p95 não piora depois do limite e o custo por operação MCP para de subir com o volume.

O trace da chamada de LLM é a fonte das quatro: cada leitura compara duas contagens que só existem se a chamada foi registrada inteira.

A primeira é a conciliação, que só fecha quando os dois lados filtram igual: mesmo método, mesma janela e mesmo mapa de chamador, sem tools/list nem repetições.

A segunda é a faixa de recusa. Recusa perto de zero com volume crescendo quer dizer teto frouxo; recusa alta em pico legítimo quer dizer teto baixo, e o sintoma chega na reclamação antes do painel.

A terceira é a latência p95: se piora depois do limite, a fila do teto está errada. A quarta é o custo por operação aceita, que não sobe com o volume.

Erros comuns e como corrigir

Teto único para todas as ferramentas é o primeiro. Busca e escrita não têm a mesma latência nem o mesmo custo, e o teto único sobra para uma e falta para a outra. A correção é um teto por ferramenta, com o do servidor como guarda-chuva.

Teto dimensionado pela média é o segundo: ele nunca segura o pior caso, que é o que estoura a conta. A correção é a conta do Passo 2, com a folga declarada.

Contador em memória que zera no deploy é o terceiro. Todo deploy devolve cota cheia. Com POST independentes o furo é maior, porque N réplicas com contador local dão N vezes o teto publicado, e ele precisa ser atômico e compartilhado, não só persistente.

Recusa sem detalhe nem espera declarada é o quarto. O chamador não sabe se espera um segundo ou uma hora, então tenta de novo, e a tentativa é o que o teto devia impedir. A correção é o Retry-After da RFC 9110, com o teto nomeado.

Perguntas frequentes

O que a especificação exige de um servidor MCP em limite de taxa? Exige que o servidor limite a taxa de invocação de ferramentas, com validação de entrada, controle de acesso e sanitização de saída, na revisão de 2026-07-28. O texto normativo é "Rate limit tool invocations", e ele não fixa unidade, número, janela nem resposta: esses quatro ficam com quem opera o servidor.

Qual unidade de teto usar quando o agente é compartilhado? Duas ao mesmo tempo. O teto de rpm por agente protege a conta quando a credencial é de um agente só; o teto por servidor protege a infraestrutura quando vários agentes somam volume. Com credencial dividida, a atribuição some e o teto por agente passa a valer para o grupo inteiro.

O que muda quando o gateway deixa de repassar a chave do chamador? O contador do servidor passa a contar o gateway, não o agente. A RFC 6585, seção 4, deixa a identificação em aberto, e a especificação proíbe repassar adiante o token do cliente. O teto roda onde a operação é visível, e quem vê a operação assume o teto por chamador.

Como o agente deve reagir a uma recusa de cota? Como erro de negócio, não como erro de ferramenta. A recusa chega no transporte, com o teto nomeado e a espera declarada, e o agente espera com jitter em vez de repetir. Reembalada como erro de execução, vira ordem de nova tentativa que consome a cota que o teto protegia.

Quando o teto por servidor ainda é a escolha certa? Quando o risco é a infraestrutura cair, e não a fatura subir. É o teto que existe sem roteador de LLM nenhum no caminho: um cliente que fala direto com o servidor passa por ele, e nessa rota o teto por chamador só existe se o servidor contar a credencial que já valida.

Referências e Leitura Complementar

• Model Context Protocol, especificação, revisão 2026-07-28, página de ferramentas. Acesso em 27/10/2026. https://modelcontextprotocol.io/specification/2026-07-28/server/tools
• Model Context Protocol, autorização, considerações de segurança, revisão 2026-07-28. Acesso em 27/10/2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
• RFC 6585, seção 4, 429 Too Many Requests. Acesso em 27/10/2026. https://www.rfc-editor.org/rfc/rfc6585.txt
• RFC 9110, seção 10.2.3, Retry-After. Acesso em 27/10/2026. https://www.rfc-editor.org/rfc/rfc9110.txt

Quando revisar o teto

O teto é premissa, não constante. Quatro mudanças obrigam a refazer o Passo 2 e o Passo 3 em vez de subir o número: ferramenta nova ou ferramenta que mudou de latência, mudança na concorrência do agente, chamador novo no mesmo servidor MCP e mudança na forma como a credencial chega ao servidor. Refazer a conta custa uma tarde. Descobrir a premissa velha custa o trimestre. O teto é uma peça da camada de gateway, e o que é um gateway LLM mostra onde ela encaixa.