MCP vs Chamadas Diretas de API — Minha Pilha de Agentes Não Tem Servidores MCP

O Protocolo de Contexto do Modelo está em toda parte agora. Todo tutorial de agente começa com "primeiro, configure seus servidores MCP." E ainda assim, a pilha de agentes que está rodando na máquina de onde estou digitando isso — monitoramento de busca, alertas do Telegram, postagens sociais, um assistente de voz — contém exatamente zero servidores MCP. Tudo se comunica com serviços externos através de chamadas diretas de API.

Isso não é uma rejeição ao MCP. É um protocolo, não um movimento — e a enxurrada de conteúdo sobre arquitetura de agentes continua transformando decisões de encanamento em decisões de identidade. Você não é uma "loja MCP" ou "está atrasado." Você está fazendo uma escolha de integração por carga de trabalho, e isso se resume a dois portões: um decide se o MCP é mesmo a categoria relevante, o outro decide se vale a pena o overhead.

Portão um — relevância: um modelo escolhe a ferramenta em tempo de execução?

O MCP existe para resolver um problema específico: um modelo de linguagem, durante a sessão, decidindo qual ferramenta usar. O protocolo padroniza como um modelo descobre ferramentas, como seus esquemas se parecem e como os resultados retornam. Essa é toda a sua razão de existir — é um protocolo voltado para o modelo. Se nenhum modelo estiver escolhendo, o MCP não é a categoria relevante; você compartilharia uma biblioteca ou levantaria um serviço simples.

Agora olhe para o que a maioria da automação realmente é. Meu pipeline de relatório matinal:

1. Cron dispara às 8:30
2. Script chama a API do Google Search Console
3. Script formata os números
4. Script posta no Telegram

O modelo não está decidindo nada aqui. Não há escolha de ferramenta em tempo de execução — o único trabalho do modelo em pipelines como este é ler os dados em uma etapa, não buscá-los. A ordem das chamadas é fixa, todos os dias, para sempre. Para essa carga de trabalho, o MCP não é a questão.

Uma sutileza que importa mais tarde: o portão um é avaliado sobre um superfície de ferramentas dos consumidores, não sobre a carga de trabalho à sua frente. O pipeline cron nunca passará por isso. Mas o acesso aos dados de busca por baixo dele pode — no dia em que um cliente orientado por modelo quiser os mesmos dados. O pipeline não é um candidato a MCP; a superfície pode se tornar uma.

De qualquer forma: ser um agente não é o critério. Muitas sistemas agentes são pipelines determinísticos com um modelo fazendo interpretação no meio.

Portão dois — valor: quem mais se beneficia do padrão?

Aqui está o caso que me ensinou que o portão um não é suficiente. Meu assistente de voz passa por ele: o modelo mapeia o que eu digo para um dos scripts nesta máquina em tempo de execução. Essa é uma seleção genuína de ferramentas — exatamente o território do MCP.

E o MCP ainda não vale a pena lá. O modelo seleciona entre oito scripts conhecidos, em uma máquina, em um cliente, todos escritos por mim. Um dicionário mapeando intenção para caminho de script faz o trabalho em vinte linhas. O MCP me daria uma interface padronizada para algo que tem exatamente um consumidor e um autor.

Assim, o portão dois tem duas portas, e passar por qualquer uma justifica o overhead:

• Um segundo consumidor. Se um agente de codificação, um assistente de desktop e uma interface de chat precisam todos acessar seu banco de dados, escrevê-lo uma vez como um servidor MCP supera três integrações personalizadas. A padronização é o produto.
• Ferramentas que você não escreveu. Servidores MCP de terceiros — navegadores, bancos de dados, plataformas SaaS — lhe dão capacidades sem que você precise criar o cliente da API você mesmo. Para ser preciso sobre o que você está comprando: a propriedade inverte o custo de autoria, não o custo de operação. Você ainda executa a conexão, a autenticação, a fixação de versão e a superfície de falha do servidor — mais sobre isso abaixo. Mesmo assim, com um único consumidor, não escrever e manter o código do cliente é muitas vezes a melhor parte do negócio.
• O caso degenerado de ambos: sessões genuinamente abertas. Trabalho interativo de agente onde você não pode prever qual das quarenta ferramentas em sua maioria de terceiros a próxima solicitação precisa. Nesse nível, a descoberta de esquema e a invocação uniforme deixam de ser cerimônia e se tornam a única opção sensata.

A regra comprimida: o modelo escolhendo torna o MCP relevante; um segundo consumidor — ou ferramentas de outra pessoa — torna-o valioso.

Como minha pilha realmente se parece

O custo que ninguém menciona

Em plataformas gerenciadas, servidores MCP parecem gratuitos — embora "gratuito" lá signifique uma conta diferente: latência, opacidade e acoplamento à disponibilidade de outra pessoa. Em metal nu, o custo é inconfundível. Cada servidor MCP é outro processo: ele inicia na inicialização ou não, registra em algum lugar ou não, mantém credenciais, tem versões, pode travar. Minha pilha de monitoramento existe porque aprendi que qualquer coisa rodando sem supervisão falha silenciosamente mais cedo ou mais tarde. Cada integração que adiciono é uma coisa que meu eu futuro depura às 8 da manhã quando o relatório matinal não chega.

Uma chamada de API direta dentro de um script cron tem uma superfície de falha: o script. Uma integração MCP tem três: o cliente, o servidor e o transporte entre eles. Esse é o custo operacional que servidores de terceiros não removem — eles economizam você de escrever o cliente, e então lhe entregam um processo para manter vivo. Às vezes, essa troca vale a pena. Para um pipeline diário fixo, não vale.

Onde eu buscaria isso — e onde minha regra se dobra

Se eu conectar um segundo cliente aos dados desta máquina — digamos, um assistente de desktop que precisa do mesmo acesso aos dados de busca que meus scripts têm — esse é o gatilho. Dois consumidores, uma superfície de ferramenta: escreva o servidor MCP, aponte ambos os clientes para ele, exclua a cola duplicada. No momento em que a padronização tem mais de um beneficiário, o overhead se transforma em alavancagem.

Uma honesta ressalva sobre o escopo. "Espere pelo segundo consumidor, então migre" é racional para mim porque sou um operador solo em uma máquina que controlo totalmente — serei eu quem notará o gatilho, e conheço cada linha da cola que estaria substituindo. Em uma equipe, o segundo consumidor muitas vezes aparece sem aviso, depois que o autor original saiu, e o custo da migração adiada recai sobre alguém que precisa reverter a engenharia da cola primeiro. Nesse cenário, pagar antecipadamente pela abstração pode ser a escolha certa antes que o portão dois se abra formalmente. Os portões não mudam; quem está em pé diante deles muda.

Até que meu segundo consumidor apareça, a resposta entediante permanece: cron, um script, uma chamada HTTP e um arquivo de log. O modelo escolhendo torna o MCP relevante. Alguém mais se beneficiando do padrão torna-o valioso. Tudo o mais são tutoriais.