O Cursor avisa acima de 40 ferramentas MCP, o VS Code recusa pedidos acima de 128, e o Claude Code adia as definições com a busca de ferramentas. Este artigo explica cada limite, o custo em tokens por ferramenta e as soluções que mantêm uma configuração cheia de ferramentas abaixo do teto.
Conecte mais um servidor MCP e seu agente pode, de repente, esquecer como ler um arquivo. Sem travamento, sem alerta vermelho, apenas uma ferramenta que estava lá ontem e hoje não aparece. É isso que o limite de ferramentas MCP causa, e cada editor lida com ele de um jeito. O Cursor avisa você acima de 40 ferramentas, o VS Code recusa pedidos acima de 128, e o Claude Code adia discretamente a maioria das definições de ferramentas até que o modelo as peça.
Este artigo traz os números reais de cada cliente, as mensagens que você verá ao ultrapassar o limite, a conta de tokens por trás desses limites e uma lista curta de soluções que mantêm uma configuração cheia de ferramentas abaixo do teto.
💡 Resumo rápido: planeje com 40 ferramentas no Cursor, 128 no VS Code e 100 no Windsurf. Trate o Claude Code como "sem número fixo, mas cada definição ainda custa contexto, a menos que a busca de ferramentas esteja ativada". Os limites mudam entre versões, então confirme na versão que você tem instalada.
Veja o que a documentação oficial e as discussões da comunidade relatam até outubro de 2026.
| Cliente | Limite de ferramentas | O que acontece ao ultrapassá-lo |
|---|---|---|
| Cursor | 40 ferramentas somando todos os servidores MCP ativados | Um aviso aparece e só as primeiras 40 ferramentas chegam ao agente |
| VS Code (Copilot Chat) | 128 ferramentas por pedido de chat | Erro: "Cannot have more than 128 tools per request" |
| Windsurf (Cascade) | 100 ferramentas somando todos os servidores | Ferramentas extras ficam indisponíveis até você desativar algumas |
| Claude Code | Sem número fixo | A busca de ferramentas adia as definições por padrão; desativá-la carrega tudo de uma vez |
| Claude Desktop | Nenhum teto rígido publicado | Cada definição de ferramenta ativada entra no contexto da conversa |
Duas coisas se destacam. Primeiro, o VS Code é o único cliente desta tabela cujo número consta na documentação oficial. Os 40 do Cursor e os 100 do Windsurf vêm de fóruns e de textos de terceiros, por isso merecem a observação "confira sua versão". Segundo, o teto rígido raramente é o primeiro problema. Respostas mais lentas, escolhas erradas de ferramenta e uma janela de contexto que enche antes de você digitar um prompt aparecem muito antes de qualquer teto.
Um servidor MCP descreve cada ferramenta com um nome, uma descrição em linguagem simples e um esquema JSON para seus argumentos. O cliente envia todo esse pacote ao modelo em cada pedido, antes do seu prompt e antes de qualquer conteúdo de arquivo. Dez ferramentas pequenas quase não pesam. Oitenta ferramentas detalhadas podem consumir uma fatia real da janela que você queria para o código.
Esse é o motivo real de os clientes definirem tetos. Um limite é uma forma direta de proteger o orçamento de contexto, manter a latência baixa e impedir que o modelo se afogue em opções. As discussões no fórum do Cursor descrevem o limite de 40 exatamente nesses termos: encaminhar dezenas de ferramentas brutas faz o modelo gastar contexto para avaliá-las, então a latência sobe e a precisão cai.
Contexto é só metade da história. A outra metade é a escolha. Quando um modelo enfrenta dezenas de ferramentas com nomes parecidos, como search_issues, search_repos e search_code, ele precisa adivinhar qual serve, e os palpites erram com mais frequência conforme a lista cresce.
A documentação de chamada de funções da OpenAI sugere manter menos de 20 funções disponíveis no início de cada turno, e classifica isso como uma sugestão flexível. O GitHub chegou a um resultado parecido no Copilot: reduziu o conjunto padrão de ferramentas integradas de 40 para 13 ferramentas centrais e expandiu o restante sob demanda. Nos próprios benchmarks do GitHub, essa abordagem melhorou as taxas de sucesso em 2 a 5 pontos percentuais e reduziu a latência média em 400 milissegundos.
Portanto, o limite prático fica abaixo do teto impresso. Um servidor com 12 ferramentas bem nomeadas costuma superar um servidor com 90 ferramentas que soam todas parecidas.
Você mesmo pode medir a confusão das ferramentas em cerca de dez minutos, sem mexer na configuração do editor.
Repita o mesmo experimento com alguns modelos lado a lado. Claude Sonnet 5, GPT 5.4 e Gemini 3.1 Pro estão todos disponíveis como modelos de chat no PicassoIA, então você pode comparar como cada um lida com uma lista lotada. Se os palpites errados caírem bruscamente quando a lista diminui, você terá a resposta sobre quantas ferramentas seu fluxo de trabalho realmente suporta.
💡 Ressalva: isso testa a escolha do modelo a partir de texto simples. Os clientes reais acrescentam o próprio roteamento, então trate o resultado como um sinal, não como garantia.
O Cursor mostra um aviso quando as ferramentas dos seus servidores ativados passam de 40. A redação relatada no fórum do Cursor segue mais ou menos esta linha: você tem 50 ferramentas de servidores ativados, o limite é 40, e algumas ferramentas podem não estar disponíveis para o agente. Em versões mais antigas, as excedentes eram simplesmente ignoradas. Conecte servidores que expõem 45 ferramentas no total e o agente usou 40, sem diagnóstico detalhado sobre quais cinco sumiram.
Algumas publicações recentes dizem que versões mais novas do Cursor registram ferramentas de forma mais flexível e carregam algumas sob demanda. A página de documentação do MCP que consultamos não publica uma contagem de ferramentas, então 40 continua sendo o número seguro para planejar.
💡 Atenção à conta: o teto é total, não por servidor. Três servidores com 15 ferramentas cada já levam você a 45, cinco acima do limite, mesmo que nenhum servidor isolado pareça grande.
Quatro medidas, em ordem do menor para o maior esforço:
.cursor/mcp.json e deixe apenas os servidores do dia a dia no ~/.cursor/mcp.json global.Ativar ferramenta por ferramenta é um pedido recorrente no fórum do Cursor, então, se você precisa desse nível de detalhe hoje, vai precisar podar no nível dos servidores.
O VS Code é o mais explícito dos três. A documentação dele afirma que um pedido de chat pode ter no máximo 128 ferramentas habilitadas por vez. Ao ultrapassar isso, o Copilot Chat falha com: "Cannot have more than 128 tools per request."
A contagem vale para tudo o que está habilitado no seletor de ferramentas, não só para as ferramentas MCP, então ela enche mais rápido do que você imagina. Dois ou três servidores grandes podem bastar.
A solução rápida fica no seletor de ferramentas da visualização de Chat. Desmarque ferramentas individuais ou servidores MCP inteiros até a contagem cair abaixo de 128 e envie o pedido de novo.
Se você quer ir além de 128, o VS Code oferece ferramentas virtuais. Defina github.copilot.chat.virtualTools.threshold e o VS Code agrupa ferramentas semelhantes sob uma única ferramenta virtual. O modelo vê primeiro os grupos e expande um grupo somente quando o prompt precisa dele, o que permite que um pedido de chat ultrapasse o limite de 128.
Pense nisso como um índice: o modelo lê os títulos dos capítulos e depois abre um capítulo. A contrapartida é uma etapa extra de expansão na primeira vez em que um grupo é necessário, em troca de uma lista inicial bem mais curta.
Os testes do GitHub com roteamento baseado em embeddings mostram por que agrupar compensa. A ferramenta necessária estava pronta em 94,5 por cento dos casos, contra 87,5 por cento da seleção baseada em LLM e 69,0 por cento de uma lista estática de ferramentas.
O Claude Code segue outro caminho. Em vez de limitar a contagem, evita pagar por cada definição logo de início. Com a busca de ferramentas, as definições das ferramentas MCP são retiradas do pedido e o modelo recebe uma única ferramenta de busca para carregar as que precisa. A documentação MCP da Anthropic lista as exceções: a busca de ferramentas fica desativada com um ANTHROPIC_BASE_URL personalizado, com ENABLE_TOOL_SEARCH=false e com modelos anteriores à geração Claude 4.5.
Publicações da comunidade descrevem mais valores para a mesma variável, como auto, que adia somente quando as definições passam de 10 por cento da janela de contexto, e auto:5 para um limite de 5 por cento. Verifique a documentação da versão instalada antes de confiar nesses valores. Uma publicação mediu 147 definições de ferramentas em cerca de 90.000 tokens quando carregadas de uma vez, contra cerca de 15.000 com a busca de ferramentas ativada.
O tamanho da saída também importa. O Claude Code avisa quando o resultado de uma única ferramenta MCP passa de 10.000 tokens e limita a saída a 25.000 por padrão. Aumente isso com MAX_MCP_OUTPUT_TOKENS apenas quando uma tarefa realmente precisar.
Não encontramos uma contagem fixa de ferramentas para o Claude Desktop na documentação da Anthropic. Publicações de terceiros descrevem um mecanismo mais simples: cada ferramenta exposta por cada servidor conectado é injetada no contexto da conversa em todas as mensagens, sem recuperação dinâmica. O conselho prático deles é ficar entre 30 e 50 ferramentas ativas antes que a saturação e a confusão apareçam. Trate essa faixa como experiência da comunidade, não como limite oficial.
A conclusão para quem usa Claude é que o limite é um orçamento, não um número. Ative apenas os conectores que a conversa atual precisa e desligue o resto.
Os números publicados variam muito porque o nível de detalhe dos esquemas varia. Estes valores vêm de listagens públicas de custo em tokens e da publicação mencionada acima:
| Servidor ou configuração | Definições de ferramentas | Tokens de uma vez | Por ferramenta (aprox.) |
|---|---|---|---|
| Servidor MCP do GitHub | 86 | 14.406 | cerca de 170 |
| Variante menor do servidor do GitHub | 36 | 11.430 | cerca de 320 |
| Servidor de Projects do GitHub | 19 | 2.316 | cerca de 120 |
| Configuração mista de uma publicação | 147 | cerca de 90.000 | cerca de 610 |
A variação é a lição. Uma ferramenta custa entre cerca de 120 e 610 tokens, dependendo de quanta descrição e esquema ela carrega. Conte as ferramentas, mas pese-as também.
Use esta fórmula para checar qualquer configuração:
ferramentas × tokens por ferramenta ÷ janela de contexto = parcela gasta antes de você digitar
| Ferramentas | Tokens cada | Total | Parcela de uma janela de 200.000 |
|---|---|---|---|
| 10 | 300 | 3.000 | 1,5% |
| 40 | 300 | 12.000 | 6% |
| 86 | 170 | 14.620 | 7,3% |
| 128 | 600 | 76.800 | 38,4% |
A janela de 200.000 é apenas um exemplo, e o seu modelo pode oferecer mais ou menos. O padrão se mantém de qualquer forma: 40 ferramentas enxutas custam cerca de 6 por cento, enquanto 128 pesadas podem consumir mais de um terço. O peso dos esquemas importa mais do que o número impresso no teto.
Organize cada ferramenta em três ou quatro tarefas, por exemplo código, dados, documentação e mídia. Depois ative uma tarefa por vez. No Cursor, isso significa configuração por projeto; no VS Code, o seletor de ferramentas; e no Claude, os interruptores dos conectores.
Agrupar também resolve colisões de nomes. Quando as ferramentas de documentação e as de código nunca compartilham uma conversa, search só pode significar uma coisa.
A maioria das configurações carrega peso morto. Passe por esta lista uma vez:
💡 Regra prática: se uma ferramenta não foi chamada em um mês, ela está custando tokens e não rendendo nada.
Se você escreve o próprio servidor MCP, projete pensando no orçamento: uma tarefa só, descrições curtas, nomes que nunca se sobrepõem e esquemas de argumentos enxutos. O conector do PicassoIA para o Claude é um bom exemplo da abordagem enxuta. Ele expõe nove ferramentas: generate_image, edit_image, dois geradores de vídeo, get_generation, list_generations, list_models, get_account e cancel_generation. Todas servem a uma só tarefa: criar imagens e vídeos.
Um servidor desse tamanho fica folgadamente abaixo dos 40 do Cursor e dos 100 do Windsurf, e deixa espaço para meia dúzia de outros servidores antes que você sinta qualquer pressão.
A forma mais fácil de sentir o que um orçamento de ferramentas bem cuidado oferece é rodar um fluxo de trabalho real por ele. Peça uma imagem em linguagem simples, confira o resultado, ajuste um detalhe e peça de novo. Uma configuração focada mantém esse ciclo rápido, porque o modelo não precisa vasculhar sessenta ferramentas não relacionadas para encontrar a que ele precisa.
As fotos deste artigo saíram do P-Image com prompts curtos e específicos. Você pode rodar o mesmo tipo de prompt no PicassoIA agora mesmo:
O PicassoIA também transforma uma imagem estática em um vídeo curto, então a mesma foto pode virar um clipe com mais um passo. Veja todos os modelos em picassoia.com/en/all-models, escolha um, escreva um prompt sobre o seu próprio projeto e veja o resultado. Mude uma palavra, rode de novo e compare. Esse hábito de testar uma variável por vez é o mesmo que mantém uma configuração MCP saudável.
Escolha seu idioma
