MCP deixou de ser experimento e virou infraestrutura: o que muda para quem escreve software

De protocolo de um fornecedor a padrão de mercado

O Model Context Protocol foi apresentado pela Anthropic em novembro de 2024 como uma forma padronizada de conectar modelos de IA a ferramentas e fontes de dados. A trajetória desde então explica por que ele deixou de ser assunto de quem brinca com agentes e virou assunto de arquitetura:

• Em dezembro de 2025, a Anthropic doou o protocolo para a Agentic AI Foundation, sob a Linux Foundation — ou seja, ele passou a ser um padrão neutro, com governança de comunidade, e não o formato de uma empresa só.
• Foi adotado por OpenAI, Google DeepMind e Microsoft, além de milhares de times de desenvolvimento.
• O ecossistema passou de 110 milhões de downloads mensais.
• Em números mais conservadores, o relatório da Stacklok de 2026 aponta 41% das organizações pesquisadas com servidores MCP em produção, limitada ou amplamente.

O roteiro de 2026 confirma a direção: transporte stateless, descoberta de servidores, tasks de longa duração, autenticação corporativa, triggers, streaming e SDK v2. Nada disso é vocabulário de experimento — é vocabulário de camada de integração de produção.

O que isso significa na prática para o seu sistema

A leitura útil é esta: seu produto vai passar a ter dois tipos de cliente — pessoas e agentes. E as duas coisas que um agente precisa da sua API são justamente as que a maioria das APIs internas não tem.

Descrições que fazem sentido fora de contexto. Uma API interna pode ter um endpoint chamado POST /v2/proc porque todo mundo do time sabe o que é. Um agente não sabe. Ferramenta MCP boa é ferramenta com nome e descrição que explicam quando usá-la, não só o que ela faz.

Granularidade pensada para decisão, não para reuso. APIs REST costumam ser genéricas de propósito. Ferramentas para agente funcionam melhor quando são específicas: buscar_pedido_por_cliente rende muito mais que query com um DSL livre. Menos poder, muito menos chance de erro.

Erros que ensinam. Um 400 Bad Request sem corpo é inútil para um agente. Uma mensagem dizendo qual campo faltou, e qual formato era esperado, faz o agente se corrigir sozinho na tentativa seguinte.

A parte de segurança que não dá para deixar para depois

Expor um servidor MCP é expor superfície de execução. As agências de segurança já publicaram orientação sobre isso em 2026, e os pontos práticos são diretos:

• Autenticação e autorização são do servidor, não do agente. O agente é um cliente não confiável. Se a ferramenta permite ler dados de qualquer cliente, ela vai ler dados de qualquer cliente.
• Operações destrutivas precisam de confirmação explícita ou simplesmente não devem estar expostas. Deletar, transferir, emitir, cancelar — se está na lista de ferramentas, alguém vai chamar.
• Todo texto que volta de uma ferramenta é entrada não confiável. Conteúdo vindo de um ticket, de um e-mail ou de uma página pode conter instruções destinadas ao modelo. Tratar retorno de ferramenta como dado, e não como comando, é o mesmo princípio que já usamos contra injeção de SQL.
• Log de chamadas de ferramenta é log de auditoria. Quem chamou, com quais argumentos, em nome de quem. Sem isso não existe investigação de incidente.

Por onde começar sem virar o projeto do trimestre

Não é preciso "estratégia de MCP". O caminho barato é escolher uma leitura útil e específica do seu sistema — consultar status de pedido, buscar histórico de um cliente, listar itens abaixo do estoque mínimo — e expor só isso, somente leitura, com autenticação de verdade.

Esse recorte custa pouco, não cria risco novo relevante e responde a pergunta que realmente importa: o que muda no dia a dia da operação quando os dados do sistema ficam a uma pergunta de distância? A resposta a essa pergunta é o que deve guiar o que vem depois — não a lista de features do protocolo.