O Model Context Protocol (MCP) é um padrão aberto que conecta aplicações de inteligência artificial a sistemas externos como arquivos, bancos de dados e ferramentas. A Anthropic criou o protocolo e, um ano depois de lançá-lo como padrão universal, doou o projeto à Agentic AI Foundation, fundo dirigido da Linux Foundation co-fundado com Block e OpenAI. Para quem usa ou constrói assistentes de IA, o tema deixou de ser assunto de especialista: os principais clientes do mercado já falam essa linguagem, e adotá-la virou uma decisão de arquitetura com riscos de segurança próprios.
Este guia explica o que o padrão resolve, o que muda com a governança em consórcio e como avaliar os riscos antes de plugar o primeiro servidor.
O que é o MCP
A documentação oficial define o protocolo como um padrão open source para conectar aplicações de IA a sistemas externos: fontes de dados como arquivos locais e bancos, ferramentas como buscadores e calculadoras, e fluxos de trabalho especializados. A analogia que o próprio projeto usa é que ele funciona como uma porta USB-C para aplicações de IA: assim como a USB-C padronizou a conexão física entre dispositivos, o protocolo padroniza a conversa entre um modelo e o que existe ao redor dele.
Antes desse tipo de padrão, cada integração era um projeto próprio: um conector para o banco, outro para o calendário, outro para o repositório de documentos. Com o MCP, escreve-se um servidor uma vez e qualquer cliente compatível consegue consumi-lo. É a mesma lógica que transformou HTTP e USB em commodities: a padronização move o esforço do fio para o produto.
De Anthropic para a Linux Foundation
No anúncio da doação, a Anthropic confirma que o MCP passa para a Agentic AI Foundation (AAIF), fundo da Linux Foundation co-fundado com Block e OpenAI, com apoio de Google, Microsoft, AWS, Cloudflare e Bloomberg. Na mesma fundação já convivem o agente goose, do Block, e o AGENTS.md, da OpenAI. O modelo de governança existente foi mantido: os mantenedores continuam priorizando contribuições da comunidade e decisões transparentes, e o padrão segue neutro em relação a fornecedores.
A escala explica a movimentação. Segundo o anúncio oficial, existem mais de 10.000 servidores MCP públicos ativos, cobrindo de ferramentas de desenvolvedor a implantações de grandes corporações, e o padrão foi adotado por ChatGPT, Cursor, Gemini, Microsoft Copilot e Visual Studio Code. O mesmo texto informa que os SDKs oficiais em todas as principais linguagens somam 97 milhões de downloads mensais nas versões de Python e TypeScript, e que a versão mais recente da especificação trouxe operações assíncronas, statelessness, identidade de servidor e extensões oficiais.
Para o usuário final, a neutralidade reduz o risco de aprisionamento: nenhuma empresa controla sozinha o destino do padrão. Para quem já se prepara para regras europeias de IA, é mais uma peça de infraestrutura aberta a dominar — leia também as 5 regras do AI Act que já valem para quem trabalha com IA.
Como o protocolo funciona
A arquitetura separa três papéis: o host, a aplicação de IA que o usuário opera; o client, o componente que mantém uma conexão dedicada com um servidor; e o server, o programa que expõe ferramentas, dados e prompts. O cliente descobre o que o servidor oferece, cuida da autorização quando necessária e repassa ao modelo as capacidades disponíveis. O modelo decide quando usar cada ferramenta; o servidor define o que, de fato, é permitido fazer — e é aí que mora a superfície de ataque.
Na prática, o ganho é eliminação de retrabalho: em vez de N integrações para N clientes, um servidor serve a todos os compatíveis. A tabela resume as trocas:
| Situação | Sem MCP | Com MCP |
|---|---|---|
| Conectar nova ferramenta | Conector sob medida por cliente | Um servidor reutilizado por clientes compatíveis |
| Trocar de assistente | Refazer integrações | Reaproveitar servidores existentes |
| Publicar API para agentes | Documentação e SDK por plataforma | Servidor único listado em registro público |
| Auditoria de acesso | Dispersa por integração | Consentimento e escopos concentrados no servidor |
Quem já monta ambientes locais de modelos, como no plano de 12 semanas para dominar LLMs sem pagar nada, pode expor scripts e arquivos como servidores e conversar com eles por qualquer cliente compatível.
Riscos reais de segurança
Padrão aberto não é sinônimo de risco zero. A documentação oficial de segurança do MCP detalha o problema de confused deputy: proxies MCP que se conectam a APIs de terceiros usando client ID estático criam a condição em que clientes maliciosos podem obter códigos de autorização sem o consentimento real do usuário, explorando registro dinâmico de clientes e cookies de consentimento que ficam no navegador após a primeira autorização.
O mesmo documento proíbe o token passthrough: servidor algum deve aceitar — muito menos repassar — tokens emitidos para outro recurso, prática que quebra limites de confiança, contorna controles como limites de taxa e atrapalha auditoria e investigação de incidentes. Há ainda o risco de SSRF, em que um servidor malicioso induz o cliente a buscar metadados de autorização em URLs controladas pelo atacante, potencialmente alcançando endpoints internos.
Traduzindo para decisão: o perigo não está no protocolo, e sim em quais servidores você conecta e com quais permissões. Um servidor de terceiros enxerga o que o modelo enxerga; escolher servidor é escolher fornecedor de confiança.
Checklist antes de ativar um servidor
- Prefira servidores do registro oficial do projeto ou de fontes cujo código você consegue auditar.
- Conceda escopo mínimo: comece por operações de leitura e eleve somente quando a tarefa exigir.
- Revise o consentimento por cliente em qualquer proxy que use client ID estático com APIs de terceiros.
- Monitore para onde os tokens vão: nada de repassar credenciais emitidas para outro serviço.
- Mantenha cliente e servidor atualizados, pois a especificação evolui e correções de segurança acompanham cada versão.