No mês passado assisti um time gastar nove dias construindo um servidor MCP para buscar dados de clima. Nove dias. O agente poderia ter chamado a API com um único curl e uma definição de ferramenta de uma linha. Mas MCP era a coisa brilhante do momento, então MCP foi.
Deixa eu dizer o que todo mundo está pensando em voz alta: você deveria parar de construir servidores MCP para tudo. O Model Context Protocol é genuinamente bom. Também é drasticamente aplicado em excesso por pessoas que ouviram "padrão" e assumiram "obrigatório."
Para o que MCP serve de verdade
MCP resolve um problema real: você tem uma capacidade que quer expor a muitos agentes, em muitos clientes, com uma interface consistente. Pense num banco de dados que toda a sua organização consulta. Um design system. Um índice de busca interno que doze ferramentas diferentes precisam acessar. Construa o servidor uma vez, e Claude Desktop, Cursor e seu harness customizado todos falam com ele da mesma forma. Essa é a vitória. Reuso entre clientes.
É isso. Esse é o argumento todo. Se você não está obtendo reuso entre múltiplos clientes ou múltiplos agentes, você está pagando o imposto do protocolo por nada.
O imposto que ninguém menciona
Todo servidor MCP é um processo. Ele tem um ciclo de vida. Tem um transporte — stdio ou SSE — que pode travar, cair ou parar de responder silenciosamente. Carrega definições de ferramentas na sua janela de contexto quer você as chame ou não. Já vi um único servidor MCP tagarela consumir 4.000 tokens de contexto antes do modelo ler uma palavra da tarefa real.
E você tem que manter a coisa. Versionar ela. Lidar com auth dentro dela. Depurá-la quando o agente diz "a ferramenta não está respondendo" e você não tem ideia se é o servidor, o transporte ou o modelo alucinando um nome de ferramenta.
Compare isso com uma função simples que o agente chama diretamente, ou um comando CLI que ele executa pelo Bash. Quando meu agente Claude Code precisa acessar a API do GitHub, ele roda gh. Sem servidor. Sem protocolo. Sem ciclo de vida. A ferramenta já está na máquina e o modelo já sabe como operá-la.
A regra de decisão honesta
Aqui está o teste que eu realmente uso antes de escrever uma única linha de código de servidor:
- Mais de um cliente ou agente vai usar isso? Se não, pule o MCP.
- Já existe um CLI que faz isso? Se sim, deixe o agente rodar o CLI.
- É uma integração única para um projeto? Escreva uma ferramenta local, não um servidor.
- Precisa sobreviver a este repositório e ser compartilhada? Agora MCP faz sentido.
Note quantas vezes a resposta é "pule o MCP." Para um builder solo entregando um produto, é quase sempre pular. Você não tem muitos clientes. Você tem um. Você está construindo infraestrutura para uma frota que você não possui.
A armadilha do wrapper
O servidor MCP ruim mais comum é o wrapper de API. Alguém pega uma API REST que já é bem documentada, já tem uma spec OpenAPI, já funciona com um bearer token, e a envolve em MCP. Por quê? O agente poderia ler a spec. Poderia fazer a requisição. Você adicionou uma camada de tradução entre o modelo e algo que o modelo já era bom em fazer.
Pior ainda, você escondeu a superfície real da API por trás das suas definições de ferramenta escolhidas a dedo. A API tem 40 endpoints. Seu servidor expõe 6, porque eram os que você precisava na terça-feira. Agora o agente literalmente não consegue fazer as outras 34 coisas sem você lançar uma nova versão do servidor.
Se a coisa subjacente é uma API HTTP, tente isso primeiro:
# Deixe o agente simplesmente chamá-la
curl -s https://api.example.com/v1/items \
-H "Authorization: Bearer $TOKEN" | jq '.items'
Dê ao modelo a URL base, o padrão de autenticação e a documentação. Veja funcionar. Você vai se surpreender com a frequência com que o requisito "precisamos de um servidor MCP" se evapora.
Quando eu realmente uso MCP
Não sou anti-MCP. Construí um para um vector store que quatro agentes separados consultam, com lógica de embedding compartilhada que eu definitivamente não queria reimplementar quatro vezes. Esse é o ponto ideal: estado compartilhado real, múltiplos consumidores reais, custo real de duplicar a lógica. O protocolo ganhou seu lugar.
Também o uso quando a capacidade precisa ser stateful de uma forma que um CLI stateless não consegue gerenciar bem — um pool de conexões de longa duração, um índice em cache, uma sessão de auth que é cara de re-estabelecer. O servidor mantém o estado. Os agentes o tomam emprestado. Boa adequação.
Mas esses são casos específicos. Não são "toda integração." O padrão deveria ser: ferramenta direta, ou CLI, ou uma função simples. MCP é o escalonamento, não o ponto de partida.
O problema do desenvolvimento orientado a currículo
Vamos ser honestos sobre por que isso acontece. MCP é novo e em voga, e "construí um servidor MCP" soa melhor num standup do que "escrevi uma definição de ferramenta de 12 linhas." Eu entendo. O incentivo é construir a coisa que parece impressionante.
Mas seus usuários não se importam com sua arquitetura. Eles se importam se o agente entrega o recurso. Cada hora que você gasta construindo encanamento de protocolo para uma integração de consumidor único é uma hora que você não gastou no produto. O movimento mais sênior muitas vezes é o chato: pule o servidor, chame a API, siga em frente.
Construa o servidor MCP quando você tiver muitas bocas para alimentar. Até lá, seu agente tem um shell. Deixe-o usá-lo.