Protocolo MCP: como ligar a inteligência artificial aos sistemas da sua empresa

Conferido em 19/10/2026 contra a especificação 2026-07-28 do MCP, a documentação oficial do protocolo, a do n8n, o OWASP e o texto da LGPD no Planalto. Para entender o que é o MCP e de onde ele veio, leia antes MCP: o padrão que liga a inteligência artificial aos sistemas da sua empresa. Este texto parte daí e trata da implantação.

Por onde uma empresa começa a integrar a inteligência artificial aos sistemas com MCP?

Uma empresa começa a integrar a inteligência artificial aos sistemas com MCP listando as perguntas que a equipe faz todo dia e hoje responde abrindo telas, como o status de um pedido ou o saldo de um cliente. Cada pergunta indica um sistema, um dado e uma permissão. A escolha de conector vem depois.

O MCP, sigla de Model Context Protocol, é o padrão aberto que a Anthropic lançou em 25 de novembro de 2024 para que assistentes de IA conversem com programas externos sempre do mesmo jeito. Ele resolve o encaixe, não a pergunta anterior: o que o assistente precisa enxergar.

Começar pelos sistemas leva ao erro mais comum, que é ligar o sistema de gestão inteiro "para ver o que dá". Começar pelas perguntas produz uma lista curta e verificável. "Quais pedidos de ontem ainda não foram faturados?" pede leitura de pedidos e notas. "Remarque a visita do cliente X para quinta" pede escrita na agenda, que é outra conversa, com outro nível de cuidado.

Um bom primeiro escopo cabe numa folha: cinco ou seis perguntas, quem as faz, de que sistema sai cada resposta e se alguma delas altera dados. Se a lista não sai, o problema ainda é de processo, e nenhum conector vai resolvê-lo.

Quais sistemas da empresa podem ser ligados a um assistente de IA pelo MCP?

Qualquer sistema da empresa que ofereça uma porta de acesso pode ser ligado a um assistente de IA pelo MCP: uma API, que é a interface pela qual um software conversa com outro, um banco de dados, uma pasta de arquivos ou uma planilha online. Sem nenhuma dessas portas, não há conexão direta.

Na prática, o conector MCP (chamado de servidor MCP) fica entre o assistente e o sistema. Ele recebe o pedido do assistente, traduz para a linguagem do sistema e devolve a resposta. A especificação define que esse servidor oferece ferramentas que o modelo pode chamar, como consultar um banco ou acionar uma API.

Os casos se dividem em três grupos. Sistemas em nuvem conhecidos, como CRMs, agendas e ferramentas de gestão de projetos, costumam ter API pública, e muitos já publicam o próprio servidor MCP. Sistemas instalados na empresa, como um ERP antigo, às vezes não têm API, mas guardam tudo num banco de dados que pode ser lido com um usuário restrito. E há o sistema fechado, sem API nem acesso ao banco, em que a integração depende do fornecedor abrir uma porta.

O banco de dados merece um aviso. Ligar o assistente direto nas tabelas é rápido, mas expõe a estrutura inteira e deixa o modelo montar consultas livres. Um servidor com ferramentas específicas, como "buscar pedido por número", entrega menos e erra menos.

Quanto trabalho dá uma integração com MCP?

Uma integração com MCP dá o trabalho de quatro frentes, e só uma delas é instalar o conector: as outras são definir permissões, testar com perguntas reais e manter o conector funcionando quando o sistema ou o protocolo mudam. Projetos que só orçam a instalação costumam parar na segunda semana.

A manutenção é a frente mais subestimada, e o próprio protocolo mostra por quê. A especificação de 28 de julho de 2026 mudou a forma como cliente e servidor se conectam, e os mantenedores reconheceram que há trabalho de migração para quem mantém servidores. A mesma versão criou uma janela mínima de doze meses entre um recurso ser marcado como obsoleto e ser removido. Dá tempo, mas exige que alguém acompanhe.

O sistema do outro lado também muda. Uma atualização do ERP que renomeia um campo quebra a ferramenta que dependia dele, e o assistente passa a responder "não encontrei" sem que ninguém perceba. Cada conector precisa de um responsável com nome.

Daqui para baixo o texto entra na parte técnica: que tipo de conector escolher, como limitar permissões, como autenticar, onde rodar, como testar e como vigiar.

É melhor usar um servidor MCP pronto ou construir um próprio?

É melhor usar um servidor MCP pronto quando ele é publicado pelo próprio fornecedor do sistema e expõe as ferramentas de que a empresa precisa; construir um próprio compensa quando o sistema é interno, quando as ferramentas prontas liberam mais do que o necessário ou quando ninguém confiável mantém um conector para aquele sistema.

Há quatro origens possíveis, e a tabela logo abaixo do texto compara as quatro. O servidor do fornecedor é a opção de menor esforço e de maior confiança, porque quem conhece o sistema é quem mantém o conector. O servidor da comunidade é o que mais aparece em busca e o que pede mais cuidado: o MCP Registry, catálogo público lançado em prévia em setembro de 2025, avisa que as informações de cada servidor são declaradas por quem o publica.

Construir o próprio servidor ficou mais simples com os kits oficiais. A página de SDKs do MCP lista seis linguagens no nível de suporte mais alto: TypeScript, Python, C#, Go, Rust e Ruby. O ganho é controle: o servidor expõe só as ferramentas da lista de perguntas.

A quarta origem é transformar um fluxo de automação em ferramenta. O n8n, plataforma de automação de fluxos de trabalho, tem um nó que faz dele um servidor MCP, e a documentação do n8n explica que esse nó expõe ferramentas e fluxos do n8n para clientes MCP. A VT Sávio trabalha com n8n, e é esse o caminho que costuma usar quando o processo já está automatizado: o fluxo que funciona vira uma ferramenta que o assistente chama, com a lógica e as validações que já existiam.

Como definir o que o assistente de IA pode ver e fazer em cada sistema?

O que o assistente de IA pode ver e fazer em cada sistema se define em três camadas: quais ferramentas o servidor expõe, que permissões a credencial do servidor tem no sistema e quais ações exigem aprovação de uma pessoa. As três precisam começar no mínimo, e nenhuma substitui as outras.

O OWASP, na lista de riscos de aplicações com modelos de linguagem, chama o problema de agência excessiva e aponta as mesmas três causas: ferramentas demais, permissões demais e autonomia demais. As recomendações seguem a mesma ordem. Ferramentas estreitas no lugar de genéricas, como "consultar pedido" em vez de "executar consulta no banco". Acesso de leitura ao banco quando a tarefa é ler. E aprovação humana para ações de alto impacto.

Um detalhe técnico costuma enganar quem implanta. A especificação permite que o servidor marque cada ferramenta com dicas, como "esta ferramenta só lê" ou "esta ferramenta pode apagar". O esquema oficial do MCP afirma que essas marcações são apenas dicas, sem garantia de descrever o comportamento real, e que o cliente nunca deve decidir com base nelas quando o servidor não é confiável. Uma ferramenta marcada como somente leitura, mas ligada a um usuário de banco com permissão de escrita, continua podendo escrever.

Por isso a permissão que vale é a do sistema, não a do conector. O usuário que o servidor MCP usa para entrar no banco ou na API deve ter só os direitos da lista de perguntas. Se o servidor for enganado, o estrago fica limitado ao que aquela credencial alcança.

Como o assistente se autentica nos sistemas sem expor senhas?

O assistente se autentica nos sistemas sem expor senhas porque quem guarda a credencial é o servidor MCP, não o modelo: num servidor local, ela vem das variáveis de ambiente da máquina; num servidor na rede, a especificação recomenda OAuth 2.1, o padrão de autorização que emite chaves de acesso temporárias e com escopo limitado.

A especificação de autorização do MCP diz que a autorização é opcional, que implementações sobre HTTP devem seguir o fluxo OAuth e que servidores locais devem buscar as credenciais no ambiente. Ela também traz uma regra que importa a quem monta conectores para sistemas de terceiros: o servidor só pode aceitar tokens, isto é, chaves de acesso, emitidos para ele mesmo, e não pode repassar adiante uma chave recebida do cliente.

Essa prática proibida tem nome nas boas práticas de segurança do MCP: repasse de token. O documento explica que ela permite contornar controles do sistema de destino e apaga a trilha de auditoria, porque o registro mostra a chamada como se viesse de outra origem.

O mesmo documento recomenda começar com um conjunto mínimo de escopos, só de consulta, e pedir escopos maiores apenas quando uma operação privilegiada for tentada. Escopo coringa, do tipo acesso total, aparece na lista de erros comuns.

No n8n, a escolha é explícita: o nó de servidor MCP aceita autenticação por token, por cabeçalho ou nenhuma. Deixar sem autenticação um endereço que dispara fluxos ligados aos sistemas da empresa equivale a publicar esses fluxos para quem descobrir a URL.

O servidor MCP deve rodar no computador do funcionário ou num servidor da empresa?

O servidor MCP deve rodar no computador do funcionário quando acessa só arquivos e ferramentas daquela pessoa, e num servidor da empresa quando acessa sistemas compartilhados, como o ERP ou o CRM, porque assim a credencial fica num lugar só, sob controle de quem administra a infraestrutura.

A especificação define dois transportes padrão: o stdio, em que o aplicativo de IA inicia o servidor como um programa na própria máquina, e o HTTP, em que o servidor fica na rede e recebe os pedidos por um endereço. Cada um tem um risco diferente.

O servidor local roda com os mesmos privilégios do aplicativo de IA. As boas práticas de segurança descrevem o ataque: um comando de instalação malicioso escondido na configuração, ou um servidor baixado de fonte duvidosa, pode ler arquivos e chaves da máquina. O documento pede que o aplicativo mostre o comando completo antes de executá-lo e recomenda rodar servidores em ambiente isolado, como um contêiner. Para quem administra, a regra prática é proibir a instalação de servidores locais fora de uma lista aprovada.

O servidor remoto concentra o risco num ponto que pode ser vigiado, mas precisa de autenticação, de HTTPS e de atenção à infraestrutura. O n8n, por exemplo, não oferece stdio, exige que o proxy reverso não segure as respostas em buffer e, em instalações com várias réplicas, pede que todas as chamadas ao endereço MCP sigam para uma réplica só.

Como testar a integração antes de liberar para a equipe?

A integração deve ser testada em duas rodadas antes de chegar à equipe: primeiro o servidor sozinho, chamando cada ferramenta com dados conhecidos e conferindo a resposta; depois o assistente completo, com as perguntas reais da lista inicial e com tentativas deliberadas de fazê-lo sair do escopo.

Para a primeira rodada existe ferramenta oficial. O MCP Inspector é o programa de referência para testar e depurar servidores MCP, com versão no navegador, na linha de comando e no terminal. Ele lista as ferramentas que o servidor expõe, que é o primeiro teste: se aparece ferramenta que não está na lista de perguntas, o escopo já vazou. A documentação faz um alerta útil: numa máquina Linux sem chaveiro do sistema, ele grava tokens e segredos num arquivo sem criptografia, a menos que se configure uma chave.

A segunda rodada é a que mostra o comportamento real. Faça as perguntas da lista e compare cada resposta com o que o sistema mostra na tela. Depois, teste o ataque mais provável, a injeção de instrução indireta: um e-mail, documento ou cadastro com um texto que manda o assistente ignorar as regras e enviar dados para fora. O OWASP registra esse cenário com um assistente de e-mail induzido a encaminhar mensagens sensíveis. Se o assistente obedece, a correção é reduzir o que a ferramenta permite, não escrever um aviso mais enfático nas instruções do modelo.

Como acompanhar a integração depois que ela entra em uso?

A integração é acompanhada pelo registro de cada chamada de ferramenta, com quem pediu, o que foi pedido e o que voltou, revisado com uma frequência definida. A especificação do MCP recomenda que o aplicativo registre o uso das ferramentas para auditoria, e a LGPD cobra esse registro quando há dado pessoal envolvido.

A seção de segurança da especificação de ferramentas divide as responsabilidades. O servidor deve validar todas as entradas, controlar o acesso, limitar a frequência de chamadas e higienizar as saídas. O cliente deve pedir confirmação em operações sensíveis, mostrar ao usuário o que será enviado antes de chamar a ferramenta, aplicar tempo limite e registrar o uso.

A parte legal não muda por ser IA. A Lei nº 13.709/2018, a LGPD, determina no art. 37 que controlador e operador mantenham registro das operações de tratamento de dados pessoais, no art. 46 que adotem medidas de segurança contra acesso não autorizado, e no art. 6º, inciso III, que o tratamento se limite ao mínimo necessário. Um assistente que consulta o cadastro de clientes trata dado pessoal, e o registro das chamadas é o que permite responder depois quem viu o quê.

O registro só vale se alguém lê. A revisão periódica procura chamadas fora do padrão, ferramentas que nunca são usadas e podem ser desligadas, e pedidos da equipe que a lista original não previa. Esses últimos são o sinal para ampliar o escopo, pelo mesmo caminho do início.

Quando a integração com MCP não é o caminho certo?

A integração com MCP não é o caminho certo quando ninguém na empresa pode ser dono do conector, quando o processo segue sempre o mesmo roteiro ou quando o dado de origem está desorganizado: nesses casos o assistente ligado ao sistema amplia o problema em vez de resolvê-lo.

O primeiro caso é o mais ignorado. Um conector sem responsável quebra na próxima atualização do sistema ou do protocolo, e o assistente continua respondendo com confiança a partir de um dado parcial. Se não há quem cuide, é melhor esperar ou prever a manutenção já no orçamento da implantação.

O segundo caso tem alternativa mais barata. Quando a tarefa é sempre "chegou o pedido, registra e avisa o cliente", uma automação de fluxo sem IA faz o mesmo com resultado previsível e fácil de auditar. O MCP rende quando a pergunta varia e cruza sistemas, e uma regra fixa não dá conta.

O terceiro caso pede outra ordem de trabalho. Assistente consultando cadastro com cliente duplicado devolve a duplicidade mais rápido. Arrumar o dado vem antes.

O que a VT Sávio mais encontra nesses projetos é o escopo crescendo antes do primeiro uso real: alguém sugere liberar também o financeiro, depois o e-mail, e o conector fica amplo antes de responder bem a uma única pergunta. O que funciona é o oposto: duas ou três perguntas, só leitura, algumas semanas observando o registro de chamadas, e só então a próxima. Quando a empresa ainda não sabe quais perguntas fazer, o primeiro passo não é o MCP, é mapear o processo.