Toda ferramenta corporativa relevante — CRM, banco de dados, sistema de tickets, planilha, repositório de código — está decidindo, neste momento, se expõe um servidor Model Context Protocol (MCP). Não é mais pergunta de early adopter. Em abril de 2026 o ecossistema já passava de 9.400 servidores MCP públicos, com estimativa de mais 3 a 4 vezes esse número em servidores privados internos a empresas — passando de 10 mil servidores enterprise e mais de 97 milhões de downloads do SDK. Anthropic, OpenAI, Google, Microsoft e AWS já adotaram o protocolo. Isso deixou de ser experimento e virou infraestrutura.
MCP resolve um problema estrutural que ficou invisível enquanto só existiam poucos agentes em produção: cada combinação de agente e ferramenta exigia uma integração própria. Um agente de atendimento que precisa consultar CRM, abrir chamado e checar estoque tinha três integrações bespoke. Trocar de fornecedor de LLM significava reescrever as três. O crescimento era combinatório: N agentes vezes M ferramentas, sem reuso — o mesmo problema que torna orquestrar múltiplos agentes mais caro que consolidar em um só quando ninguém pensa em reuso de conexão.
O problema que existia antes do MCP
Antes do protocolo, "conectar um agente a uma ferramenta" significava escrever uma função, descrevê-la em linguagem natural pro modelo, tratar autenticação, versionar o contrato manualmente, e repetir esse processo pra cada par agente-ferramenta. Frameworks de agente tentaram abstrair a repetição com camadas próprias — o que resolvia a duplicação de código, mas não a duplicação de integração: o backend de CRM ainda precisava expor uma API específica pra cada framework que quisesse consumi-lo.
MCP separa dois papéis que estavam fundidos. De um lado, o servidor MCP — mantido por quem conhece o sistema — expõe três primitivas padronizadas: tools (funções que o agente pode chamar), resources (dados que o agente pode ler) e prompts (templates reutilizáveis). De outro, o cliente MCP — dentro do agente, de qualquer framework — descobre e consome essas primitivas via um protocolo comum, sem precisar saber nada sobre a implementação interna do sistema.
Antes do MCP, cada agente reaprendia a falar com cada ferramenta. Depois, a ferramenta aprende a falar MCP uma vez, e qualquer agente compatível já entende.
O que muda para quem decide arquitetura
A consequência prática é que o custo marginal de conectar um novo agente a um sistema existente cai — mas o custo de manter esse sistema exposto sobe. Expor um servidor MCP significa aceitar tráfego de clientes que você não controla individualmente, com um contrato de ferramenta que precisa de versionamento sério e superfície de auditoria nova.
Isso já mudou o comportamento de fornecedores. Trinta por cento dos fornecedores de aplicação enterprise vão lançar servidor MCP próprio — o que inclui camadas de CRM e dados que hoje só se conectavam via API REST proprietária ou webhook. Quando Data Cloud deixa de ser só um CDP e passa a ser o nervo central do Salesforce, expor essa camada via MCP significa que qualquer agente externo compatível — não só o nativo da plataforma — pode consultar o mesmo grafo de dados do cliente, com governança do lado do servidor, não do lado de cada integração custom.
Pra quem decide arquitetura hoje, a pergunta não é mais "vamos adotar MCP" — é "quais dos nossos sistemas internos valem a pena expor como servidor, e com que controle de acesso". Sistema com dado sensível e alto valor de reuso justifica o investimento em expor bem. Sistema de uso único, sem candidato a segundo consumidor, não justifica a manutenção extra.
MCP substitui function calling nativo?
Não substitui — resolve um problema diferente. Function calling nativo (o tool use da OpenAI, da Anthropic) já permite que um modelo chame uma função descrita em JSON Schema dentro de uma única aplicação. Isso continua sendo a camada certa quando você controla os dois lados: o agente e a ferramenta vivem no mesmo código, sem necessidade de descoberta dinâmica nem de reuso por terceiros.
MCP entra quando o servidor e o cliente são mantidos por times ou empresas diferentes, ou quando o mesmo servidor precisa atender múltiplos agentes com necessidades distintas ao longo do tempo — sem que o mantenedor do servidor precise saber, de antemão, quem vai consumir. É a diferença entre escrever uma função privada e publicar uma API versionada: as duas resolvem "meu código chama outro código", mas em escopos de responsabilidade diferentes.
Quando vale adotar agora
Não é decisão binária de "todo mundo precisa". Três critérios ajudam a decidir se este é o momento de investir em expor — ou consumir — MCP:
- Reuso real, não hipotético. Há hoje, ou em roadmap concreto de dois trimestres, mais de um agente ou framework que vai precisar acessar o mesmo sistema? Isso é a mesma lógica de validar se um agente é a resposta certa antes de multiplicar integrações — antes de expor um servidor, vale confirmar que o processo por trás dele já está maduro. Se a resposta é "só um agente, só um caso de uso", a integração direta ainda é mais simples e mais barata de manter.
- Governança do lado certo. Expor via MCP move o controle de acesso pra dentro do servidor — quem pode chamar qual tool, com qual escopo. Se hoje esse controle não existe nem na API atual, adicionar MCP por cima não resolve o problema de governança; só muda onde ele aparece.
- Capacidade de versionar sem quebrar cliente. Servidor MCP em produção precisa de contrato estável. Se o time responsável ainda muda schema de API sem aviso, publicar isso como servidor MCP multiplica o raio de quebra — de um cliente interno pra qualquer agente externo que descobriu a tool.
Passando nos três, o investimento compensa. Falhando em dois ou mais, vale primeiro arrumar a casa antes de publicar isso como superfície pra terceiros.
O padrão que se forma agora é o que vai durar
A velocidade de adoção — de zero a 10 mil servidores enterprise em pouco mais de um ano — sugere que MCP virou o vocabulário comum entre agente e ferramenta, do mesmo jeito que REST virou vocabulário comum entre frontend e backend. Quem decide expor um sistema como servidor MCP hoje está, na prática, decidindo o contrato que vai valer pelos próximos anos de integração de agente. Vale o mesmo cuidado que qualquer API pública levaria — porque, efetivamente, é isso que está sendo publicado.