0
plugandship
2 min de leitura ·

O que eu confiro antes de instalar um servidor MCP de terceiros (7 coisas, leva uns 10 minutos)

Nas últimas semanas revisei algumas dezenas de servidores MCP que mandaram pra um diretório que eu mantenho, e acabei montando uma lista do que olhar antes de deixar um deles rodar na minha máquina. Servidor MCP local roda como processo com as permissões do seu usuário, e o que ele expõe vai direto pro contexto do agente, então vale uns minutos de checagem.

1. Quem publicou e há quanto tempo

Abro o repositório e vejo a idade da conta ou da org, se tem outros projetos e se o site do produto existe e bate com o que o README promete. Repo criado semana passada não é motivo pra descartar, tem muita coisa boa nova por aí, mas aí eu leio o resto com mais calma.

2. Nome do pacote e da org

Confiro se o comando de instalação aponta pro mesmo pacote do repositório e se o nome não imita um projeto conhecido. Uma letra trocada, um I maiúsculo no lugar de um l ou um hífen a mais é o jeito mais barato de pegar quem copia comando de README sem olhar.

3. Fixar a versão

npx -y pacote e uvx pacote baixam a versão mais nova toda vez que o cliente sobe o servidor. Se sair uma versão maliciosa amanhã, porque a conta do mantenedor foi invadida por exemplo, você roda sem perceber. Eu prefiro fixar:

npx -y pacote@1.4.2
uvx pacote@1.4.2

4. Ler as descrições das ferramentas

Nome, descrição e schema de cada ferramenta entram no contexto do modelo. Já mostraram ataque escondendo instrução nessas descrições, pedindo pro agente ler um arquivo de chave e mandar o conteúdo num parâmetro qualquer. Eu leio as descrições no código antes de ligar. Em servidor remoto isso é menos garantido, porque ele pode mudar as descrições depois que você aprovou.

5. Token com o mínimo de permissão

Se o servidor pede token de GitHub, Notion, banco etc., crio um só pra ele, com o menor escopo possível e, quando dá, só leitura. Token pessoal com tudo liberado dentro de processo de terceiro é pedir pra dar ruim.

6. Contar as ferramentas

Na maioria dos clientes cada ferramenta ocupa contexto em toda conversa. Servidor com 30 ou 40 ferramentas pesa bastante, e se o cliente deixa desligar ferramenta por ferramenta, eu desligo o que não vou usar.

7. Cuidado com o .mcp.json dos outros

No Claude Code, servidor no escopo de projeto fica no .mcp.json do repositório e vai junto pra todo mundo que clonar. O Claude Code pede confirmação antes de usar esses servidores, então clonou repo de terceiro e apareceu esse pedido, abre o .mcp.json e vê o que ele roda antes de aceitar.

Dá uns 10 minutos por servidor e já filtra o grosso. Se vocês olham mais alguma coisa antes de instalar, comenta aí que eu atualizo a lista.

O diretório que citei é o plugandship.dev, que é um site meu.

Carregando publicação patrocinada...
1

Você também confere os destinos de rede que o servidor acessa? Um token só de leitura ainda pode expor dados se o processo os enviar para outro lugar.

1

bem lembrado, isso ficou de fora da lista. pra servidor stdio que só deveria mexer em coisa local, o teste mais barato é rodar ele num container com --network none e ver se continua funcionando. se quebrar, ele tá falando com alguém e aí vale descobrir com quem.

nos que precisam de rede, dá pra subir uma vez com strace -f -e trace=connect e olhar pra quais IPs ele conecta além do serviço que diz usar. não pega tudo, mas pega o caso mais grosseiro.

1

Fixar pacote@1.4.2 segura essa versão. As dependências dele continuam resolvendo na instalação, então o pin não fecha a árvore.

1

verdade, bem lembrado. pacote publicado no npm não leva o package-lock junto (só se o autor publicar um npm-shrinkwrap.json, que quase ninguém faz), então as dependências com ^ pegam a versão mais nova que bater no range. o pin diminui a janela mas não fecha.

pra fechar de verdade dá pra instalar o servidor numa pasta própria, com lockfile e npm ci, e apontar o cliente pro binário de lá em vez de usar npx. no uvx o --exclude-newer com uma data ajuda a travar a resolução também.