Todo servidor MCP ao qual você se conecta envia uma resposta tools/list — um documento JSON escrito por quem quer que tenha construído o servidor — direto para o contexto do seu modelo, sem revisão. Cole essa resposta no scanner da VeriSwarm e obtenha 11 verificações determinísticas em segundos: envenenamento de ferramentas, typosquatting, manipulação de esquemas, padrões de rug-pull, injeção de prompt, permissões excessivas, vinculação incorreta de modelo, falsificação de contexto, canais encobertos, referências de memória inseguras e injeção de cabeçalhos. Nenhum LLM julgando suas ferramentas — análise de padrões e estrutura que devolve o mesmo veredito sempre.
Os metadados de uma ferramenta MCP são estruturais. O modelo decide o que chamar e como com base no texto da descrição — não no código por trás dela. Uma descrição envenenada não precisa comprometer nada; o ataque acontece inteiramente no raciocínio do modelo. O benchmark MCPTox testou isso contra 45 servidores MCP reais e 353 ferramentas reais e mediu taxas de sucesso de ataque acima de 60%, chegando a 72%. Ler descrições de ferramentas a olho não escala além do primeiro servidor, e não sobrevive a um rug pull — um servidor que se comporta bem durante sua revisão e entrega algo diferente na próxima atualização de versão.
Elas cobrem as categorias de risco originais para as quais o scanner foi construído — as mais prováveis de aparecer em uma definição de ferramenta envenenada ou descuidada.
Instruções ocultas em descrições e no texto de parâmetros — “ignore as instruções anteriores”, diretivas de ocultação, sequestros de persona. O scanner percorre toda a árvore do esquema, incluindo propriedades aninhadas dentro de ramos oneOf/anyOf, então um payload enterrado quatro níveis abaixo ainda assim aparece.
Nomes de ferramentas suspeitosamente parecidos com ferramentas conhecidas — incluindo imitações que mudam só a caixa das letras, como READ_FILE se passando por read_file, algo que uma comparação exata e ingênua não pega de jeito nenhum.
Esquemas de objeto vazios que aceitam qualquer entrada, additionalProperties: true que deixa passar campos ocultos, além de aninhamento de esquema além de 4 níveis de profundidade — um lugar comum para esconder um parâmetro malicioso.
Linguagem que pede credenciais, tokens ou acesso a arquivos sensíveis e endpoints de rede internos que o propósito declarado da ferramenta não justifica — a preparação para uma redefinição posterior assim que a ferramenta passa a ser confiável.
Blobs em Base64 que se decodificam em texto legível — contrabando de payload — e homóglifos Unicode, como um а cirílico substituindo o seu a, usados para colar instruções passando por uma revisão visual.
Uma ferramenta nomeada ou descrita como somente leitura mas que aceita os parâmetros command, script ou sql está declarando uma capacidade e entregando outra.
Riscos específicos do protocolo que as seis originais não cobrem. No total das onze verificações, o scanner cobre 9 dos 10 riscos do OWASP MCP Top 10 v0.1-beta (2025). O décimo — MCP08, Lack of Audit and Telemetry — é algo que uma definição estática de ferramenta não consegue mostrar; é uma lacuna de log em tempo de execução, não de esquema.
Ferramentas travadas em um modelo específico — “só funciona com GPT-4” ou um requisito de acoplamento a um system prompt específico. Cria uma dependência de roteamento e uma superfície de exploração específica daquele modelo.
Uma ferramenta que afirma poder reescrever o histórico da conversa, injetar turnos falsos ou se passar pelo usuário ou pelo assistente — capacidades que podem derrubar filtros de segurança e trilhas de auditoria ao mesmo tempo.
Chaves de nível superior não padronizadas, campos de esquema de extensão de fornecedor (x-) e longos blobs em base64 embutidos em descrições — lugares onde um revisor procurando por texto corrido não vai olhar.
Linguagem que reivindica acesso a estado global, compartilhado ou entre sessões, ou um parâmetro session_id com um curinga como padrão — o padrão por trás de uma quebra de isolamento entre tenants.
Um parâmetro com formato de nome de cabeçalho — incluindo authorization, cookie ou host — ou um conectado a uma solicitação de saída via extensão x-mcp-header da especificação MCP. Ambos podem sobrescrever um cabeçalho de fronteira de confiança que quem chama nunca vê.
As mesmas 11 verificações, o mesmo formato de relatório, três formas de fazer:
POST /v1/suite/guard/scan-mcp com as definições das ferramentas no corpo. Retorna um veredito (pass / warn / fail), uma pontuação de risco de 0-1 e um array de achados — cada achado traz o nome da ferramenta, a verificação que disparou, a severidade, evidências e uma recomendação.scanMcpTools() no SDK de Node, scan_mcp_tools() no SDK de Python — ambos encapsulam o mesmo endpoint com formatos de requisição/resposta tipados.scan_mcp_tools no próprio servidor MCP da VeriSwarm permite que ele escaneie as ferramentas de outro servidor antes mesmo de chamá-las — sem precisar de um cliente HTTP separado.Achados com severidade crítica ou alta são persistidos como achados de escaneamento do Guard no seu tenant, então um resultado de escaneamento não é uma impressão de console avulsa — é um registro que você pode revisar, priorizar e encerrar ao longo do tempo.
Uma definição de ferramenta escaneada como limpa hoje pode entregar algo diferente amanhã — a característica que define um rug pull é justamente que a versão que você auditou não é a versão que você vai rodar na semana que vem. Rode o escaneamento a cada atualização de versão do servidor MCP, ou segundo uma programação, não só na primeira conexão. O scanner é a metade pré-implantação da história; a metade em tempo de execução — filtrando chamadas de ferramentas ao vivo conforme acontecem, depois que o servidor já passou por um escaneamento — é o Guard Proxy. Nenhum substitui o outro: o scanner detecta o que uma ferramenta declara, o Guard Proxy detecta o que ela faz.
O envenenamento de ferramentas é a verificação que mais vale a pena entender a fundo — é aquela em que o ataque acontece inteiramente dentro do raciocínio do modelo, sem nada para interceptar na camada de rede. A mecânica do ataque, as taxas reais de sucesso e como o scanner o detecta estão detalhados em Envenenamento de ferramentas MCP: como o ataque funciona e como detectá-lo.
Chame o método tools/list dele para obter as definições das ferramentas, depois envie esse array para o scanner da VeriSwarm — POST /v1/suite/guard/scan-mcp, o scanMcpTools() do SDK de Node, o scan_mcp_tools() do SDK de Python, ou a ferramenta scan_mcp_tools do servidor MCP hospedado. Os quatro chamam o mesmo motor de 11 verificações e retornam o mesmo relatório estruturado: um veredito (pass/warn/fail), uma pontuação de risco de 0-1 e, para cada achado, severidade, evidências e uma recomendação.
Onze verificações determinísticas: envenenamento de ferramentas, typosquatting, manipulação de esquemas, padrões de rug-pull, injeção de prompt e permissões excessivas cobrem as seis categorias de risco originais; vinculação incorreta de modelo, falsificação de contexto, canais encobertos, referências de memória inseguras e injeção de cabeçalhos alinham o scanner a 9 dos 10 riscos do OWASP MCP Top 10 v0.1-beta (2025) — todo risco exceto o MCP08 (Lack of Audit and Telemetry), que não é algo que uma definição estática de ferramenta consiga te mostrar; precisa de log em tempo de execução, não de um escaneamento de esquema. Cada verificação é baseada em padrões e estrutura — nenhum LLM no meio do caminho, então uma dada definição de ferramenta produz os mesmos achados toda vez que você a escaneia.
Não. É um analisador estático — padrões de regex, percursos da árvore do esquema e normalização Unicode, não uma chamada a um modelo. É uma escolha deliberada: juízes probabilísticos são o motivo pelo qual pelo menos uma auditoria independente de um scanner MCP baseado em YARA reportou uma taxa de falsos positivos de cerca de 78%. Verificações determinísticas trocam um pouco de recall por algo em que um pipeline de CI realmente pode se basear como portão de qualidade — a mesma entrada produz o mesmo veredito duas vezes.
Ambos. No CI, salve a resposta tools/list de um servidor em um arquivo e escaneie-a como uma etapa do pipeline — um achado crítico é um build que falha, não uma thread no Slack depois do ocorrido. Em produção, chame o endpoint da API segundo uma programação ou a cada atualização de versão do servidor MCP, porque uma ferramenta que escaneou limpa uma vez só é conhecida como boa naquela vez. Reescanear é como um rug-pull — um servidor que se comporta bem durante a revisão e fica malicioso depois — é pego em vez de passar despercebido.
O scanner é a metade pré-implantação: ele lê as definições de ferramentas declaradas antes mesmo do seu agente chamar o servidor. O Guard Proxy é a metade em tempo de execução: ele fica entre seu agente e suas ferramentas, filtrando cada chamada ao vivo conforme acontece. Nenhum substitui o outro. O scanner detecta o que uma ferramenta diz que faz; o Guard Proxy detecta o que ela realmente faz no momento da chamada.
É medido, não teórico. O benchmark MCPTox testou o envenenamento de ferramentas contra 45 servidores MCP reais e 353 ferramentas reais, e encontrou taxas de sucesso de ataque acima de 60%, chegando a 72% no pico — com modelos mais capazes obedecendo com mais frequência, porque seguir melhor instruções também significa cumprir melhor uma instrução maliciosa. Um detalhamento completo da mecânica do ataque e de como a verificação tool_poisoning do scanner o detecta está no explicativo dedicado.
Envie uma resposta tools/list para o Guard e veja o que seus agentes andam lendo. O plano gratuito do Gate te dá primeiro o pipeline de pontuação de confiança e eventos; o scanner do Guard funciona em cima dele.