Se você conversou com alguém de tecnologia sobre agentes de IA no último ano, provavelmente ouviu a sigla MCP. Ela aparece em anúncio de ferramenta, em proposta de fornecedor e em vaga de emprego. Muita gente fala como se fosse a peça que resolve a integração de uma vez.
Ele resolve uma parte importante, e vale entender qual. Neste texto a gente explica o que é o Model Context Protocol, por que ele pegou tão rápido e quais perguntas você ainda precisa fazer antes de deixar um agente mexer nos seus sistemas.
O que é o MCP, em uma frase
O MCP é um protocolo aberto que define como um agente de IA descobre e usa ferramentas e dados de outros sistemas. Ele foi publicado pela Anthropic no fim de 2024 e, ao longo de 2025, passou a ser aceito pelos principais fornecedores de modelos e de ferramentas de desenvolvimento.
A comparação mais usada é com a tomada USB. Antes dela, cada aparelho tinha seu cabo. Depois, um encaixe só servia para quase tudo. Com agentes acontecia a mesma coisa: para ligar um modelo ao CRM, ao ERP ou à planilha, alguém escrevia uma integração específica para aquele modelo e aquele sistema. Trocou o modelo, refaz. Entrou um sistema novo, escreve de novo.
Com o MCP, o sistema é exposto uma vez, em um formato padrão, e qualquer agente compatível consegue usar.
Como funciona na prática
Existem três papéis. Vale conhecer os nomes porque eles aparecem em qualquer conversa técnica:
- Host: o aplicativo onde o agente roda. Pode ser um assistente de mesa, uma ferramenta de programação ou o agente que a sua empresa construiu.
- Cliente: a parte do host que conversa com cada servidor MCP, uma conexão por servidor.
- Servidor: o programa que fica na frente de um sistema (o CRM, o banco de dados, o drive) e diz ao agente o que ele pode fazer ali.
O servidor oferece basicamente três coisas. Ferramentas, que são ações (criar um pedido, consultar um cliente, enviar um e-mail). Recursos, que são dados para leitura (um documento, um registro, um arquivo). E prompts, que são modelos de instrução prontos para tarefas comuns.
Quando o agente começa a trabalhar, ele pergunta ao servidor o que está disponível. O servidor responde com a lista de ferramentas, cada uma com nome, descrição e os campos que espera receber. O modelo lê essa lista e decide, durante a tarefa, qual ferramenta chamar e com quais dados. O servidor executa e devolve o resultado.
O servidor pode rodar na mesma máquina do agente ou em um endereço na internet. No segundo caso, a especificação traz um caminho de autenticação baseado em OAuth, o mesmo padrão usado quando você entra em um aplicativo com a sua conta do Google.
Por que virou padrão tão rápido
Protocolo bom não basta para virar padrão. O MCP pegou por uma combinação de fatores:
- Resolveu uma dor real e cara. Quem construía agentes gastava boa parte do tempo escrevendo e mantendo conectores. Isso não diferenciava produto nenhum.
- Saiu aberto e simples. A especificação é pública, há bibliotecas em várias linguagens e um servidor básico sai em poucas horas.
- Os concorrentes adotaram. Quando fornecedores que disputam o mesmo mercado aceitam o mesmo encaixe, as empresas de software passam a ter um motivo para publicar seus próprios servidores.
- Efeito rede. Cada novo servidor publicado deixa todos os agentes compatíveis um pouco mais úteis, o que atrai mais gente para publicar.
Para quem está do lado da operação, a consequência prática é boa. Trocar de modelo ficou menos traumático, porque as conexões continuam valendo. E muitos sistemas que você já usa provavelmente têm, ou vão ter, um servidor MCP oficial.
O MCP padroniza o encaixe. Quem pode usar o encaixe, para quê e com que registro continua sendo decisão sua.
O que o MCP não resolve: identidade
O protocolo define como o agente se conecta ao servidor. Ele não responde, sozinho, em nome de quem o agente está agindo.
Pense em um agente que atende pedidos de vários vendedores. Quando ele consulta o CRM, ele enxerga a carteira de quem? A do vendedor que pediu, ou a de todo mundo, porque foi conectado com uma conta de serviço que vê tudo? Esse é o atalho mais comum: uma credencial com acesso amplo, compartilhada por todas as tarefas. Funciona na demonstração e vira problema na primeira auditoria.
Antes de conectar, pergunte:
- O agente usa a identidade de quem fez o pedido ou uma conta própria?
- Se usa conta própria, ela tem só o acesso de que precisa, ou herdou o acesso de um administrador?
- Dá para saber, olhando o sistema de destino, que a ação foi feita por um agente e a pedido de quem?
O que o MCP não resolve: autorização
Estar autenticado é diferente de estar autorizado a fazer qualquer coisa. Um servidor MCP pode expor dez ferramentas, e o seu agente talvez só devesse usar duas. Pode expor a ferramenta de emitir reembolso sem nenhum limite de valor. O protocolo descreve as ferramentas, mas a regra de negócio (até quanto, em que situação, com aprovação de quem) precisa morar em algum lugar.
Há também um risco próprio desse modelo. O agente decide o que fazer a partir de texto: a descrição das ferramentas, o conteúdo dos documentos, a mensagem do cliente. Se alguém colocar uma instrução escondida em um e-mail ou em um campo do CRM, o agente pode tratar aquilo como ordem. Isso se chama injeção de instrução, e nenhum protocolo de conexão impede sozinho.
O que costuma funcionar:
- Liberar para cada agente só as ferramentas de que ele precisa, e nada além.
- Separar ferramentas de leitura das de escrita, e tratar as de escrita com mais cuidado.
- Colocar limites fora do modelo: valor máximo, quantidade por hora, horários permitidos.
- Exigir aprovação humana nas ações que mexem com dinheiro, com cliente ou que não têm volta.
- Usar só servidores de origem conhecida e revisar o que mudou quando eles forem atualizados.
O que o MCP não resolve: auditoria
Quando algo sai errado, alguém vai perguntar o que aconteceu. Se a resposta depende de ler a conversa do modelo e adivinhar, você não tem auditoria.
Um registro útil responde, para cada ação: qual agente agiu, a pedido de quem, com qual ferramenta, com quais dados, qual foi o resultado e se houve aprovação humana. O MCP transporta as chamadas, mas guardar esse histórico de forma organizada, consultável e protegida é trabalho de quem monta a operação.
Isso pesa mais quando há dado pessoal no caminho. A LGPD pede que você consiga explicar como os dados foram tratados, e um agente que chama ferramentas sem deixar rastro torna essa explicação impossível.
Como olhar para o MCP na sua empresa
Vale tratar o MCP como você trata qualquer padrão de integração: uma boa notícia que reduz custo e dependência, e não uma garantia de segurança. Na hora de avaliar um projeto ou um fornecedor, quatro perguntas separam o que está pronto do que é demonstração:
- Quais servidores MCP serão usados, quem mantém cada um e de onde vêm?
- Com qual identidade e com quais permissões o agente acessa cada sistema?
- Onde ficam as regras de limite e de aprovação humana?
- Onde fica o registro de cada ação, quem consegue consultar e por quanto tempo é guardado?
Se as respostas vierem claras, o MCP vai fazer o trabalho dele muito bem. Se vierem vagas, o problema não está no protocolo, está no que falta em volta dele.
O MCP tirou da frente o trabalho repetitivo de conectar. Sobrou o trabalho que sempre importou: decidir quem pode fazer o quê e conseguir provar o que foi feito.