MCP 2026: a pilha de conectividade em três camadas

TV
Thiago Victorino
8 min de leitura
MCP 2026: a pilha de conectividade em três camadas
Ouvir este artigo

No dia 19 de abril, David Soria Parra subiu ao palco da AI Engineer. Ele é co-criador do MCP, da Anthropic. Quando ele diz o que vem pela frente, não é previsão de analista: é divulgação de roadmap.

Dois pontos chamaram atenção.

Primeiro: o Progressive Discovery, padrão que descrevemos em março como aposta contrarian em A Crise do Contexto, agora é o comportamento default do Claude Code. Não é mais experimento. É a forma como o cliente da Anthropic carrega ferramentas por padrão, com redução de 85% no consumo de contexto em benchmarks internos e 98,7% quando composto com execução de código (150 mil tokens caem para 2 mil em um workflow Google Drive → Salesforce).

Segundo: o Code Mode recebeu validação de palco. A ideia é dar ao modelo um interpretador V8 ou Lua em vez de orquestrar chamadas de ferramentas através de inferência. Soria Parra citou o trabalho da Cloudflare: 81% de redução de tokens no caso geral, 94% no portal interno (52 ferramentas viraram duas, search e execute), 99,9% na superfície completa da API da Cloudflare (1,17 milhão de tokens caem para cerca de mil). Citou, de passagem, o FastMCP da comunidade: “é muito melhor do que o Python SDK que a gente entrega.” Escreveu o Python SDK, aliás, ele mesmo.

Isso basta de batida de validação. O que importa é que a arquitetura que descrevemos como aposta agora é o terreno. E o terreno recontextualiza decisões de compra.

A tese que muda a conversa

Aqui está a frase da keynote que vale reler com atenção:

“Se alguém te disser que existe uma solução para todos os seus problemas de conectividade, seja computer use, seja MCP, essa pessoa provavelmente está errada.”

Essa frase mata, em 25 palavras, o pitch de um ano inteiro do próprio ecossistema da Anthropic. “MCP para tudo” não é mais a posição oficial. A posição oficial, agora, é uma pilha de três camadas, cada uma com um trabalho distinto, cada uma com uma decisão de procurement distinta, cada uma com uma superfície de governança distinta.

A pilha é: Skills + MCP + CLI/computer use.

Skills carrega conhecimento procedural. É um arquivo, ou uma pasta de arquivos, que descreve como executar uma tarefa específica do seu domínio: as regras de categorização de despesa da sua empresa, o formato de relatório que o CFO quer ver, a checklist de due diligence do seu time jurídico. Skill é a camada onde mora a sua peculiaridade organizacional. Não é código, não é API. É instrução reutilizável, versionada, auditável como documento.

MCP carrega semântica rica. É o protocolo quando você precisa de UI, autenticação, governança, independência de plataforma, tarefas de longa duração, elicitação, resources. MCP é a camada em que a Anthropic investiu dezoito meses construindo primitivos que nenhum wrapper REST consegue replicar. É também a camada que vai receber, ao longo de 2026, a maior parte dos anúncios que Soria Parra listou: transporte stateless, cross-app access, server discovery, skills-over-MCP.

CLI e computer use carregam composição local. É o que você alcança quando o agente roda em sandbox, com acesso ao shell, e pode se beneficiar de ferramentas que o modelo já viu exaustivamente no pré-treinamento: git, gh, kubectl, aws. Quando a ferramenta tem décadas de documentação no Stack Overflow, o modelo não precisa de schema elaborado. Precisa de --help.

A decisão de engenharia, a partir de 2026, não é mais “qual protocolo eu adoto?” A decisão é: para cada capacidade do meu agente, qual das três camadas é a mais adequada, e quem audita cada uma delas?

Por que isso reorganiza procurement

Quem compra software corporativo aprendeu, nos últimos dois anos, a perguntar sobre MCP. A pergunta era binária: seu produto fala MCP ou não? Era suficiente quando “MCP” era sinônimo de “toda a conectividade do agente.” Não é mais. Cada item do roadmap vira uma pergunta nova que o comprador precisa fazer antes de assinar o contrato.

Transporte stateless (meta: junho de 2026). Soria Parra atribuiu a proposta aos “amigos do Google.” Vale nomear o que foi suavizado. O Google é co-fundador, junto com Anthropic, OpenAI, Microsoft, AWS e Block, da Agentic AI Foundation, criada na Linux Foundation em dezembro de 2025. A AAIF é a casa política do MCP e também do A2A, o protocolo agent-to-agent que o Google doou à Linux Foundation em junho de 2025. “Transporte stateless do Google” é, portanto, um hyperscaler co-governando a spec em direção a padrões de deployment que favorecem operação em escala (Cloud Run, Kubernetes, Lambda). Isso é bom para quem quer escalar MCP como se fosse REST. Mas a pergunta que o comprador precisa fazer é: o vendor contratado tem plano para transportar estado entre requests, ou está apoiado em sticky sessions que vão quebrar quando o spec de junho mudar?

Cross-app access. O roadmap anuncia SSO corporativo entre servidores MCP, através do provedor de identidade da empresa (Okta, Google, Entra). Isso cai diretamente sobre o plano de Identidade da taxonomia que discutimos ontem. Hoje, conectar um agente a cinco aplicações SaaS significa cinco fluxos OAuth, cinco conjuntos de escopos, cinco trilhas de auditoria. Cross-app access colapsa isso em uma única fronteira de identidade. Maravilha para o usuário. Pesadelo para o CISO que não souber perguntar: como o vendor pretende escopar, rotacionar e revogar credenciais que agora atravessam múltiplos servidores sob um único login?

Server discovery via .well-known/mcp. Este é discreto e transformador. A partir da próxima spec, navegadores, crawlers e agentes vão poder perguntar a qualquer site: “existe um servidor MCP aqui?” O seu domínio vai anunciar capacidades a agentes da mesma forma que o robots.txt anunciou crawling para buscadores, dez anos atrás. Isso é ótimo para adoção. É péssimo para quem não souber que, a partir de junho, a detecção de shadow-MCP fica assimétrica. Qualquer engenheiro pode publicar um servidor MCP sob um subdomínio corporativo. A pergunta: quem monitora, na sua empresa, os endpoints .well-known/mcp que apontam para o seu nome?

Skills-over-MCP. A extensão que permite ao autor do servidor empacotar instruções procedurais junto das ferramentas. O argumento comercial é elegante: hoje, o engenheiro de vendas instala um servidor MCP e, em seguida, caça manualmente a Skill certa para usá-lo bem. Com skills-over-MCP, o autor do servidor entrega os dois. Mas a pergunta de segurança é imediata: quem audita o conteúdo da Skill que chega empacotada com o servidor? Uma Skill pode carregar prompt injection tão facilmente quanto uma descrição de ferramenta. A própria camada de instruções procedurais passa a ser superfície de ataque, e poucos times de segurança corporativa estão preparados para revisar texto operacional como código.

Code Mode e o sandbox. A frase “dá ao modelo um V8 isolate” soa como feature flag. Operar com segurança é projeto de security engineering. O post de referência da Cloudflare descreve sete camadas de defesa em profundidade para exatamente esse padrão: limites de recursos, capability gating, ponte RPC para ferramentas apenas, globais bloqueadas, filtragem de syscalls, controle de egresso, logging de auditoria. A Cloudflare consegue fazer isso porque isolates são o negócio principal dela. Um vendor de mid-market que prometer “Code Mode” num pitch Q2 provavelmente está subestimando o que a palavra implica. A pergunta: como o vendor isola, monitora e restringe a execução de código que o agente escreve em tempo real?

O que não foi dito na keynote

Soria Parra abriu com uma comparação: 110 milhões de downloads mensais dos SDKs MCP, “duas vezes mais rápido do que o React alcançou volume equivalente.” O número é verdadeiro no literal, desonesto no analítico. Esses downloads são, em maioria absoluta, dependências transitivas: quando um time instala LangChain ou o Agents SDK da OpenAI, o SDK do MCP entra junto, usado ou não. Volume de download mede distribuição do pacote, não uso em produção. Trate como “os SDKs do MCP são hoje dependência default nos frameworks de agente mais populares.” Não trate como métrica de adoção.

Ele também enquadrou 2026 como “o ano em que agentes de knowledge worker entram em produção.” É a tese da Anthropic, que vende capacidade de modelo e tem interesse comercial nessa narrativa. A realidade medida é mais modesta. Os relatórios de 2026 da Writer, Deloitte e PwC mostram ROI organizacional de agentes em torno de 23%, com quase 80% das empresas relatando dificuldade para colocar agentes em produção. Conectividade não é o gargalo. Avaliação, confiança e redesenho de workflow são os gargalos. A pilha de três camadas resolve a parte mais fácil do problema.

Progressive Discovery, por fim, reduz custo de contexto e troca por qualidade de recuperação. O modelo agora precisa decidir que precisa de uma ferramenta, formular uma query útil e escolher entre resultados. Cada etapa é um novo modo de falha. Falha silenciosa, quando a busca ignora a ferramenta certa e o modelo prossegue como se ela não existisse, é pior do que a falha ruidosa do context bloat. A keynote não traz métrica de recall nem de precisão. Quem for adotar, terá que medir por conta própria.

A pergunta verdadeira

O MCP não é o padrão. É um padrão, consolidando-se como camada de conectividade de ferramentas dentro de uma pilha multi-standard que inclui Skills, CLI, REST legado e A2A para comunicação agent-to-agent. A keynote foi um ato de maturação: o próprio co-criador abandonou a narrativa de “MCP para tudo” e ofereceu, no lugar, um mapa com três camadas e uma dúzia de itens de roadmap.

Se a sua empresa vai assinar contratos de agente no segundo trimestre de 2026, o contrato precisa carregar perguntas sobre todos os itens desse mapa. Não porque o roadmap seja lei (roadmaps escorregam), mas porque os vendors que não souberem responder hoje são os mesmos que vão entregar dívida técnica quando a spec de junho aterrissar.

A Victorino escreveu em março sobre progressive disclosure como aposta contrarian. Ontem, sobre a superfície de governança que a Cloudflare publicou como arquitetura de referência. Hoje, sobre a pilha de três camadas. A tese é consistente: a conectividade do agente é um problema de arquitetura e de auditoria, não de escolha de vendor. Cada camada precisa de dono, de política e de evidência de operação. Quem comprar sem essa disciplina vai pagar duas vezes: uma no contrato, outra na remediação.


Fontes

A Victorino ajuda empresas a construírem sistemas de IA governados na camada de conectividade — para que a sua pegada MCP seja auditável, escopada e segura para produção: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa