Na semana passada, a Perplexity anunciou que estava abandonando o MCP e voltando às APIs tradicionais e a uma ferramenta de linha de comando.
Adoro o MCP. Uso-o frequentemente para conectar meus sistemas locais aos meus frameworks de agentes. Ele torna o LangGraph e o Strand uma maravilha. No entanto, o MCP é uma gambiarra, um protocolo ingênuo que nunca deveria sair da sua rede local. Não tem conserto. Não dá para adaptá-lo a uma boa arquitetura.
A simplicidade é seu principal diferencial: uma API para quem não quer se preocupar com APIs; uma espécie de porta USB para que agentes se conectem universalmente a outros aplicativos. É uma ótima solução para expor seus serviços locais aos seus agentes locais. A configuração é rápida e a solução é resiliente a mudanças. Se você precisa implementar algo rapidamente e não para produção, é a solução perfeita.
Mas a internet não é, e não pode ser construída com base em conexões USB. Redes de agentes distribuídos, pelo menos por enquanto, não podem ser construídas por pessoas que não se preocupam com APIs. O MCP não é de nível empresarial nem para a internet. No entanto, na terra dos ingênuos, a resposta mais fácil de entender acaba se tornando a resposta, criando uma bomba-relógio inevitável.
Condenado pela Ingenuidade
O MCP segue uma longa tradição de softwares fracassados. Em algum momento do passado, alguma tecnologia empresarial poderosa já resolveu todos esses problemas e foi testada e comprovada em larga escala na internet. No entanto, essas estruturas são complexas e possuem altas barreiras de entrada.
Uma equipe inteligente percebeu que não tinha todos os recursos e a escalabilidade de uma solução empresarial. Em vez disso, precisavam de velocidade e simplicidade. Após algumas concessões bem-intencionadas, surgiu uma solução inteligente, rápida e fácil de implementar, capaz de colocar seu projeto em funcionamento. É ótima para uma demonstração, perfeita para uma ferramenta interna ou para automatizar aquela tarefa semanal.
Tudo vai bem até que se torne popular ou alguém decida lançá-lo, disfarçando-o de tecnologia madura. As valiosas lições sobre segurança, escalabilidade e encapsulamento aprendidas com as gerações anteriores de APIs foram completamente ignoradas. É como ver engenheiros reinventando a roda isoladamente, sem saber que já existe uma fábrica ali perto. Eles poderiam simplesmente ir até a fábrica e sair na frente, mas se deixam seduzir pelo prédio em vez de se dedicarem à integração. A sensação é de maior produtividade. Quebrar o que já existe é visto como algo disruptivo. Reconstruir a roda é apresentado como inovação.
O que as APIs empresariais realmente resolvem
Todo software em grande escala é construído sobre software que você não controla. Todo serviço de internet se conecta a outros serviços, outras empresas, outras equipes ou outros desconhecidos. O problema fundamental que as APIs corporativas resolvem não é como se conectar; é como se conectar a sistemas nos quais você não confia, que você não controla.
É um problema complexo. Foram necessários trinta anos de dolorosas lições sobre violações de segurança, falhas em cascata e desastres de auditoria para construir os padrões que hoje chamamos de arquitetura empresarial. Autenticação, autorização, limitação de taxa, versionamento, separação de responsabilidades, trilhas de auditoria e contratos de qualidade de serviço não são burocracia. São a solução.
O MCP ignora tudo isso porque nunca foi projetado para cruzar um limite de confiança. Não precisava. Foi projetado para chamar aplicativos locais, um agente se comunicando com ferramentas na mesma máquina, dentro de um perímetro seguro. Isso é adequado para o que se propõe. O problema é confundir o MCP com algo para o qual ele nunca foi projetado.
Não se pode administrar um banco da mesma forma que uma empresa familiar administra um caixa. O caixa funciona porque todos na sala são conhecidos e confiáveis. O banco funciona porque ninguém é.
As vantagens do MCP.
Assim como o USB, o MCP oferece uma interface simples e intuitiva. Os agentes não precisam aprender novas APIs para cada ferramenta. Contanto que uma ferramenta seja compatível com MCP, ela pode ser integrada a qualquer agente.
A camada de linguagem natural cria descoberta automatizada e mapeamento de APIs. Se você adicionar uma nova ferramenta, atualizar uma versão ou substituir uma ferramenta por outra, não haverá nenhuma alteração no agente. Ele descobrirá tudo dinamicamente.
Por exemplo, se você tivesse um servidor MCP conectado ao seu e-mail e calendário, poderia criar um agente que verificasse solicitações de reunião e as agendasse em seu calendário. Ao adicionar o Slack ao seu servidor MCP, ele estará instantaneamente disponível para o seu agente. Agora, ele poderá receber solicitações de reunião e responder a perguntas via Slack.
Isso seria muito mais difícil com APIs corporativas clássicas. Cada alteração representa um novo contrato. Cada nova ferramenta exige mais uma integração. O MCP utiliza LLMs para automatizar grande parte da infraestrutura e transformar projetos corporativos de meses em complementos prontos para uso. Ele resolve um problema real.
Qual é, então, o problema com o MCP?
Para integrações internas rápidas, não há muitas opções. Mas todos nós já vimos planilhas se transformarem em bancos de dados essenciais para os negócios. Todos nós já vimos ferramentas criadas em um fim de semana que agora processam milhões de dólares em transações, com o apoio apenas de orações fervorosas para que um auditor nunca as descubra.
O MCP está quebrado. Não é confiável. Não é escalável. Não lida bem com falhas. Não pode ser protegido.
A flexibilidade é o seu primeiro problema. O que torna o MCP tão fácil de implementar é também o motivo pelo qual não se pode confiar nele. Não existem contratos. É um sistema não determinístico que não faz promessas sobre o que fará. Se você estiver em uma situação de baixo risco, então a baixa confiança provavelmente não será um problema. Se você espera que cada solicitação seja revisada por um humano responsável, por que perder tempo restringindo um sistema que, de qualquer forma, terá um humano envolvido?
A escala de contexto é o segundo problema. A Perplexity descobriu que a sobrecarga do esquema do servidor MCP consome 72% da janela de contexto do agente antes mesmo da primeira requisição ser feita. A linguagem humana é ótima para uma conversa informal, mas péssima para o uso eficiente de largura de banda e CPU. APIs corporativas geralmente separam descoberta, comando e dados em canais diferentes, cada um otimizado para sua função. Descoberta e comandos não mudam com frequência e podem ser armazenados em cache ou até mesmo compilados pelo cliente. Você não precisa consultar dinamicamente quais ferramentas e comandos estão disponíveis em cada sessão, nem gerar código do cliente em tempo real cada vez que repete a requisição com dados diferentes.
O ponto forte do MCP é a automação da descoberta, mas a descoberta dinâmica e a vinculação de dados já são abordadas há mais de 30 anos por protocolos consolidados como CORBA e SOAP. O MCP não precisava reinventar a roda, muito menos ser tão ingênuo sobre o funcionamento das APIs. Não é necessário consumir tokens para automatizar a descoberta. Você pode facilmente direcionar um agente para um endpoint OpenAPI e gerar e armazenar em cache uma ferramenta cliente que seu agente local pode reutilizar até que algo mude.
Em terceiro lugar, o MCP não está preparado para a escala da internet. O protocolo é baseado em um modelo de chat sobre HTTPS. O cliente envia mensagens por meio de conexões HTTPS simples, mas o servidor responde por meio de uma conexão estática e com estado. Cada sessão consiste em duas conexões, sendo que uma delas deve permanecer aberta durante toda a sessão. Nenhum servidor escala dessa forma. Os servidores não podem desperdiçar uma porta de rede com um cliente ocioso. Não há previsão para reconexão. O servidor não pode simplesmente descartar a conexão e migrá-la para outro servidor. Não é possível realizar failover. Não é possível reequilibrar a carga. Não é possível descartar uma conexão ociosa e recuperá-la ao reconectar.
Em quarto lugar, o MCP trata a segurança como um recurso opcional. Não existe o conceito de autenticação ou autorização. O MCP não é construído sobre uma pilha de protocolos complementares, como o OpenAPI ou o A2A. Ele aproveita a segurança, a escalabilidade e a confiabilidade das camadas subjacentes para construir APIs que permitem chamadas remotas em uma base pronta para uso corporativo. O MCP não utiliza HTTPS. É um chatbot criado para usar ferramentas locais, que foi adaptado da entrada/saída padrão local para a rede via HTTPS.
As equipes tentarão resolver o problema encapsulando suas chamadas em OAuth, SAML ou outros padrões compatíveis com HTTPS, mas não existe um padrão MCP. Essas soluções alternativas comprometem a facilidade de uso do plug-and-play e, na maioria das vezes, serão contornadas. A Knostic, empresa especializada em segurança de IA, identificou 1.862 servidores MCP expostos à internet e verificou manualmente 119 deles, constatando que todos permitiam acesso a listas de ferramentas internas sem autenticação.
O que fazer?
O MCP local ainda faz sentidoÉ para isso que foi feita e é o que faz bem.
A boa notícia é que as APIs corporativas são um problema bem resolvido. A má notícia é que você pode precisar capacitar sua equipe de inventores inovadores. Se você pretende usar agentes que superam barreiras de confiança, disponibilizá-los por meio de sistemas na internet ou como parte de qualquer sistema comercial que exija confiança e/ou auditorias, então procure soluções além do MCP.
A API Agent-to-Agent (A2A) do Google é uma API específica para agentes, criada para esse domínio. Minhas equipes têm obtido bons resultados com os endpoints REST OpenAPI tradicionais. Eles são bem compreendidos pelos nossos clientes e nos permitiram aproveitar nossa infraestrutura existente, em vez de criar uma nova pilha de tecnologias paralelas.
Minha equipe é uma organização de grande porte. Já possuímos as habilidades e a infraestrutura necessárias para o ambiente corporativo. Não foi um grande salto trazer nossas melhores práticas para o mundo dos agentes e superar o MCP. Para empresas ou equipes que não têm essa experiência, quanto mais cedo pararem de tentar corrigir o MCP, mais rápido poderão migrar para agentes corporativos.
Não é que a Arquitetura Empresarial ainda não tenha se adaptado aos agentes autônomos. Estamos começando a perceber como os agentes se encaixam em nossos sistemas empresariais. Infelizmente, as pessoas que desenvolvem os agentes geralmente não são as mesmas que desenvolveram os sistemas empresariais. Mas não precisa ficar perplexo, é hora de deixarmos o MCP de lado como o conector universal.
Fonte: Lucas McGregor
