MCP é uma Camada de Transporte Fingindo Ser um Cérebro

Um post viral no HN esta semana chamou a explosão do MCP de "um pesadelo de sistemas distribuídos." O argumento: agora temos centenas de servidores MCP, agentes os chamam livremente, e ninguém resolveu o problema de coordenação de qual ferramenta chamar quando. O resultado são loops infinitos, créditos queimados e fundadores solitários encarando um buraco de $20 no saldo da API após o almoço.

Eu conheço esse problema pessoalmente porque eu o causei.

O Intervalo do Almoço de $20

Eu estava construindo um projeto educacional no ano passado. O código tinha um loop que tentava chamadas de API quando a resposta voltava nula — um padrão defensivo padrão. Exceto que as respostas não estavam realmente falhando. Elas não estavam sendo salvas corretamente. O código de armazenamento estava quebrado, então o loop continuava vendo nulo, continuava tentando, continuava chamando a Anthropic.

Eu fui almoçar. Voltei uma hora depois. Todo o crédito de $20 foi embora.

Agora, $20 não é uma quantia que muda a vida. Mas sentar lá olhando para o painel de uso, duas coisas me atingiram ao mesmo tempo. Primeiro, a maioria dessas chamadas eram tarefas simples — resumir isso, extrair aquilo — que não precisavam do modelo que eu estava enviando. Eu estava pagando preços de Sonnet por tarefas que um modelo muito mais barato poderia lidar sem quebrar nada. Segundo, não havia nada entre mim e a API que pudesse ter capturado isso. Nenhum orçamento. Nenhum monitor. Nenhum disjuntor. Apenas um loop e um modelo que estava feliz em continuar respondendo.

Isso foi o que me fez construir o Prism.

O Verdadeiro Problema com o MCP

O MCP é genuinamente conveniente. Ele padronizou o transporte — como os agentes falam com as ferramentas. Essa parte funciona. O problema é o que ele não padronizou: a intenção.

Agora, quando um agente tem acesso aos servidores MCP, ele chama o que considerar necessário, a menos que você lhe dê instruções muito específicas. Não há consciência orçamentária. Não há classificação de complexidade. Não há lógica de "isso é uma consulta simples, use o caminho barato" incorporada ao protocolo. O agente simplesmente dispara, e você paga.

O post do HN enquadrou isso como um problema de coordenação M×N — M agentes falando com N ferramentas sem uma camada de orquestração. Eu acho que isso está na direção certa, mas perde a formulação mais aguda. O problema não é que temos muitas ferramentas. O problema é que estamos tratando uma camada de transporte como se fosse inteligência.

O MCP diz ao agente como chamar uma ferramenta. Ele não diz ao agente se deve chamá-la, qual modelo deve lidar com a chamada, ou quanto essa chamada deve custar. Essas são decisões de roteamento e governança, e agora elas não estão em lugar nenhum. Elas não estão no protocolo. Elas não estão no agente. Elas estão na cabeça do desenvolvedor, codificadas como engenharia de prompt que quebra no momento em que o contexto fica complicado.

O que Realmente Precisa Acontecer

A visão do Gemini sobre isso foi "padronizar demais o transporte, padronizar de menos a intenção semântica." Eu concordo com o diagnóstico. Mas eu acho que a solução é mais específica do que "padronizar a intenção."

O que precisamos não é de uma especificação MCP mais inteligente. O que precisamos é de uma camada entre o agente e as ferramentas que faça três coisas:

Roteamento ciente do orçamento. Cada chamada MCP deve ter um teto de custo. Não um orçamento global que você verifica depois que a conta chega, mas um orçamento por tarefa que a camada de roteamento impõe antes da chamada ser feita. Consulta simples? Roteie para um modelo barato. Raciocínio complexo? Roteie para Sonnet ou Opus. Complexidade desconhecida? Classifique primeiro, depois roteie. A classificação em si deve custar quase nada.

Caminhos fixos para consultas regulares. A maioria dos fluxos de trabalho de agentes tem um pequeno número de padrões de consulta que se repetem constantemente. Extraindo um nome de um e-mail. Resumindo um documento. Procurando um esquema. Essas não deveriam passar pelo loop de raciocínio completo do agente toda vez. Elas deveriam seguir um caminho pré-definido que seja apertado, focado e barato. Pense nisso como agentes MCP com orçamentos fixos e rotas fixas — as coisas regulares permanecem hiper-otimizadas, e o caminho de raciocínio completo é reservado para tarefas genuinamente novas.

Um loop de feedback que aprende. A camada de roteamento deve ficar mais inteligente ao longo do tempo. Se uma tarefa consistentemente é roteada para um modelo caro e a saída é indistinguível do que um modelo barato produz, o sistema deve notar e ajustar. Se um servidor MCP específico consistentemente aciona tentativas, o sistema deve sinalizá-lo. Isso não é mágica de IA — é registro, pontuação e limites. Infraestrutura chata que ninguém quer construir, mas que todos precisam.

Onde o Prism se Encaixa

O Prism existe por causa do intervalo do almoço de $20. A primeira versão resolve a parte mais óbvia — roteando consultas para o modelo mais barato que não as quebrará. Três modos: Eco, Balanceado, Esporte. A classificação acontece antes da chamada, não depois. Isso sozinho teria salvado meus $20 porque metade dessas chamadas re-tentadas eram tarefas simples sendo enviadas para Sonnet.

Mas o roteamento é apenas a primeira camada. A visão é mais próxima de se tornar o Vercel da gestão de API de IA — um plano de controle que fica entre seu código e os modelos, lidando com roteamento, memória, orçamentos, monitoramento e otimização contínua. Não é outro provedor de modelo. Não é outro servidor MCP. A camada que torna todos eles utilizáveis sem queimar seus créditos enquanto você almoça.

Não chegamos lá ainda. O Prism hoje faz roteamento e memória de sessão. A imposição de orçamento, os caminhos fixos, o loop de feedback — isso é o que estamos construindo. Mas a arquitetura é projetada para isso, e o intervalo do almoço de $20 é a razão pela qual cada decisão começa com "qual é o custo por chamada."

O Quadro Geral

A explosão do MCP é uma coisa boa. Mais ferramentas, mais acesso padronizado, mais capacidade para construtores solitários. Mas estamos na fase em que todos estão empolgados com o acesso e ninguém está pensando na governança. É o mesmo padrão que os microserviços em 2016 — todos adotaram a arquitetura, ninguém construiu a observabilidade, e então todos passaram os próximos três anos adicionando monitoramento depois que a produção pegou fogo.

MCP sem uma camada de roteamento e governança é a mesma armadilha. O transporte funciona. A inteligência ainda não existe. E até que alguém a construa, todo hacker independente com um agente conectado ao MCP está a um único função de armazenamento quebrada de comprar o almoço do seu provedor de API.

Eu estou construindo essa camada. O Prism está ao vivo em ssimplifi.com — roteamento e memória de sessão hoje, governança orçamentária e otimização a seguir. Se você queimou créditos em um loop burro, você sabe por que isso importa.