npx -y @algum-pacote/servidor-mcp parece um comando qualquer — mas instala e executa código de terceiro com os mesmos privilégios do seu usuário, conectado a um modelo que pode decidir sozinho o que chamar. Em 2024 isso era uma escolha de nicho. Hoje o MCP virou infraestrutura de mercado, e a própria equipe que mantém o protocolo já documenta, com exemplo de código, um comando de instalação "de um clique" que dispara npx e, em sequência, extrai o conteúdo de ~/.ssh/id_rsa via curl.
De padrão da Anthropic a projeto da Linux Foundation
A Anthropic abriu o MCP em 25 de novembro de 2024 como "um novo padrão para conectar assistentes de IA aos sistemas onde os dados vivem". A analogia oficial, publicada no site do protocolo, é direta: "pense no MCP como uma porta USB-C para aplicações de IA" — um único padrão de conexão em vez de uma integração sob medida para cada combinação de modelo e ferramenta.
O que mudou desde então é a governança. O projeto hoje roda como "Model Context Protocol, a Series of LF Projects, LLC" — guarda-chuva da Linux Foundation —, com estrutura hierárquica de Lead Maintainers, Core Maintainers, Maintainers e Contributors, e a regra explícita, descrita na página de governança do MCP, de que "não há cadeiras reservadas para empresas específicas": a participação é por indivíduo. Os Lead Maintainers listados atualmente são David Soria Parra e Den Delimarsky.
A especificação também evoluiu: a versão vigente é identificada como 2026-07-28, seguindo o formato AAAA-MM-DD que marca a última data em que uma mudança incompatível com versões anteriores foi publicada. Não há handshake: cada requisição declara sua versão no campo _meta (io.modelcontextprotocol/protocolVersion), e o servidor aceita ou rejeita cada uma isoladamente. No transporte Streamable HTTP, o mesmo valor é espelhado no cabeçalho MCP-Protocol-Version, conforme a documentação de versionamento do MCP.
Por que isso importa: não é mais só a Anthropic usando
A adoção fora do ecossistema Anthropic é o que transformou o MCP de "recurso do Claude" em infraestrutura. A OpenAI passou a suportar o protocolo nativamente — Sam Altman confirmou em 26 de março de 2025 que "as pessoas amam o MCP e estamos animados para adicionar suporte em todos os nossos produtos". A adoção veio em etapas: começou pelo Agents SDK, a Responses API ganhou suporte a servidores MCP remotos em 21 de maio de 2025, e conectores customizados chegaram ao ChatGPT como parte do Developer Mode, em beta desde outubro de 2025 segundo a InfoQ.
O Google anunciou no I/O que o SDK e a API do Gemini passariam a suportar MCP nativamente, e o Google Cloud lançou em preview público servidores MCP remotos totalmente gerenciados, começando por Google Maps, BigQuery, Compute Engine e GKE. A própria documentação oficial do protocolo lista suporte também em VS Code, Cursor e MCPJam como exemplo do princípio "construa uma vez, integre em qualquer lugar".
Na prática: três dos maiores laboratórios de IA do mercado — Anthropic, OpenAI e Google — e as principais IDEs agênticas falam o mesmo protocolo. Um servidor MCP escrito uma vez integra com todos eles, sem reescrever nada por cliente.
O MCP Registry: descoberta oficial, ainda em preview
Adoção rápida cria outro problema: como saber qual servidor MCP é legítimo? A resposta oficial é o MCP Registry, um repositório central de metadados mantido com contribuição de Anthropic, GitHub, PulseMCP e Microsoft. Ele está marcado explicitamente, na sua própria documentação, como "atualmente em preview", com risco assumido de "mudanças incompatíveis ou reset de dados" antes do lançamento geral.
O Registry não hospeda código — ele aponta para pacotes publicados em npm, PyPI ou Docker Hub via um server.json padronizado, e autentica o namespace por GitHub, DNS ou desafio HTTP, para impedir que qualquer um publique um servidor se passando pelo dono de um domínio ou organização. É a peça que falta para o ecossistema amadurecer, mas enquanto estiver em preview, ele não é garantia — é um sinal a mais, não um selo de segurança.
Como instalar um servidor MCP local, na prática
A própria documentação oficial documenta o passo a passo mínimo, usando o servidor de filesystem como exemplo. Resumo direto da fonte:
- Editar o arquivo de configuração do cliente (no Claude Desktop:
claude_desktop_config.json, em~/Library/Application Support/Claude/no macOS ou%APPDATA%\Claude\no Windows). - Declarar o servidor:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/username/Desktop", "/Users/username/Downloads"]
}
}
}
- Reiniciar o cliente. O servidor aparece em "Manage connectors", e toda operação de arquivo passa a exigir aprovação explícita do usuário antes de executar — mas, como descreve a própria documentação sobre servidores locais, "o servidor roda com as permissões da sua conta de usuário, então pode executar qualquer operação de arquivo que você mesmo conseguiria fazer manualmente". A aprovação por ação limita o gatilho, não o alcance.
A estrutura mcpServers + command/args/env é o mesmo padrão em qualquer cliente compatível — Claude Desktop, VS Code, Cursor —, não só um recurso proprietário de um produto. É justamente essa simplicidade de instalação — um bloco JSON copiado de algum lugar da internet — que torna a próxima seção necessária.
Os riscos que a própria spec documenta
O guia oficial de segurança do protocolo documenta onze categorias de ataque no capítulo "Attacks and Mitigations", e um advisory de pesquisa independente cobre mais uma que não está lá. Entre elas, os padrões abaixo são os mais relevantes para quem avalia instalar um servidor de terceiro — todos documentados com exemplo técnico.
Tool Poisoning Attack (TPA). Instruções maliciosas escondidas na descrição de uma ferramenta MCP — invisíveis para quem olha a interface, mas totalmente visíveis para o modelo, que as lê como parte do contexto. O caso documentado pela Invariant Labs: uma ferramenta add(a, b) aparentemente inofensiva, com uma tag <IMPORTANT> escondida na docstring instruindo o modelo a ler ~/.ssh/id_rsa e enviar o conteúdo disfarçado num parâmetro chamado sidenote. O usuário vê "soma dois números"; o modelo recebe uma instrução para exfiltrar uma chave privada.
Confused Deputy Problem. Acontece em servidores MCP que funcionam como proxy para uma API de terceiro. A combinação de client ID estático, registro dinâmico de clients e cookie de consentimento pode permitir que um atacante roube o código de autorização sem que o usuário aprove nada de novo — o servidor age como "procurador confuso", usando sua própria autoridade em nome do atacante. O guia oficial de segurança torna obrigatório (MUST): consentimento por client individual, validação exata do redirect_uri e um parâmetro state criptograficamente seguro.
Token Passthrough. Antipadrão explicitamente proibido pela especificação: "servidores MCP NÃO DEVEM aceitar nenhum token que não tenha sido emitido explicitamente para o servidor MCP". Repassar para um sistema downstream um token que não foi emitido para aquele servidor quebra auditoria, rate limiting e o isolamento de confiança entre sistemas — o downstream não consegue distinguir quem realmente fez a chamada.
SSRF via descoberta OAuth. Um servidor MCP malicioso pode apontar URLs de metadata para endereços internos — como 169.254.169.254, o endpoint clássico de metadata de nuvem — durante o processo de descoberta OAuth, induzindo o cliente a vazar credenciais de infraestrutura para quem não deveria tê-las, segundo o mesmo guia de segurança.
Comprometimento de servidor MCP local. Servidores locais rodam com os mesmos privilégios do usuário que os instalou — sem sandbox por padrão. O guia oficial de segurança traz um cenário exemplificado pela própria spec: comandos maliciosos embutidos em configurações de instalação "de um clique", como exfiltração de ~/.ssh/id_rsa encadeada num curl disparado por npx.
Checklist antes de instalar um servidor MCP de terceiro
| Risco | Pergunta a fazer antes de instalar |
|---|---|
| Tool Poisoning | O código-fonte do servidor está disponível para revisão? A descrição de cada ferramenta bate com o que ela realmente faz? |
| Confused Deputy | Se o servidor faz proxy de OAuth, ele valida redirect_uri exato e usa state aleatório por sessão? |
| Token Passthrough | O servidor emite tokens próprios para downstream, ou repassa o token que recebeu do cliente sem validação? |
| SSRF via OAuth | As URLs de metadata/descoberta são fixas e auditáveis, ou vêm de configuração controlada pelo próprio servidor? |
| Compromisso local | O comando de instalação roda algo além do declarado (curl encadeado, script pós-install)? O servidor pede mais escopo de arquivo/sistema do que a tarefa exige? |
Nenhum item da lista substitui revisão de código real. Mas os cinco fazem a pergunta certa antes de rodar um npx -y que baixa e executa algo desconhecido com os privilégios da sua própria conta.
Regra prática: prefira servidores listados no MCP Registry oficial ou publicados por quem já mantém a ferramenta que o servidor expõe (o próprio fornecedor do CRM, do banco, da API). Servidor MCP anônimo, sem repositório público e sem publisher identificável, é motivo suficiente para não instalar — independente de quão útil a ferramenta pareça.
Para times que precisam de um servidor MCP com controle de acesso desenhado desde o início — permissão granular por usuário, isolamento entre leitura e escrita, log auditável —, o caminho mais seguro costuma ser construir um servidor MCP sob medida em vez de confiar em um pacote de terceiro para dados sensíveis da operação.
Perguntas Frequentes
O MCP é inseguro por design?
Não. O protocolo define a estrutura de comunicação e, na própria especificação, impõe requisitos obrigatórios de segurança (como a proibição de token passthrough). O risco não está no protocolo — está em servidores individuais implementados sem seguir essas exigências, especialmente os de origem desconhecida.
Servidores MCP oficiais (Anthropic, GitHub, Google) têm os mesmos riscos?
Servidores publicados por organizações identificáveis e com código aberto para auditoria reduzem o risco de tool poisoning e de instalação maliciosa, porque a descrição das ferramentas e o comportamento do código podem ser conferidos. Ainda assim, cabe ao cliente MCP e ao operador validar corretamente fluxo OAuth e escopo de permissões — nenhum publisher elimina a necessidade de revisão.
O MCP Registry resolve esse problema?
Ajuda, mas ainda está em preview e sujeito a mudanças. Ele centraliza metadados e autentica namespace por GitHub, DNS ou desafio HTTP, o que dificulta um atacante se passar por um publisher legítimo — mas não audita o comportamento do código do servidor. Continua sendo responsabilidade de quem instala revisar o que o servidor realmente faz.
Dá para rodar um servidor MCP de terceiro com segurança mesmo sem revisar o código?
Reduz o risco, não elimina: rodar em ambiente isolado (container, VM, usuário sem privilégio), restringir os diretórios/escopos expostos ao mínimo necessário e nunca conectar um servidor não revisado a credenciais de produção. Nenhuma dessas medidas substitui saber o que o código faz.
Conclusão
O MCP resolveu um problema real de integração e, por isso mesmo, virou padrão de mercado rápido — governança sob a Linux Foundation, suporte nativo de Anthropic, OpenAI e Google, registry oficial em construção. Mas infraestrutura que cresce rápido também vira alvo rápido, e os próprios mantenedores do protocolo já documentam, com exemplo de código, como um servidor mal-intencionado pode ler uma chave SSH ou sequestrar um fluxo de autorização. A ferramenta não é o risco. Instalar sem checar de onde ela vem, é.
Se a sua empresa está avaliando instalar servidores MCP de terceiro ou construir um próprio com controle de acesso desde o início, fale com a equipe MaxVision — arquitetura de integração segura faz parte do que entregamos.
