O protocolo que virou hype e agora vira problema
Em janeiro de 2026, Denis Yarats, CTO da Perplexity AI, compartilhou internamente uma decisão que poucos esperavam: a empresa estava abandonando o Model Context Protocol (MCP) e migrando suas integrações para APIs diretas e CLIs. A notícia vazou para a comunidade de desenvolvedores de IA e gerou exatamente o tipo de debate que o mercado precisava ter — mas ainda evitava.
“MCP resolve um problema de demos. APIs e CLIs resolvem problemas de produção. Não são a mesma coisa.” — síntese da posição técnica da Perplexity, conforme relatos internos da equipe de engenharia
Este artigo não é um obituário do MCP. É uma análise do que acontece quando um protocolo promissor encontra a realidade das empresas que precisam de segurança, compliance e previsibilidade — não de mais uma camada de abstração entre o agente e o dado.
O que é MCP e por que todo mundo adotou rápido demais
O Model Context Protocol foi lançado pela Anthropic em novembro de 2024 como um padrão aberto para conectar modelos de linguagem a fontes de dados externas — bancos de dados, APIs, ferramentas, sistemas de arquivos. A proposta era elegante: em vez de cada empresa construir integrações customizadas para cada LLM, o MCP criaria um protocolo universal.
A adoção foi rápida. Em três meses, centenas de servidores MCP foram publicados no GitHub. IDEs como Cursor e Windsurf integraram o protocolo. A comunidade NoCode e de agentes de IA tratou o MCP como o “USB-C dos agentes” — uma metáfora sedutor que, infelizmente, ignorava diferenças críticas entre conectar um periférico e conectar um agente de IA a sistemas corporativos.
- Velocidade de adoção: mais de 1.000 servidores MCP públicos em 90 dias após o lançamento
- Ecossistema entusiasta: suporte imediato de Claude, Cursor, Windsurf, Zed e dezenas de ferramentas
- Caso de uso dominante: desenvolvimento local, automações pessoais, protótipos
O problema: desenvolvimento local e produção corporativa são ambientes completamente diferentes. E o MCP foi desenhado para o primeiro, não para o segundo.
Por que o MCP falha em produção: os três problemas reais
Problema 1: stdio como transporte padrão
O MCP usa stdio (entrada/saída padrão) como mecanismo de transporte primário. Isso funciona perfeitamente para uma sessão local onde o desenvolvedor controla o ambiente. Em produção, onde os agentes rodam em containers, ambientes serverless ou pipelines de CI/CD, o stdio introduz problemas sérios:
- Sem autenticação nativa entre cliente e servidor MCP
- Sem criptografia de transporte no modo stdio local
- Dificuldade de auditoria de logs em escala
- Incompatibilidade com proxies corporativos e firewalls
O modo SSE (Server-Sent Events) existe como alternativa para ambientes remotos, mas adiciona complexidade de deploy que apaga boa parte da promessa de simplicidade do protocolo.
Problema 2: superfície de ataque ampliada
A pesquisa da Astrix Security (2025) documentou vulnerabilidades críticas em implementações MCP reais:
- Tool Poisoning: um servidor MCP malicioso pode sobrescrever o comportamento de ferramentas legítimas via descrições manipuladas — o modelo lê as descrições e executa ações não autorizadas
- Prompt Injection via MCP: dados retornados por ferramentas MCP podem conter instruções que redirecionam o comportamento do agente
- Privilege Escalation: servidores MCP com acesso a sistemas de arquivos locais ou APIs podem ser usados para escalar privilégios além do escopo intencionado
- Rug Pull Attack: um servidor MCP pode mudar comportamento depois de instalado, sem que o usuário perceba
Para empresas sujeitas a SOC 2, ISO 27001 ou LGPD, cada um desses vetores representa um risco real de auditoria — e nenhum deles tem mitigação nativa no protocolo.
Problema 3: compliance sem resposta
APIs diretas têm décadas de padrões de segurança estabelecidos: OAuth 2.0, HMAC signatures, rate limiting, auditoria por IP, logging estruturado. CLIs corporativas têm gestão de credenciais, integração com ferramentas de secrets management (Vault, AWS Secrets Manager) e trilha de auditoria.
O MCP tem nenhum desses controles nativamente. Cada implementação resolve (ou ignora) à sua maneira. Para times de segurança corporativa, isso não é uma lacuna de feature — é um bloqueador de adoção.
A decisão da Perplexity: maturidade, não retrocesso
Denis Yarats e o time de engenharia da Perplexity chegaram a uma conclusão que outros times de produção estão chegando em silêncio: o MCP é excelente para prototipagem e uso individual, ruim para sistemas que precisam de SLA, segurança e observabilidade.
A migração para APIs diretas e CLIs não é um recuo tecnológico. É a mesma decisão que qualquer engenheiro sênior toma quando precisa colocar algo em produção real:
- APIs diretas têm contratos estáveis, versionamento explícito, SDKs maduros e padrões de autenticação consolidados
- CLIs são composáveis, auditáveis, fáceis de integrar em pipelines existentes e não dependem de um protocolo de terceiro
- MCP adiciona uma camada de indireção que, em produção, se traduz em: mais pontos de falha, menos controle, superfície de ataque maior
A Perplexity não abandonou a ideia de agentes conectados a ferramentas. Abandonou a aposta de que um protocolo emergente, sem histórico de produção, fosse o caminho certo para sistemas críticos.
Comparativo: MCP vs API vs CLI em produção
A tabela abaixo resume as três abordagens nas dimensões que importam para times de engenharia e segurança:
- Autenticação: MCP = implementação manual variável | API = OAuth/HMAC nativo | CLI = secrets manager integrado
- Auditoria: MCP = logs não padronizados | API = logging estruturado por padrão | CLI = trilha de auditoria nativa
- Compliance: MCP = sem padrão | API = SOC 2 / ISO 27001 documentado | CLI = políticas de IAM aplicáveis
- Versionamento: MCP = por servidor (variável) | API = contrato versionado | CLI = versionamento semântico
- Superfície de ataque: MCP = alta (tool poisoning, prompt injection) | API = controlada | CLI = controlada
- Ideal para: MCP = prototipagem local | API = integração de sistemas | CLI = automação e pipelines
O que isso muda para quem usa agentes de IA hoje
Se você está construindo agentes de IA para uso pessoal, em ambiente de desenvolvimento ou protótipos — continue usando MCP. O protocolo é genuinamente útil nesse contexto. A experiência de conectar um agente a um servidor MCP é notavelmente mais simples do que construir integrações customizadas.
Se você está construindo sistemas de agentes para empresas, com dados sensíveis, SLA definido, equipe de segurança envolvida e auditoria regulatória — a decisão da Perplexity é um sinal claro: invista em APIs diretas com autenticação robusta e CLIs composáveis. Adicione MCP como camada de conveniência somente onde o risco é controlável.
O mercado de agentes de IA está passando pela mesma maturação que todas as tecnologias passam: da fase de “isso é incrível” para a fase de “isso funciona em produção?”. O MCP está nessa transição agora.
O que a Anthropic e o ecossistema precisam fazer
A decisão da Perplexity não precisa ser o fim do MCP. Mas para o protocolo sobreviver no mercado corporativo, algumas evoluções são necessárias:
- Autenticação nativa obrigatória — não opcional, não delegada à implementação
- Logging estruturado padronizado — cada chamada de ferramenta deve gerar trilha auditável
- Sandboxing de servidores — isolamento de permissões por servidor, não por sessão
- Certificação de servidores públicos — algum mecanismo de vetting para o ecossistema open source
- Modo enterprise documentado — guia de deploy que passe em auditoria SOC 2
Sem essas evoluções, o MCP continuará sendo o que é hoje: uma ferramenta excelente para desenvolvedores e um risco inaceitável para CISOs.
FAQ: perguntas que o mercado está fazendo
MCP está morto?
Não está morto — está delimitado. O protocolo tem um espaço legítimo em desenvolvimento local, ferramentas pessoais e prototipagem. O que morreu é o hype de que MCP seria o padrão universal para agentes em produção corporativa. Perplexity acelerou essa conclusão, mas outros times de engenharia estavam chegando lá de qualquer forma.
Devo migrar minhas integrações MCP para APIs diretas?
Depende do contexto. Se seus agentes rodam em ambiente controlado, sem dados regulados e sem SLA crítico — não há urgência. Se você está construindo para clientes corporativos ou lidando com dados sensíveis — sim, priorize APIs com autenticação robusta. O risco não é teórico.
A decisão da Perplexity vai influenciar outros players?
Já está influenciando. Times de engenharia que acompanham o espaço de agentes de IA estão revisando suas decisões arquiteturais. A pergunta não é mais “vamos usar MCP?” mas “onde MCP faz sentido vs. onde precisamos de algo mais robusto?”. Essa é a pergunta certa.
O que acontece com os servidores MCP já em produção?
A maioria funciona e continuará funcionando para os casos de uso para os quais foi construída. O risco está em expandir o uso de MCP para contextos de maior criticidade sem revisar a postura de segurança. A recomendação é: auditoria das permissões dos servidores existentes e avaliação do modelo de ameaças antes de escalar.
Existe alternativa ao MCP que já tem maturidade de produção?
Sim. Function Calling via API (OpenAI, Anthropic, Google) combinado com backends próprios é a abordagem mais madura. LangChain Tools e LlamaIndex oferecem abstrações com mais controle sobre o ciclo de vida das ferramentas. OpenAPI specs como fonte de truth para geração de integrações é outra abordagem com histórico de produção consolidado.
Conclusão: o mercado amadureceu, o protocolo precisa acompanhar
A saída da Perplexity do MCP não é uma crítica ao protocolo em si — é um sinal de que o mercado de agentes de IA chegou em um ponto de maturidade onde as escolhas arquiteturais importam tanto quanto as capacidades dos modelos. Sistemas que precisam de segurança real, compliance documentado e operação previsível não podem depender de protocolos que ainda estão resolvendo problemas básicos de autenticação e auditoria.
Isso não é retrocesso. É engenharia responsável. E se você está construindo agentes de IA para empresas — é exatamente esse tipo de raciocínio que seus clientes esperam de você.
Quer entender como construir arquiteturas de agentes de IA que funcionam em produção — com segurança, rastreabilidade e escala? Converse com o time da Posicionamento Digital.
