MCP Por Default é Erro: Quando o Protocolo Vira Overhead Desnecessário

Tenho três posts aqui no blog elogiando o MCP. Um sobre como o protocolo virou padrão aberto da indústria sob a Linux Foundation. Outro sobre como o MCP está ressignificando interfaces de usuário. Um terceiro sobre os riscos de segurança que a maioria ignora ao implantar servidores MCP. Escrevi esses posts de boa fé e continuo de acordo com tudo que está lá.

Por isso mesmo, este post é a conversa de maturidade que faltava.

Depois de usar MCP em produção em projetos de tamanhos variados, percebi que estava cometendo o erro clássico de quem encontra uma boa ferramenta: usando-a para tudo. E quando o Thoughtworks Tech Radar Vol. 34, de abril de 2026, colocou "MCP by default" em Caution, foi menos uma surpresa e mais um aceno de confirmação. O Radar não está dizendo que MCP é ruim. Está dizendo exatamente o que levei algum tempo para aprender: adoção reflexiva tem custo real, e esse custo frequentemente não aparece no piloto.

A questão não é se você deve usar MCP. É se você deve usar MCP aqui, para este problema, com este time, neste momento.

---

Por Que Todo Mundo Adotou MCP No Piloto Automático

Entender por que chegamos aqui não é exercício de crítica. É diagnóstico.

O MCP surgiu num momento de vácuo. Antes dele, cada integração entre um agente e uma ferramenta externa era uma integração customizada, com seu próprio contrato, seu próprio formato de resposta, sua própria forma de lidar com erro. Quem tentou conectar um modelo a uma API proprietária em 2023 sabe bem o sofrimento: você escrevia um wrapper, documentava o schema das ferramentas no system prompt, torcia para o modelo entender o formato esperado, e rezava para a saída ser parsável.

O MCP chegou com uma proposta elegante: um protocolo único, com contratos de ferramenta padronizados, descoberta automática de capacidades e gestão de sessão embutida. Em menos de um ano virou padrão aberto com 97 milhões de downloads mensais do SDK, suporte nativo em Claude, ChatGPT, Cursor e VS Code. Quando uma tecnologia resolve um problema real com elegância e adquire suporte ubíquo da noite para o dia, a tendência humana é generalizá-la.

E aí está o problema. O MCP foi promovido como a resposta para "como conecto meu agente ao mundo externo", e essa pergunta tem mil variantes com respostas diferentes. Nós colocamos o MCP como resposta padrão sem qualificar a pergunta.

Há também um viés de sinalização. MCP ficou associado com "arquitetura agentica séria". Apresentar uma integração baseada em MCP numa revisão de design passou a soar mais robusto do que apresentar um CLI com output JSON. Um ao parece enterprise-grade; o outro parece script de shell. Esse viés de percepção, mais do que qualquer argumento técnico, explica boa parte da adoção reflexiva.

E tem o efeito de tutorial. A documentação oficial do MCP é boa, os exemplos são claros, os SDKs em Python e TypeScript reduzem a fricção inicial. Quando o caminho de menor resistência para "integrar meu agente com esta ferramenta" passa pelo servidor MCP, é o que você vai fazer. O problema não é o tutorial — é que nenhum tutorial tem interesse em te dizer "para este caso, talvez não fosse necessário".

---

O Que o MCP Realmente Adiciona — E O Que Custa

Para decidir bem, você precisa entender o que MCP entrega de verdade e o que ele cobra em troca. Nenhuma das duas listas é curta.

O que MCP entrega de verdade:

Contratos de ferramenta padronizados. O servidor MCP expõe um schema formal para cada ferramenta: nome, descrição, parâmetros com tipos, exemplos. O cliente usa esse schema para entender o que pode chamar e como. A diferença para uma integração customizada é a diferença entre uma API com OpenAPI spec e uma API com um README no Notion.

OAuth nativo. O MCP v2 especifica OAuth 2.1 como mecanismo padrão de autenticação. Isso significa que você pode delegar auth para seu provedor de identidade existente — Okta, Azure AD, Google Workspace — sem reinventar o fluxo em cada integração. Para qualquer contexto onde identidade e auditoria importam, esse item sozinho já justifica a análise.

Reusabilidade de servidor. Um servidor MCP bem construído pode ser consumido por múltiplos clientes: Claude Desktop, o agente interno do time, o Cursor de um desenvolvedor, uma pipeline de automação. Você implementa uma vez e distribui. Um CLI não tem essa propriedade naturalmente — você pode chamar de qualquer lugar, mas quem chama precisa entender e parsear a saída.

Descoberta de capacidades. Um cliente MCP pode perguntar ao servidor o que ele consegue fazer sem documentação externa. É o equivalente de /--help estruturado e legível por máquina, mas como parte do protocolo, não como convenção.

O que MCP cobra em troca:

Um servidor intermediário. Você não está mais fazendo uma chamada direta. Você tem um processo MCP rodando, gerenciando sessões, roteando chamadas. Isso é infraestrutura adicional para provisionar, monitorar, escalar e manter.

Latência extra. Cada chamada de ferramenta passa por serialização, transporte pelo protocolo MCP, processamento no servidor e deserialização. Em cenários de alta frequência de chamadas de ferramenta — e agentes agressivos chegam facilmente a dezenas de chamadas por tarefa — esse overhead acumula.

Debugging mais complexo. Quando algo falha numa integração direta, o stack trace aponta para o problema. Quando algo falha num fluxo MCP, você tem potencialmente três lugares para investigar: o cliente, o servidor MCP e a ferramenta subjacente. O protocolo adiciona uma camada de indireção que torna o debugging não linear.

Mais pontos de falha. Servidor MCP caindo significa todas as ferramentas expostas por ele indisponíveis. Uma integração direta isolada falha de forma isolada. O MCP centraliza a disponibilidade, o que é bom para consistência e ruim para tolerância a falhas se você não tratar a infraestrutura MCP com o cuidado que ela merece.

O Radar chama isso de abstraction tax. O termo é preciso. Toda abstração tem um custo, e a questão é sempre se o valor entregue justifica o imposto cobrado. O MCP justifica o imposto em muitos casos — e não justifica em vários outros que se tornaram casos de uso "MCP por default".

---

Quando Um CLI Bem Feito É Suficiente — Ou Melhor

O Radar articula uma alternativa que merece atenção séria: "Um CLI bem feito com --help, JSON estruturado e erros previsíveis frequentemente basta."

A afirmação vai contra a intuição de quem está no hype de agentic AI, então vale detalhar o que "CLI bem feito" realmente significa aqui, porque não é um script de shell jogado num repositório.

Um CLI que serve bem para integração com agentes tem algumas características específicas. Saída JSON estruturada e consistente em stdout — o agente parseia, não interpreta. Erros distintos e com semântica clara em stderr, com códigos de saída previsíveis. Flags --json ou --output json para alternar entre modo humano e modo máquina. Documentação --help que descreve comportamento, não apenas sintaxe. Idempotência onde possível, ou indicação clara quando não.

Agentes se integram muito bem com CLIs assim. O contexto agentico de um modelo inclui tanto a saída de ferramentas quanto a capacidade de interpretar saídas estruturadas. Um agente que recebe um JSON limpo de um CLI está em condição equivalente a um agente que recebeu a resposta de um servidor MCP — com a diferença de que não há servidor intermediário na equação.

Um exemplo concreto: suponha que você precisa que um agente consulte o status de deploys de uma ferramenta interna de CI/CD. Você tem duas opções. A primeira é criar um servidor MCP com uma ferramenta get_deploy_status que aceita {pipeline_id, environment} e retorna o estado. A segunda é garantir que sua CLI interna produza --output json com o mesmo schema e documentar os parâmetros no system prompt do agente. Na prática, a segunda funciona tão bem quanto a primeira — e não requer que você provisione, monitore e mantenha um servidor adicional. O agente chama o CLI, recebe o JSON, age sobre ele. Sem middleman.

Isso não quer dizer que o CLI é sempre superior. Quer dizer que a comparação é legítima e precisa acontecer antes de você ir direto para o servidor MCP.

Quando o CLI ganha na comparação:

Ferramentas internas de time, onde você controla o cliente e o servidor, e a "descoberta de capacidades" é uma conversa no Slack ou numa PR de documentação. O overhead do protocolo MCP não entrega valor porque o contrato já é conhecido por todos os consumidores.

Scripts e automações unitárias, onde a ferramenta executa uma coisa específica e retorna. Não há sessão para gerenciar, não há múltiplos clientes para servir. O MCP seria estrutura para um problema que não existe.

Protótipos e provas de conceito, onde a velocidade de iteração é o que importa e a infraestrutura MCP ainda não está disponível. Começar com CLI e migrar para MCP quando o caso de uso validar a complexidade é uma estratégia racional — o contrário (começar com MCP e simplificar) raramente acontece na prática. A pressão por "não quebrar o que já funciona" congela arquiteturas mais cedo do que deveria.

Ambientes restritos, onde você não pode ou não quer rodar serviços adicionais. Containers mínimos, ambientes edge, pipelines CI com recursos limitados. Um CLI não precisa de servidor. Esse critério parece óbvio mas é ignorado com frequência quando o time já tem MCP rodando em outro contexto e tenta reusar a infraestrutura para casos que não justificam a dependência.

Integrações de vida curta, onde o agente vai ser usado para uma task específica por um período limitado e depois descontinuado. Construir e manter um servidor MCP para uma integração temporária é overengineering com data de validade.

Há também uma categoria emergente que o próprio Radar destaca como alternativa: Agent Skills. Skills são contratos de capacidade mais leves que MCP, projetados especificamente para composição em pipelines agênticos sem o overhead de um servidor de protocolo. A ideia é encapsular uma capacidade — "sabe buscar dados neste sistema", "sabe executar este tipo de transformação" — em algo que pode ser composto em um agente sem exigir a infraestrutura completa do MCP. Para muitos casos onde você pensaria "vou criar um servidor MCP para expor esta capacidade", um skill bem definido entrega o mesmo resultado com menos infra. Vale avaliar antes de escalar para MCP — especialmente quando a capacidade é de uso interno, com um único consumidor e sem requisito de auth estruturada.

---

Quando MCP Faz Sentido de Verdade

Depois de tudo isso, seria desonesto não ser específico sobre quando MCP é a escolha certa. Porque é, em muitos contextos.

Múltiplos clientes, um servidor. Se você está construindo uma integração que será consumida por Claude Desktop, pelo agente do time, pelo Cursor dos desenvolvedores e por uma pipeline de automação, o servidor MCP é o investimento certo. Você implementa auth, logging, rate limiting e versionamento uma vez. A alternativa é replicar isso em cada cliente — ou acumular dívida técnica até a primeira auditoria.

Contextos onde auth e auditoria são requisitos reais. OAuth 2.1 nativo, audit trails, controle de acesso por escopo — se esses são requisitos da sua organização, não conveniências, o MCP v2 entrega isso como parte do protocolo. Construir equivalência em cima de um CLI é possível, mas você está reinventando o que o MCP já resolve.

Ferramentas que expõem capacidades complexas e compostas. Se sua ferramenta não executa uma operação — ela expõe um domínio inteiro com múltiplas operações interdependentes — o modelo de descoberta de capacidades do MCP faz diferença real. Um servidor MCP de acesso a banco de dados, por exemplo, pode expor query, schema, explain e transaction com contratos distintos, e o agente descobre e usa conforme necessário.

Quando a ferramenta vai evoluir independentemente do agente. O protocolo MCP cria uma fronteira limpa entre o servidor e o cliente. Se a ferramenta tem seu próprio ciclo de vida, seu próprio time, seus próprios releases, a separação por protocolo é boa engenharia — não burocracia.

Integrações com sistemas de terceiros que já têm servidores MCP. O ecossistema cresceu para o ponto onde muitas ferramentas enterprise — GitHub, Jira, Salesforce, bancos de dados populares — já têm servidores MCP mantidos. Nesse caso, o overhead de adoção é quase zero: você conecta um cliente a um servidor existente. O "abstraction tax" já foi pago por outra equipe.

A distinção mais limpa que encontrei na prática: se você está expondo, use MCP; se você está consumindo uma vez, avalie se CLI não basta. Quem expõe tem mais razões para investir na infraestrutura de protocolo. Quem consome uma ferramenta isolada para um agente específico tem mais razões para buscar a integração mais simples que funciona.

---

Como Decidir: Um Framework de Três Perguntas

O Radar termina sua análise com uma chamada para "adoção deliberada". Deliberada não significa burocrática. Significa que a decisão tem critérios, não é por inércia.

Três perguntas que uso antes de decidir entre MCP e uma alternativa mais simples:

1. Quantos clientes vão consumir esta ferramenta?

Um cliente (o agente deste projeto específico): avalie CLI ou skill primeiro. Múltiplos clientes distintos: a centralização do MCP justifica o custo. Essa é a pergunta mais discriminante porque incide diretamente no principal argumento de valor do MCP — reusabilidade de servidor.

2. Auth e auditoria são requisitos formais ou conveniências?

Se há um requisito de compliance, de auditoria de acesso, de integração com seu IdP corporativo: MCP com OAuth 2.1 é a resposta. Se auth é "bom ter" e você está numa fase de validação: CLI com token simples no header é suficiente e muito mais rápido de iterar.

3. O contrato da ferramenta é estável ou vai evoluir independentemente?

Se a ferramenta e o agente evoluem juntos, no mesmo repositório, pelo mesmo time: a fronteira de protocolo adiciona atrito sem adicionar isolamento real. Se são sistemas separados com ciclos de vida distintos: a fronteira do MCP é vantagem, não overhead.

Se você respondeu "um cliente", "auth é conveniência" e "evolução acoplada" para as três perguntas: provavelmente um CLI bem feito serve melhor. Se respondeu "múltiplos clientes", "requisito formal" e "ciclos independentes": MCP é a escolha certa.

A maioria dos casos reais cai em algum meio-termo, e tudo bem. O ponto é que a decisão agora tem critérios, não é por default.

Uma quarta pergunta que eu adicionaria: qual é o custo de estar errado?

Se você escolher CLI e depois descobrir que precisava de MCP, a migração existe e é relativamente direta — você já tem o comportamento definido, só está mudando o transporte e adicionando o protocolo por cima. Se você escolher MCP e descobrir que era desnecessário, você vai manter esse servidor por inércia por muito tempo, porque a pressão para simplificar raramente vence a pressão para "não quebrar o que funciona". O custo de estar errado no sentido "escolhi mais do que precisava" é assimétrico para o lado negativo.

Isso sugere uma heurística: em caso de dúvida genuína, comece menor. A migração de CLI para MCP é um upgrade; a migração de MCP para CLI é uma simplificação que raramente tem patrocínio organizacional.

Há também o fator momentum do ecossistema. As tendências de desenvolvimento agentico em 2026 apontam para uma fragmentação de padrões antes de uma consolidação — MCP, Agent Skills, CLIs estruturados e APIs REST com schemas OpenAI-compatíveis coexistem. O ecossistema ainda está se formando, e escolhas de arquitetura feitas hoje com MCP podem precisar de revisão quando o padrão evoluir. Ser deliberado inclui não sobreengenheirar para um futuro que ainda não está claro. Escolher a abstração mais simples que resolve o problema hoje deixa mais espaço para adaptar amanhã.

---

A Maturidade Que Faltava na Conversa

O MCP é um protocolo genuinamente bom. Os três posts que escrevi sobre ele continuam corretos. O que mudou é o meu contexto de uso: depois de mais projetos, com mais variação de escala e requisito, a zona de "MCP faz sentido" ficou mais nítida — e também ficou mais clara a zona onde ele é exagero. Essa clareza não veio de teoria. Veio de manter servidores MCP que não precisavam existir, de debugar fluxos mais complexos do que o problema justificava, e de depois olhar para o caso de uso e perceber que um CLI com quinze linhas de saída JSON teria resolvido o mesmo problema com metade da infraestrutura.

O Radar colocar "MCP by default" em Caution não é um retrocesso. É sinal de que a tecnologia amadureceu o suficiente para ser usada com critério, não apenas com entusiasmo. Esse é exatamente o arco de qualquer boa ferramenta: você começa usando em tudo porque descobriu que funciona, e eventualmente aprende o contorno de aplicação onde ela realmente brilha. O Kubernetes passou por isso. O GraphQL passou por isso. O Docker passou por isso. MCP está passando agora — o que é, no fundo, uma boa notícia. Significa que saiu da fase de hype e entrou na fase de uso criterioso.

Adoção deliberada não é adoção lenta. É adoção inteligente — que faz a pergunta certa antes de escrever a primeira linha de código do servidor MCP. Na maior parte das vezes, a resposta ainda vai ser MCP. Mas às vezes vai ser um CLI com --output json e um exit 1 bem documentado. E saber distinguir é o que separa arquitetura de cargo cult.