Durante dois anos, o problema de quem queria colocar IA para trabalhar dentro da empresa foi técnico: conectar o assistente ao ERP, ao CRM, à planilha de estoque e à caixa de e-mail dava trabalho, e cada conexão era um projeto. O Model Context Protocol, o MCP, resolveu boa parte disso. Hoje, ligar um assistente de IA a um sistema leva uma tarde.
E é exatamente aí que mora o novo problema. Quando conectar fica fácil, o que trava deixa de ser o “como” e passa a ser o “o quê”: o que essa IA pode ler, o que pode alterar e quem responde quando ela erra.
O problema que o MCP resolve: de M × N para M + N
Antes de um padrão, cada combinação de assistente e sistema exigia uma integração própria. Três assistentes de IA e cinco sistemas internos significavam até quinze conectores diferentes, cada um com seu formato, sua autenticação e sua manutenção. Troque de fornecedor de modelo e boa parte desse trabalho vai para o lixo.
O MCP, lançado pela Anthropic em novembro de 2024 como protocolo aberto, faz para a IA o que a tomada padrão fez para os eletrodomésticos: define um único formato de encaixe. Cada sistema ganha um “servidor MCP” uma vez, e qualquer assistente compatível conversa com ele. Três assistentes e cinco sistemas passam a exigir cinco servidores, não quinze conectores.
O padrão pegou. Em dezembro de 2025, a Anthropic doou o MCP à Agentic AI Foundation, uma fundação sob a Linux Foundation criada junto com OpenAI e Block e apoiada por Google, Microsoft e AWS. Na época, o protocolo já tinha mais de 10 mil servidores públicos ativos e era suportado por ChatGPT, Gemini, Microsoft Copilot, VS Code e Cursor. Não é mais a aposta de um fornecedor; é infraestrutura comum do mercado.
Como funciona por dentro
A arquitetura tem três peças. O host é o aplicativo que a pessoa usa, como um assistente de chat ou um editor de código. Dentro dele, um cliente MCP mantém a conexão com cada servidor, o programa que fica na frente de um sistema (o banco de dados, o CRM, o drive de arquivos) e o expõe num formato padronizado, trocando mensagens em JSON-RPC.
O servidor oferece três tipos de coisa: ferramentas (ações que o modelo pode pedir para executar, como “criar pedido” ou “consultar cliente”), recursos (dados que podem ser lidos e colocados no contexto, como um documento ou um registro) e prompts (modelos de instrução prontos para tarefas recorrentes).
O ponto que mais importa para quem decide é este: o modelo nunca toca o sistema. Ele lê o nome, a descrição e os parâmetros de cada ferramenta disponível, decide qual chamar e com quais valores, e devolve esse pedido. Quem executa é o servidor, com as credenciais que ele tem. É o mesmo mecanismo de function calling, agora com um encaixe padrão. A consequência é direta: o agente pode fazer tudo o que a credencial do servidor permite. Se o servidor está ligado ao ERP com um usuário administrador, o assistente tem, na prática, poder de administrador.
O risco mora na descrição da ferramenta
Para escolher a ferramenta certa, o modelo lê a descrição dela como texto. E o modelo não separa bem texto que descreve de texto que manda. Em abril de 2025, a Invariant Labs mostrou um ataque que chamou de tool poisoning: um servidor de aparência inofensiva, com uma ferramenta de “somar dois números”, trazia na descrição uma instrução escondida para o agente ler arquivos de chave de acesso da máquina e enviá-los junto da chamada. O usuário via uma calculadora. O modelo via uma ordem.
Há variações. Um servidor pode mudar a descrição da ferramenta depois de aprovado, e a descrição de um servidor pode alterar como o agente usa as ferramentas de outro. Todas têm a mesma raiz: o agente herda a confiança de cada servidor conectado, e o protocolo, sozinho, não verifica essa confiança. É o mesmo problema estrutural do prompt injection, com uma porta de entrada a mais.
Conectar ficou fácil; decidir o que conectar é o trabalho
Imagine uma distribuidora com quarenta funcionários. O gerente comercial descobre que existe um servidor MCP pronto, feito pela comunidade, para o sistema de gestão que a empresa usa. Em uma tarde, o assistente de IA da equipe passa a consultar pedidos, saldo de clientes e estoque. Funciona tão bem que ninguém pergunta com qual usuário o servidor foi configurado. Foi com o do próprio gerente, que pode conceder desconto, cancelar pedido e alterar cadastro.
Nada deu errado ainda. Mas a empresa acabou de dar a um sistema que segue instruções de texto, de qualquer origem, as mesmas permissões de um gerente, sem que ninguém tenha decidido isso. O problema não é o MCP. É a ordem das decisões.
João Paulo Batistella, executivo de inovação e ex-CEO da EISA, defende que, antes de entregar um processo a um agente de IA, a empresa precisa mapear o processo, documentar a norma e definir o que a IA pode fazer e, principalmente, o que ela não pode. O MCP não muda essa ordem. Ele a torna mais urgente, porque tirou do caminho a barreira técnica que, sem querer, obrigava as empresas a pensar antes de conectar.
Quatro perguntas antes de ligar um servidor MCP
1. Leitura ou escrita? Comece só com leitura. Um assistente que consulta pedidos já gera valor e, no pior caso, mostra um dado a quem não devia. Um que altera pedidos pode gerar prejuízo. Liberar escrita é uma segunda decisão, não um detalhe da primeira.
2. Com qual credencial? Crie um usuário próprio para o servidor, com o menor escopo que a tarefa exige. Nunca a conta de uma pessoa, muito menos a de um administrador. Se o assistente não precisa ver salário, o usuário dele não vê salário.
3. Quem escreveu o servidor e quem controla a versão? Servidor da comunidade é código de terceiro rodando com acesso ao seu sistema. Prefira o servidor oficial do fornecedor do sistema, fixe a versão instalada e leia as descrições das ferramentas, que são o que o modelo vai ler.
4. Que ação exige confirmação humana? Defina antes quais ferramentas só rodam depois de alguém aprovar: tudo que movimenta dinheiro, apaga dado ou fala em nome da empresa com o cliente. Na síntese de Batistella, a IA executa, o humano responde.
Um limite honesto: para uma única integração dentro de um produto fechado, chamar a API do sistema direto, via function calling, pode ser mais simples que montar um servidor MCP. O protocolo compensa quando a empresa tem vários assistentes, vários sistemas ou quer trocar de modelo sem refazer as integrações.
O MCP é uma boa notícia: tira das empresas um custo de integração que não gerava vantagem para ninguém. Mas ele não decide nada por você. A tomada padrão facilitou ligar qualquer aparelho na parede; ela não diz o que deve ficar ligado à noite.
Acompanhe a Eleva Tecnologia para mais análises sobre IA aplicada a negócios: siga @ElevaTechno no X, @elevatechnologies no Instagram ou a Eleva Technologies no LinkedIn — ou conheça o grupo em elevatec.net/sobre.
