MCP: o padrão que liga a inteligência artificial aos sistemas da sua empresa

Conferido em 12/10/2026 contra a especificação 2026-07-28 do protocolo, o blog oficial dos mantenedores e os anúncios da Anthropic. O MCP muda rápido: datas e versões citadas aqui valem para esta data.

O que é MCP, explicado sem termos técnicos?

O MCP, sigla de Model Context Protocol, é uma espécie de tomada padrão para inteligência artificial: em vez de cada assistente precisar de um cabo diferente para cada programa, todos usam o mesmo encaixe. A própria documentação oficial do MCP compara o protocolo a uma porta USB-C, que conecta aparelhos de marcas diferentes.

A comparação ajuda a entender o problema que ele resolve. Um assistente de IA, como o ChatGPT ou o Claude, sabe o que aprendeu no treinamento e o que você escreve na conversa. Ele não sabe quantas unidades de um produto restam no estoque, qual cliente está com boleto vencido ou que horários sobraram na agenda de amanhã. Para responder isso, alguém precisa ir ao sistema, copiar a informação e colar no chat.

Com o MCP, o assistente faz essa consulta sozinho. De um lado fica o programa que tem os dados, que oferece um conector padronizado. Do outro fica o assistente, que sabe usar qualquer conector desse tipo. É isso que a expressão "IA conectada ao mundo real" quer dizer na prática: o modelo deixa de trabalhar só com o que está na tela e passa a consultar, e às vezes alterar, o que existe nos sistemas da empresa.

Por que um assistente de IA precisa de um protocolo para acessar dados da empresa?

Um assistente de IA precisa de um protocolo para acessar dados da empresa porque, sem um padrão, cada ligação entre um assistente e um sistema é um projeto separado, com código próprio e manutenção própria. Com cinco assistentes e dez sistemas, seriam cinquenta integrações; com um padrão comum, cada lado se adapta uma vez.

Esse foi o argumento do lançamento. Ao apresentar o protocolo, em 25 de novembro de 2024, a Anthropic argumentou que cada nova fonte de dados exigia uma implementação própria, e que isso tornava difícil escalar sistemas de fato conectados. A proposta era trocar esse emaranhado de ligações avulsas por um protocolo único.

A ideia não é nova em tecnologia. A especificação do MCP diz que se inspirou no Language Server Protocol, o padrão que permitiu a qualquer editor de código entender qualquer linguagem de programação sem que cada par editor-linguagem fosse programado à parte. O MCP aplica o mesmo raciocínio aos aplicativos de IA.

Para quem decide, a consequência é de custo e de dependência. Uma integração sob medida amarra a empresa a um assistente específico: trocar de fornecedor de IA significa refazer a ligação. Com um conector no padrão, outro assistente compatível pode usar o mesmo conector. Isso reduz a dependência de um fornecedor, mas não a elimina, porque cada assistente tem as suas limitações e as suas regras de uso.

Quem criou o MCP e quem usa o protocolo hoje?

O MCP foi criado pela Anthropic, empresa que desenvolve o assistente Claude, e lançado como padrão aberto em 25 de novembro de 2024. Em dezembro de 2025 a Anthropic doou o protocolo à Agentic AI Foundation, ligada à Linux Foundation, e hoje ele é suportado por ChatGPT, Gemini, Microsoft Copilot e outros.

A doação foi anunciada em 9 de dezembro de 2025. Segundo o comunicado da Anthropic, a fundação foi criada por Anthropic, Block e OpenAI, com apoio de Google, Microsoft, AWS, Cloudflare e Bloomberg. O mesmo texto afirma que o modelo de governança do projeto não muda: os mantenedores continuam decidindo de forma aberta, com participação da comunidade.

Os números de adoção mais citados vêm desse comunicado: mais de 10 mil servidores MCP públicos ativos e mais de 97 milhões de downloads mensais dos kits de desenvolvimento em Python e TypeScript (Anthropic, 12/2025). Na lista de produtos que usam o protocolo aparecem ChatGPT, Cursor, Gemini, Microsoft Copilot e Visual Studio Code, e entre as nuvens com suporte estão AWS, Cloudflare, Google Cloud e Microsoft Azure.

Em setembro de 2025 os mantenedores lançaram o MCP Registry, um catálogo público de servidores. O próprio anúncio avisava que o lançamento era uma prévia, sem garantia de durabilidade dos dados, e que as informações de cada servidor são declaradas por quem o publica.

O que o MCP muda na prática para uma empresa pequena ou média?

Para uma empresa pequena ou média, o MCP muda quem precisa fazer a ponte entre o assistente de IA e os sistemas: em vez de alguém copiar dados do sistema para o chat e devolver a resposta à mão, o assistente consulta e age direto no sistema, dentro das permissões que a empresa definiu.

Alguns exemplos de uso que a documentação oficial cita: um assistente que acessa a agenda do Google e o Notion da pessoa, e um chatbot corporativo ligado a vários bancos de dados, que deixa o funcionário analisar números conversando. Traduzido para a rotina de uma empresa brasileira, é o atendente que pergunta ao assistente o status de um pedido sem abrir o sistema de gestão, ou o gestor que pede o faturamento do mês por região e recebe o número tirado do banco, não estimado.

Há também o caminho inverso, que interessa a quem já tem processos automatizados. O n8n, ferramenta de automação de fluxos de trabalho, tem um nó que transforma o n8n em servidor MCP e disponibiliza ferramentas e fluxos do n8n para clientes MCP, e outro que faz o contrário: deixa os agentes de IA do n8n usarem ferramentas externas. A VT Sávio trabalha com n8n, e essa dupla função é o motivo prático de o MCP aparecer em projetos de automação: o fluxo que já funciona vira uma ferramenta que o assistente pode chamar, sem reescrever a integração.

Daqui para baixo o texto entra na parte técnica: como o protocolo funciona por dentro, o que mudou na versão de 2026 e onde estão os riscos.

Como o MCP funciona por dentro?

O MCP funciona com três papéis: o host, que é o aplicativo de IA que a pessoa usa; o cliente, que é o conector dentro desse aplicativo; e o servidor, que é o programa que oferece dados e ações. Eles conversam por mensagens no formato JSON-RPC 2.0, um padrão simples de pedido e resposta.

O servidor pode oferecer três tipos de recurso, segundo a especificação. As ferramentas (tools) são funções que o modelo pode executar, como "consultar pedido" ou "criar lembrete". Os recursos (resources) são dados e contexto para o modelo ou o usuário lerem, como um arquivo ou o registro de um cliente. E os prompts são modelos de mensagem prontos, que o usuário escolhe para disparar uma tarefa recorrente. No sentido contrário, o cliente pode atender a pedidos de elicitação: o servidor pergunta algo ao usuário no meio da tarefa, como a confirmação de um dado que faltou.

A ligação física entre cliente e servidor tem dois formatos comuns. No primeiro, o servidor roda na mesma máquina do aplicativo e conversa pela entrada e saída padrão do sistema operacional (o transporte stdio). No segundo, o servidor fica na rede e a conversa acontece por HTTP. Nem toda ferramenta aceita os dois: o servidor MCP do n8n, por exemplo, aceita HTTP e não aceita stdio, e oferece autenticação por token, por cabeçalho ou nenhuma, o que já é uma decisão de segurança a tomar na configuração.

Além do núcleo, a especificação define extensões opcionais, que só funcionam quando cliente e servidor as suportam. Duas se destacam: Tasks, para operações demoradas que o cliente acompanha até terminar, e MCP Apps, para exibir elementos interativos, como gráficos e formulários, dentro da própria conversa.

O que mudou na especificação do MCP em 2026?

A especificação do MCP publicada em 28 de julho de 2026 tornou o protocolo stateless, isto é, sem sessão: cada pedido passa a levar consigo a versão, a identidade e as capacidades, em vez de depender de uma conversa inicial que fixava o cliente num servidor. É a maior revisão desde o lançamento, segundo os mantenedores.

O anúncio da versão 2026-07-28 detalha as mudanças. A troca inicial de mensagens (initialize) e o cabeçalho Mcp-Session-Id, que prendia um cliente a uma instância do servidor, foram aposentados. Para descobrir o que um servidor oferece existe agora um pedido opcional, server/discover. O efeito prático é que um servidor MCP passa a escalar como qualquer serviço web comum, atrás de um balanceador de carga, sem precisar lembrar de quem é cada conversa.

Três recursos foram marcados como obsoletos, Roots, Sampling e Logging, mas continuam funcionando por pelo menos doze meses. A versão também criou uma política formal de obsolescência, com janela mínima de doze meses entre um recurso ser marcado e ser removido. O transporte antigo HTTP+SSE entrou na mesma regra, com um ano para migrar. Na autorização, a especificação passou a incluir a validação do emissor da resposta (RFC 9207) e trocou o registro dinâmico de clientes por documentos de metadados do cliente, mantendo o registro dinâmico por compatibilidade.

Para quem mantém um servidor, a mudança tem custo. Os próprios mantenedores reconhecem que há trabalho de migração, sobretudo para quem dependia do identificador de sessão. Quem precisa guardar estado entre pedidos, como um carrinho de compras, passa a emitir um identificador próprio e recebê-lo de volta como argumento, e a documentação de segurança exige que esse identificador nunca seja tratado como prova de identidade.

Quais são os riscos de segurança de ligar a IA aos sistemas da empresa?

O principal risco de segurança de ligar a IA aos sistemas da empresa é que uma ferramenta MCP executa ações reais: a especificação diz que ferramentas representam execução arbitrária de código e devem ser tratadas com cautela. Um assistente com permissão de escrita pode apagar, enviar ou alterar dados se for enganado.

A especificação estabelece que o aplicativo precisa obter consentimento explícito do usuário antes de chamar qualquer ferramenta, e que a descrição de uma ferramenta deve ser considerada não confiável, a menos que venha de um servidor confiável. O motivo é concreto: o modelo decide o que fazer lendo essas descrições, e um servidor mal-intencionado pode escrever nelas instruções que o usuário não vê.

O risco mais difícil de controlar tem nome: injeção de instrução indireta. O OWASP, na lista de riscos de aplicações com LLM de 2025, descreve o caso em que o modelo recebe conteúdo externo, como uma página ou um arquivo, com instruções que alteram o comportamento dele. Um e-mail de cliente pedindo ao assistente que ignore as regras e envie a lista de preços de custo é texto comum para quem lê, e pode ser uma ordem para um assistente com acesso ao e-mail e ao sistema de gestão. A mesma lista reconhece que não há método conhecido que impeça o ataque por completo, e recomenda limitar o modelo ao mínimo de privilégios e exigir aprovação humana para operações de alto risco.

A documentação de segurança do MCP acrescenta riscos de infraestrutura. Um servidor instalado na máquina roda com os mesmos privilégios do aplicativo de IA, então um servidor baixado de fonte duvidosa pode ler arquivos e chaves de acesso. Um servidor não pode aceitar credenciais emitidas para outro serviço e repassá-las adiante, prática que a especificação proíbe. E as permissões devem começar mínimas, com elevação só quando uma operação privilegiada for de fato necessária.

Há ainda a lei. Dado pessoal de cliente consultado por um assistente continua sob responsabilidade da empresa perante a LGPD (Lei nº 13.709/2018), seja qual for o caminho técnico. A regra que funciona é simples de enunciar: o assistente começa só com leitura, enxerga o agregado antes do cadastro, e toda ação que escreve, envia ou apaga passa por uma pessoa.

Quando o MCP não vale a pena?

O MCP não vale a pena quando a tarefa segue sempre o mesmo caminho: se o pedido chega, o sistema registra e o cliente recebe a confirmação, uma automação de fluxo comum faz isso de forma mais barata, mais previsível e mais fácil de auditar do que um assistente de IA decidindo cada passo.

O MCP brilha quando a pergunta varia e cruza sistemas: "quais clientes compraram o produto X no trimestre e estão com entrega atrasada?" não cabe num fluxo fixo. Fora desse cenário, há três situações em que ele atrapalha. A primeira é o sistema sem nenhuma forma de acesso programado: o servidor MCP precisa de uma porta de entrada, e sem ela o projeto vira outra coisa. A segunda é o dado desorganizado: um assistente que consulta um cadastro com clientes duplicados responde com a mesma confusão, só que mais rápido. A terceira é o volume baixo: se a consulta acontece duas vezes por semana, abrir o sistema continua sendo mais barato que configurar e vigiar um conector.

O erro que a VT Sávio mais encontra nesse tipo de projeto não é técnico: é liberar acesso amplo ao assistente antes de saber quais perguntas ele precisa responder. O resultado é um conector que vê tudo e que ninguém consegue auditar. O caminho que funciona é o inverso: listar as cinco ou seis perguntas reais da operação, expor só as ferramentas que respondem a elas, em modo de leitura, e ampliar depois de algumas semanas de uso observado. Se nem essas perguntas existem ainda, o MCP é cedo demais, e o primeiro passo é organizar o processo.

O que ainda não dá para afirmar sobre o MCP?

Ainda não dá para afirmar que o MCP é um padrão estável no sentido em que o HTTP ou o e-mail são: a especificação mudou de forma incompatível em 2026, e os números de adoção mais citados vêm da própria Anthropic, que criou o protocolo e tem interesse no seu sucesso.

O total de servidores públicos também não diz nada sobre qualidade. O anúncio do MCP Registry descreve um mecanismo de moderação para retirar servidores com código malicioso ou que se passam por serviços legítimos, o que confirma que esse tipo de servidor existe. Contar servidores é contar conectores publicados, não conectores seguros ou mantidos.

E a injeção de instrução indireta continua sem solução definitiva. Enquanto ela não tiver, qualquer promessa de assistente totalmente autônomo operando sistemas críticos merece desconfiança. O que dá para afirmar com segurança é mais modesto: o MCP reduz o custo de conectar a IA aos sistemas, e o trabalho de decidir o que ela pode fazer continua sendo da empresa.