Como avaliar um servidor MCP de terceiros antes de dar suas credenciais a ele?

Instalar um servidor MCP de terceiros é entregar a um processo que você não escreveu exatamente as mesmas chaves que você usa

Fala aí, beleza? Integração da comunidade é o que faz o agente sair do "chat esperto" e virar algo que mexe no seu banco, no seu repo e na sua conta de verdade

O problema é que ninguém audita esse código por você

Não existe fada da segurança passando por trás de cada pacote que aparece no seu feed, então a conta cai no seu colo

Aqui vai um checklist prático, em duas partes: o que olhar ANTES de conectar e o que dá pra limitar depois, tanto do lado do serviço quanto do lado do cliente…

Por que "parece oficial" não é critério de confiança em MCP

Começa pela parte que muita gente assume errado: a própria documentação da Anthropic diz que servidores MCP remotos não são de propriedade, operados nem endossados por ela

A orientação é só conectar servidores em que você confia, revisando as práticas de segurança e os termos de cada um antes

"Mas ele tá no diretório de conectores!"

Estar listado significa que a Anthropic revisou o servidor contra critérios de listagem

Não significa auditoria de segurança, e ela também não gerencia esses servidores

São coisas MUITO diferentes, e a distância entre uma e outra é justamente onde mora o risco

O caso postmark-mcp: passado limpo e uma linha a mais

Se liga nesse caso, porque ele derruba o argumento do "olhei o código quando instalei"

O pacote npm malicioso postmark-mcp se passava pela biblioteca oficial da Postmark: era uma réplica quase exata com uma linha a mais, que colocava em cópia oculta todos os e-mails enviados para um servidor do atacante

O backdoor apareceu só na versão 1.0.16, depois de uma sequência de versões publicadas sem código malicioso

O pacote foi baixado 1.643 vezes antes de ser removido do npm

Ou seja: passado limpo não é garantia de presente limpo, é só histórico

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

GhostSplice: a instrução que vem picotada

Tem também o vetor que não depende de você baixar coisa errada

O grupo ASSET Research divulgou o GhostSplice, um ataque em que um servidor MCP malicioso fragmenta a instrução entre canais, por exemplo parte na descrição da ferramenta e parte no resultado dela

Cada pedaço é inofensivo sozinho

Juntos, levam agentes de código a exfiltrar chaves SSH, segredos e código-fonte

Repara no detalhe cruel: a descrição da ferramenta entra no contexto do modelo antes de você chamar qualquer coisa

Quem já bateu o martelo sobre isso

Não é papo de fórum, não

O Artificial Intelligence Security Center da NSA publicou a Cybersecurity Information Sheet "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation", em 20 de maio de 2026

A orientação da CSI é direta: organizações não devem depender apenas da documentação do próprio MCP, precisam adotar salvaguardas adicionais, usar ferramentas bem mantidas de provedores confiáveis e aplicar procedimentos rigorosos de revisão às ferramentas MCP antes do deploy

O OWASP Gen AI Security Project também publicou a versão 1.0 do cheat sheet "A Practical Guide for Securely Using Third-Party MCP Servers", em 23 de outubro de 2025

Todo mundo aponta pro mesmo lugar: a revisão é responsabilidade de quem conecta 🙂

O que ter em mãos antes de avaliar o servidor

Antes de sair rodando comando, junta o material

Avaliar no escuro é como aceitar PR sem abrir o diff

• A URL ou o pacote exato, e quem publica: nome coloquial ("o MCP do fulano") não serve, você precisa do identificador exato
• A página do projeto no MCP Registry: é o registro oficial e comunitário de servidores MCP, com a instância de referência em registry.modelcontextprotocol.io
• O entendimento do namespace: o registry usa nomes em formato DNS reverso com autenticação de namespace, onde io.github.usuario é verificado por OAuth do GitHub e com.exemplo por registro TXT de DNS do domínio
• A lista de ferramentas expostas pelo servidor: é ela que define o alcance real, não o README
• A documentação do serviço que emite a credencial: você precisa saber quais escopos e limites existem do lado dele antes de gerar token nenhum
• Um projeto de teste separado: não o repositório principal, não a conta de produção

Esse último item é o mais ignorado e o mais barato de fazer

Como avaliar um servidor MCP de terceiros passo a passo

Esta parte é toda de avaliação, ainda sem instalar nada

1. Confirme a procedência e o namespace verificado no MCP Registry

Compare o nome em DNS reverso com quem você acha que é o dono daquilo

Erro comum deste passo: confiar em nome parecido com o do provedor oficial

Foi exatamente assim que o postmark-mcp funcionou, imitando a lib oficial quase caractere por caractere

2. Olhe o histórico de versões, sem presumir que passado limpo garante presente limpo

Um servidor com meses de commits normais continua podendo receber uma linha a mais amanhã

Erro comum deste passo: fixar a avaliação no dia da instalação e nunca mais revisar

A versão 1.0.16 do caso Postmark existe pra lembrar disso

3. Mapeie o que o servidor precisa acessar e compare com o escopo mínimo que o serviço permite emitir

A pergunta certa não é "esse servidor é bom?", é "o que essa credencial abre se ele for hostil?"

Esse raciocínio de escopo mínimo é o mesmo que vale na hora de dar acesso às suas contas pra qualquer agente

Erro comum deste passo: gerar token de admin porque "é mais rápido pra funcionar"

4. Liste as ferramentas de escrita expostas e pergunte se você precisa delas

Leitura vaza, escrita destrói: a diferença de estrago entre as duas é enorme

O servidor MCP oficial do GitHub é um bom exemplo de servidor que já resolve isso: ele tem modo somente leitura que desativa todas as ferramentas que não são de leitura, mesmo que elas tenham sido pedidas na configuração

O modo somente leitura é ativado pela variável de ambiente GITHUB_READ_ONLY no servidor local e pelo header X-MCP-Readonly no servidor remoto, e tem precedência sobre as outras configurações

E atenção ao default: sem configuração explícita, ele sobe com os toolsets padrão context, issues, pull_requests, repos e users

Erro comum deste passo: subir com a configuração padrão e achar que o padrão é o mínimo

5. Cheque se o servidor busca conteúdo externo

A documentação de segurança do Claude Code recomenda escrever seus próprios servidores MCP ou usar servidores de provedores em que você confia, e alerta que servidores que buscam conteúdo externo expõem a risco de prompt injection

Issue de terceiro, página web, comentário de PR: tudo isso é texto que alguém escreveu pra ser lido pelo seu agente

Erro comum deste passo: tratar conteúdo buscado pela ferramenta como dado, quando o modelo pode tratar como instrução

6. Verifique sinais de higiene de autorização contra a especificação atual

A revisão estável mais recente da especificação do Model Context Protocol é a 2026-07-28, que sucede a 2025-11-25

Nela, o token passthrough é explicitamente proibido, e servidores MCP precisam validar que os tokens foram emitidos especificamente para eles

O capítulo de security best practices também descreve o problema do confused deputy: servidores proxy que usam client ID estático para autenticação de terceiros, aceitam registro dinâmico de cliente e não exigem consentimento por cliente antes de encaminhar a autorização podem ser explorados

Erro comum deste passo: assumir que "tem OAuth" significa "tá seguro"

Como instalar o servidor MCP com o mínimo de acesso no Claude Code

Passou no checklist? Beleza, agora é contenção

A ideia aqui é: mesmo que o servidor vire vilão, o alcance dele é pequeno

1. Escolha o escopo de forma consciente

Segundo a documentação de MCP do Claude Code, cada comando claude mcp add escreve no escopo local por padrão, a menos que você passe –scope project ou –scope user

Erro comum deste passo: usar –scope user pra "não precisar configurar de novo" e liberar um servidor de terceiro em todo projeto da máquina

2. Adicione por HTTP com a sintaxe certa

claude mcp add --transport http nome-do-servidor https://exemplo.com/mcp

Se for pro time, o comando muda de escopo:

claude mcp add --scope project --transport http nome-do-servidor https://exemplo.com/mcp

Erro comum deste passo: rodar o comando na pasta errada e espalhar o servidor num projeto que não era o alvo

3. Entenda quando existe (e quando NÃO existe) o prompt de aprovação

Por segurança, o Claude Code pede aprovação em sessões interativas na primeira vez que vê um servidor de escopo project vindo do .mcp.json, pra que um repositório clonado não suba processos na sua máquina sem consentimento

Agora o ponto crítico, que é o que pega gente boa: em execuções não interativas, ou seja claude -p, sessões do Agent SDK e sessões na nuvem, o Claude Code carrega servidores de escopo project sem perguntar

Erro comum deste passo: confiar no prompt de aprovação como se ele existisse em toda execução, quando o pipeline automatizado nunca vai te perguntar nada

4. Limpe decisões antigas quando o servidor mudar

claude mcp reset-project-choices

Esse comando limpa as decisões de aprovação anteriores para servidores definidos no .mcp.json do projeto

Erro comum deste passo: aprovar uma vez em janeiro e carregar essa aprovação por meses, mesmo depois de o servidor no arquivo ter sido trocado

5. Escreva as regras em /permissions

Ferramentas MCP no Claude Code exigem permissão explícita: sem permissão, o Claude vê que as ferramentas existem, mas não consegue chamá-las

O padrão de nome é este:

mcp__<nome-do-servidor>__<nome-da-ferramenta>
mcp__github__list_issues
mcp__github__get_*
mcp__puppeteer__*
mcp__*

E o que significam esses símbolos?

Nas regras de allow, o glob só vale depois do prefixo literal mcp__<servidor>__, ou seja, o segmento do servidor não aceita glob

Então mcp__github__get_ pega só as ferramentas get_, enquanto mcp__puppeteer__ libera o servidor puppeteer inteiro

Nas regras de deny, o padrão precisa casar com o nome completo da ferramenta: "" pega todas as ferramentas e "mcp__" pega todas as ferramentas MCP de todos os servidores

Dá pra aprovar a ação uma vez ou escrever a própria regra em /permissions

Erro comum deste passo: liberar o servidor inteiro no allow por preguiça de listar as leituras que você realmente usa

6. Audite e desfaça

claude mcp list
claude mcp remove nome-do-servidor

O claude mcp list mostra o status de todos os servidores MCP conectados, e o claude mcp remove remove um servidor pelo nome escolhido no cadastro

Dentro da sessão, o comando /mcp serve pra checar e gerenciar servidores já adicionados

Erro comum deste passo: deixar servidor de teste conectado pra sempre, porque desinstalar dá menos dopamina que instalar haha

Como aplicar o checklist conforme o seu cenário

O checklist é o mesmo, o aperto muda

Dev solo testando uma integração da comunidade:

Deixa no escopo local mesmo, que é o padrão do claude mcp add

Deny amplo com mcp__* e allow só das leituras que você precisa naquele momento

Se o serviço permitir credencial restrita, usa: no caso do GitHub, o modo somente leitura já resolve boa parte, porque tem precedência sobre as outras configurações

Vale considerar também se você precisa mesmo daquele servidor avulso ou se dá pra viver com os MCPs já embutidos no cliente que você usa

Time compartilhando .mcp.json no repositório:

Aqui o –scope project é o ponto: o arquivo foi pensado pra compartilhamento com o time, e todo mundo que clonar vai ver aquele servidor

A aprovação da primeira vez protege as sessões interativas

O CI não

Então trata pipeline com claude -p, Agent SDK e sessão na nuvem como carregamento silencioso, porque é isso que eles são

E depois de qualquer mudança no arquivo, claude mcp reset-project-choices pra não arrastar aprovação velha

Organização:

Administradores podem restringir quais servidores MCP rodam na organização via arquivos de configuração gerenciada, com allowlists e denylists, chegando a desativar MCP por completo

As managed settings têm precedência sobre a configuração local do desenvolvedor, então isso não é sugestão, é regra

Tome cuidado com um efeito colateral: por padrão, publicar um managed-mcp.json suprime os conectores do claude.ai que o Claude Code busca sozinho

Pra carregar os dois, define "allowAllClaudeAiMcps": true numa fonte de managed settings

O que aparece na prática: conectando um MCP de serviço real

Agora um relato honesto, porque eu mesmo já fiz isso no modo rápido

No vídeo abaixo eu monto um clone de Linktree do zero ao deploy usando Antigravity com o MCP do Supabase, e a parte de segurança aparece meio sem querer

A primeira coisa que o fluxo pediu foi um access token da conta

Gerei o token no painel do Supabase, dei um nome e escolhi a data de expiração, e falei ali mesmo que colocar "never" não seria problema pra quem confia na própria máquina

Revendo com calma: "never" é conveniência, não é decisão de segurança

Outro detalhe que eu aviso no vídeo: o token só aparece uma vez na tela de geração, se não copiar na hora tem que criar outro

Depois de colar e salvar, dei refresh e fui conferir a aba de tools pra ver o que aquele servidor conseguia fazer com a credencial

E o alcance é grande: pegar projeto, criar projeto, listar tabelas

Resumindo o que eu falo lá: o servidor podia fazer praticamente tudo

Defendi no vídeo que, com o MCP conectado, não precisa mexer em chave de ambiente do Supabase no projeto, porque a conexão já está feita pelo servidor

Quando o agente criou um arquivo de variáveis de ambiente mesmo assim, eu ignorei o arquivo e segui pro prompt seguinte

Pedi ao agente, via MCP, pra criar um projeto novo e montar as tabelas, e o servidor criou o projeto na minha conta de verdade

Como a conta tinha 2 organizações, o fluxo perguntou em qual organização criar

Escolhi manualmente, e é justamente esse tipo de pergunta que merece atenção: antes de liberar, confere a QUAL conta e a qual projeto o agente ganhou alcance

Ainda no prompt de criação do banco, fiz questão de pedir o RLS configurado, que é item de segurança da aplicação

Depois acompanhei o resultado direto no painel do Supabase pra confirmar que o que o MCP fez apareceu no banco

Repara no vídeo menos no resultado e mais no momento da conexão: quanto do meu "checklist" ali foi gerar o token, colar, dar refresh e olhar a lista de tools?

Foi isso, e só isso

Não tem no vídeo checagem de quem publica e mantém aquele servidor, nem verificação de escopo da credencial

O que salva nessa hora é o que eu digo lá também: conhecimento prévio de programação é o que te permite avaliar e corrigir o que a IA faz, em vez de aceitar tudo cegamente

Conclusão

A pergunta que resolve a maioria dos casos não é "esse servidor é bom?"

É "quanto estrago esse servidor faz no pior cenário?"

Porque o cenário bom se resolve sozinho: é o ruim que cobra a conta

A recomendação oficial da Anthropic continua a mesma, escrever seus próprios servidores MCP ou usar servidores de provedores em que você confia, e a revisão de práticas de segurança e termos é sua

Próximo passo bem concreto pra fechar o post: roda claude mcp list agora, olha escopo e permissões de cada servidor que já está conectado aí, e remove com claude mcp remove tudo que você não usa mais

Aposto que tem pelo menos um servidor esquecido nessa lista 😀

até o próximo post!