How do I use AgentAudit?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AgentAudit audit github.com/modelcontextprotocol/server-filesystem" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

AgentAudit

by agentaudit-dev

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

🛡️ AgentAudit

Security scanner for AI agent packages — CLI + MCP server

Scan MCP servers, AI skills, and packages for vulnerabilities, prompt injection, and supply chain attacks. Powered by regex static analysis and deep LLM audits.

AgentAudit

📑 Table of Contents

Related MCP server: Mund

What is AgentAudit?

AgentAudit is a security scanner purpose-built for the AI package ecosystem. It works in two modes:

CLI tool — Run agentaudit in your terminal to discover and scan MCP servers installed in your AI editors
MCP server — Add to Claude Desktop, Cursor, or Windsurf so your AI agent can audit packages on your behalf

It checks packages against the AgentAudit Trust Registry — a shared, community-driven database of security findings — and can perform local scans ranging from fast regex analysis to deep LLM-powered 3-pass audits.

🚀 Quick Start

Option A: CLI (recommended)

# Install globally (or use npx agentaudit)
npm install -g agentaudit

# Discover MCP servers configured in your AI editors
agentaudit

# Quick scan — clones repo, checks code with regex patterns (~2s)
agentaudit scan https://github.com/owner/repo

# Deep audit — clones repo, sends code to LLM for 3-pass analysis (~30s)
agentaudit audit https://github.com/owner/repo

# Registry lookup — check if a package has been audited before (no cloning)
agentaudit lookup fastmcp

Example output:

  ◆ AgentAudit v3.13.4  │  my-scanner · #3 · 280pts · 19 audits

  Discovering MCP servers in your AI editors...

•  Scanning Cursor  ~/.cursor/mcp.json    found 3 servers

├──  tool   supabase-mcp              ✔ ok
│   SAFE  Risk 0  https://agentaudit.dev/packages/supabase-mcp
├──  tool   browser-tools-mcp         ✔ ok
│   ⚠ not audited  Run: agentaudit audit https://github.com/nichochar/browser-tools-mcp
└──  tool   filesystem                ✔ ok
│   SAFE  Risk 0  https://agentaudit.dev/packages/filesystem

  Looking for general package scanning? Try `pip audit` or `npm audit`.

Enhanced banner: When logged in, the banner shows your agent name, rank, points, and audit count. Run agentaudit setup to create an account.

Option B: MCP Server in your AI editor

Add AgentAudit as an MCP server — your AI agent can then discover, scan, and audit packages using its own LLM. No extra API key needed.

{
  "mcpServers": {
    "agentaudit": {
      "command": "npx",
      "args": ["-y", "agentaudit", "--stdio"]
    }
  }
}

{
  "mcpServers": {
    "agentaudit": {
      "command": "npx",
      "args": ["-y", "agentaudit", "--stdio"]
    }
  }
}

{
  "mcpServers": {
    "agentaudit": {
      "command": "npx",
      "args": ["-y", "agentaudit", "--stdio"]
    }
  }
}

{
  "servers": {
    "agentaudit": {
      "command": "npx",
      "args": ["-y", "agentaudit", "--stdio"]
    }
  }
}

Add to the mcpServers section of your existing config:

{
  "mcpServers": [
    {
      "name": "agentaudit",
      "command": "npx",
      "args": ["-y", "agentaudit", "--stdio"]
    }
  ]
}

{
  "context_servers": {
    "agentaudit": {
      "command": {
        "path": "npx",
        "args": ["-y", "agentaudit", "--stdio"]
      }
    }
  }
}

Then ask your agent: "Check which MCP servers I have installed and audit any unaudited ones."

📋 Commands Reference

Scan & Audit

Command	Description	Example
`agentaudit`	Discover MCP servers (default, same as `discover`)	`agentaudit`
`agentaudit discover`	Find MCP servers in Cursor, Claude, VS Code, Windsurf	`agentaudit discover`
`agentaudit discover --quick`	Discover + auto-scan all servers	`agentaudit discover --quick`
`agentaudit discover --deep`	Discover + interactively select servers to deep-audit	`agentaudit discover --deep`
`agentaudit scan <url>`	Quick regex-based static scan (~2s)	`agentaudit scan https://github.com/owner/repo`
`agentaudit scan <url> --deep`	Deep audit (same as `audit`)	`agentaudit scan https://github.com/owner/repo --deep`
`agentaudit audit <url>`	Deep LLM-powered 3-pass audit + verification (~45s)	`agentaudit audit https://github.com/owner/repo`
`agentaudit audit <url> --verify cross`	Audit + cross-model verification (different model verifies)	`agentaudit audit <url> --verify cross`
`agentaudit audit <url> --remote`	Server-side scan via agentaudit.dev (no LLM key needed, 3/day free)	`agentaudit audit <url> --remote`
`agentaudit consensus <name>`	Cross-model consensus view for a package	`agentaudit consensus supabase-mcp`
`agentaudit lookup <name>`	Look up package in trust registry	`agentaudit lookup fastmcp`
`agentaudit history`	Show local audit history	`agentaudit history`

Community

Command	Alias	Description
`agentaudit dashboard`	`dash`	Interactive full-screen TUI with 5 tabs (Overview, Leaderboard, Benchmark, Activity, Search)
`agentaudit leaderboard`	`lb`	Top contributors ranking (pipe-friendly)
`agentaudit benchmark`	`bench`	LLM model audit performance comparison
`agentaudit activity`	`my`	Your recent audits & findings
`agentaudit search <query>`	`find`	Search packages in the registry by name, ASF-ID, or hash

Configuration

Command	Alias	Description
`agentaudit model`	—	Interactive LLM provider + model configuration
`agentaudit setup`	`login`	Sign in with GitHub OAuth or paste API key manually
`agentaudit status`	`whoami`	Show current config, API keys, and personal stats

Global Flags

Flag	Description
`--json`	Output machine-readable JSON to stdout
`--quiet` / `-q`	Suppress banner and decorative output
`--no-color`	Disable ANSI colors (also respects `NO_COLOR` env var)
`--model <name>`	Override LLM model for this run
`--models <a,b,c>`	Multi-model audit (parallel calls, consensus comparison)
`--verify <mode>`	Adversarial verification: `self` (same model), `cross` (different model), or `<model-name>`. Auto-enabled for registry uploads.
`--no-verify`	Skip verification AND registry upload (local-only scan)
`--remote`	Use agentaudit.dev server for scan (no local LLM key needed)
`--no-upload`	Skip uploading report to registry
`--export`	Export audit payload as markdown
`--debug`	Show raw LLM response on parse errors
`--help` / `-h`	Show help text
`-v` / `--version`	Show version

Exit Codes

Code	Meaning
`0`	Clean — no findings detected, or successful lookup
`1`	Findings detected
`2`	Error (clone failed, network error, invalid args)

⚖️ Quick Scan vs Deep Audit

	Quick Scan (`scan`)	Deep Audit (`audit`)
Speed	~2 seconds	~30 seconds
Method	Regex pattern matching	LLM-powered 3-pass analysis
API key needed	No	Yes (Anthropic, OpenAI, or OpenRouter)
False positives	Higher (regex limitations)	Very low (context-aware)
Detects	Common patterns (injection, secrets, eval)	Complex attack chains, AI-specific threats, obfuscation
Best for	Quick triage, CI pipelines	Critical packages, pre-production review

Tip: Use agentaudit scan <url> --deep to run a deep audit via the scan command.

🔌 MCP Server

When running as an MCP server, AgentAudit exposes the following tools to your AI agent:

Tool	Description
`audit_package`	Deep LLM-powered audit of a repository
`check_registry`	Look up a package in the trust registry
`submit_report`	Upload audit findings to the registry
`discover_servers`	Find MCP servers in local editor configs
`consensus_analysis`	Cross-model consensus view for a package
`search_packages`	Search packages in the registry by name, ASF-ID, or hash
`scan_tool_poisoning`	Detect tool poisoning in MCP tool descriptions

Workflow

User asks agent to install a package
         │
         ▼
Agent calls check_registry(package_name)
         │
    ┌────┴────┐
    │         │
  Found    Not Found
    │         │
    ▼         ▼
 Return    Agent calls audit_package(repo_url)
 score        │
              ▼
         LLM analyzes code (3-pass)
              │
              ▼
         Agent calls submit_report(findings)
              │
              ▼
         Return findings + risk score

🎯 What It Detects

Core Security

Command Injection Credential Theft Data Exfiltration SQL Injection Path Traversal Unsafe Deserialization

AI-Specific

Prompt Injection Jailbreak Agent Impersonation Capability Escalation Context Pollution Hidden Instructions

MCP-Specific

Tool Poisoning Desc Injection Resource Traversal Unpinned npx Broad Permissions

Persistence & Obfuscation

Crontab Mod Shell RC Inject Git Hook Abuse Zero-Width Chars Base64 Exec ANSI Escape

🧠 How the 3-Pass Audit Works

The deep audit (agentaudit audit) uses a structured 3-phase LLM analysis — not a single-shot prompt, but a rigorous multi-pass process:

Phase	Name	What Happens
1	🔍 UNDERSTAND	Read all files and build a Package Profile: purpose, category, expected behaviors, trust boundaries. No scanning yet — the goal is to understand what the package should do before looking for what it shouldn't.
2	🎯 DETECT	Evidence collection against 50+ detection patterns across 8 categories (AI-specific, MCP, persistence, obfuscation, cross-file correlation). Only facts are recorded — no severity judgments yet.
3	⚖️ CLASSIFY	Every finding goes through a Mandatory Self-Check (5 questions), Exploitability Assessment, and Confidence Gating. HIGH/CRITICAL findings must survive a Devil's Advocate challenge and include a full Reasoning Chain.

Why 3 passes? Single-pass analysis is the #1 cause of false positives. By separating understanding → detection → classification:

Phase 1 prevents flagging core functionality as suspicious (e.g., SQL execution in a database tool)
Phase 2 ensures evidence is collected without severity bias
Phase 3 catches false positives before they reach the report

This architecture achieved 0% false positives on our 11-package test set, down from 42% in v2.

Adversarial Verification Pass (v3.14+)

After the 3-pass audit, a verification pass re-examines each finding against the actual source code. Verification is auto-enabled when uploading to the registry to ensure data quality. For local-only scans, use --no-verify to skip it (this also disables registry upload).

# Verification runs automatically when uploading (default behavior)
agentaudit audit https://github.com/owner/repo

# Explicit verification mode
agentaudit audit https://github.com/owner/repo --verify cross

# Skip verification + upload (local-only, fast)
agentaudit audit https://github.com/owner/repo --no-verify

Each finding goes through a 5-point checklist:

Code Existence — Does the cited code actually exist in the file?
Context Accuracy — Is the code used in the way described?
Execution Model — Can an attacker actually trigger this?
Severity Calibration — Is the severity appropriate?
Fabrication Check — Are there hallucinated details?

Verdicts: verified (confirmed real), demoted (severity reduced), rejected (false positive removed).

Why require verification for uploads? LLMs can hallucinate code that doesn't exist or overstate severity. Without verification, false positives enter the public registry and unfairly flag packages as unsafe. The verification pass catches these before they become permanent records.

Model Accuracy (Real-World Data)

We benchmarked multiple LLMs on the Top 20 most popular MCP servers (62+ reports):

Model	Findings on Top 20	Precision	Assessment
Claude Opus 4.6	0 findings (all clean)	N/A	Very conservative — ideal for avoiding false positives
Gemini 2.5 Flash	Many findings	~30% strict	High false positive rate — not recommended for production audits

Key insight: Model choice dramatically affects audit quality. We recommend Claude Opus 4 or Claude Sonnet 4 for production audits. Use --models to run multiple models and compare results via consensus.

🔄 CI/CD Integration

AgentAudit is designed for CI pipelines with proper exit codes and JSON output:

# GitHub Actions example
- name: Scan MCP servers
  run: |
    npx agentaudit scan https://github.com/org/mcp-server --json --quiet > results.json
    # Exit code 1 = findings detected → fail the build

# Shell scripting
agentaudit scan https://github.com/owner/repo --json --quiet 2>/dev/null
if [ $? -eq 1 ]; then
  echo "Security findings detected!"
  exit 1
fi

JSON Output Examples

# Scan with JSON output
agentaudit scan https://github.com/owner/repo --json

{
  "slug": "repo",
  "url": "https://github.com/owner/repo",
  "findings": [
    {
      "severity": "high",
      "title": "Command injection risk",
      "file": "src/handler.js",
      "line": 42,
      "snippet": "exec(`git ${userInput}`)"
    }
  ],
  "fileCount": 15,
  "duration": "1.8s"
}

# Registry lookup with JSON
agentaudit lookup fastmcp --json

Coming soon: --fail-on <severity> flag to set minimum severity threshold for non-zero exit (e.g., --fail-on high ignores low/medium findings).

📊 Dashboard & Community

AgentAudit includes a full-screen interactive dashboard and standalone community commands.

Interactive Dashboard

agentaudit dashboard    # or: agentaudit dash

5-tab TUI with keyboard navigation (←→ tabs, ↑↓ scroll, 1-5 jump, q quit). Overview tab includes interactive Quick Actions — select and launch audits, consensus views, or remote scans directly from the dashboard:

Tab	Content
[1] Overview	Your profile + registry stats + interactive Quick Actions (press a/v/r/c or Enter)
[2] Leaderboard	Top contributors with medal rankings and bar charts
[3] Benchmark	LLM model audit performance comparison
[4] Activity	Your recent audits and findings
[5] Search	Interactive package search (type to search, Enter to submit)

Standalone Commands

All community commands work without the dashboard (pipe-friendly, supports --json):

agentaudit leaderboard              # Top contributors
agentaudit leaderboard --tab monthly --json   # Monthly rankings as JSON
agentaudit benchmark                # Model comparison
agentaudit activity                 # Your recent audits & findings
agentaudit search fastmcp           # Search registry by name/ASF-ID
agentaudit search fastmcp --json    # Machine-readable search results

⚙️ Configuration

Credentials

AgentAudit stores credentials in ~/.config/agentaudit/credentials.json (or $XDG_CONFIG_HOME/agentaudit/credentials.json).

Run agentaudit setup to sign in with GitHub or paste an API key, or set via environment:

export AGENTAUDIT_API_KEY=asf_your_key_here

LLM Providers (13 supported)

AgentAudit supports 13 LLM providers for deep audits. Set one API key — the CLI auto-detects it. Use agentaudit model to choose provider + model interactively, or agentaudit status to check your setup.

Variable	Provider	Default Model
`ANTHROPIC_API_KEY`	Anthropic (Claude)	`claude-sonnet-4-20250514`
`GEMINI_API_KEY`	Google (Gemini)	`gemini-2.5-flash`
`OPENAI_API_KEY`	OpenAI (GPT-4o)	`gpt-4o`
`DEEPSEEK_API_KEY`	DeepSeek	`deepseek-chat`
`MISTRAL_API_KEY`	Mistral	`mistral-large-latest`
`GROQ_API_KEY`	Groq	`llama-3.3-70b-versatile`
`XAI_API_KEY`	xAI (Grok)	`grok-3`
`TOGETHER_API_KEY`	Together AI	`Llama-3.3-70B-Instruct-Turbo`
`FIREWORKS_API_KEY`	Fireworks AI	`llama-v3p3-70b-instruct`
`CEREBRAS_API_KEY`	Cerebras	`llama-3.3-70b`
`ZAI_API_KEY`	Zhipu AI (GLM)	`glm-4.7`
`OPENROUTER_API_KEY`	OpenRouter	`anthropic/claude-sonnet-4`

Other Environment Variables

Variable	Description
`AGENTAUDIT_API_KEY`	API key for registry uploads (or use `agentaudit setup`)
`AGENTAUDIT_MODEL`	Override LLM model (same as `--model` flag)
`NO_COLOR`	Disable ANSI colors (no-color.org)

Provider priority: Set preferred_provider via agentaudit model, or the CLI picks the first available key. Override per-run with --model <name>.

📦 Requirements

Node.js ≥ 18.0.0
Git (for cloning repositories during scan/audit)

❓ FAQ

How do I set up AgentAudit?

npm install -g agentaudit
agentaudit setup

Or use without installing: npx agentaudit

Do I need an API key?

Quick scan (scan): No API key needed — runs locally with regex
Deep audit (audit): Needs an LLM API key (see below)
Registry lookup (lookup): No key needed for reading; key needed for uploading reports
MCP server: No extra key needed — uses the host editor's LLM

Setting up your LLM key for deep audits

The audit command supports 13 LLM providers. Set one API key and AgentAudit auto-detects it:

# Set any one of these (Anthropic recommended)
export ANTHROPIC_API_KEY=sk-ant-...
export OPENAI_API_KEY=sk-...
export GEMINI_API_KEY=...
export DEEPSEEK_API_KEY=...
# ... or any of the 13 supported providers (see Configuration section)

Interactive setup:

agentaudit model     # 2-step menu: pick provider → pick model
agentaudit status    # check which keys are set + current config

Override per-run:

agentaudit audit https://github.com/owner/repo --model gpt-4o

Troubleshooting: If you see API error: Incorrect API key, double-check your key is valid and has credits. Use --debug to see the full API response.

What data is sent externally?

Registry lookups: Package name/slug is sent to agentaudit.dev to check for existing audits
Report uploads: Audit findings are uploaded to the public registry (requires API key)
Deep audits: Source code is sent to Anthropic or OpenAI for LLM analysis
Quick scans: Everything stays local — no data leaves your machine

Can I use it offline?

Quick scans (agentaudit scan) work fully offline after cloning. Registry lookups and deep audits require network access.

Can I use it as an MCP server without the CLI?

Yes! npx agentaudit starts the MCP server when invoked by an editor. The CLI and MCP server are the same package — behavior is determined by how it's called.

How does `discover` know which editors I use?

It checks standard config file locations for Claude Desktop, Cursor, VS Code, and Windsurf. It also checks the current working directory for project-level .cursor/mcp.json and .vscode/mcp.json.

	Project	Description
🌐	agentaudit.dev	Trust Registry -- browse packages, findings, leaderboard
🛡️	agentaudit-skill	Agent Skill -- pre-install security gate for Claude Code, Cursor, Windsurf
⚡	agentaudit-github-action	GitHub Action -- CI/CD security scanning
📚	agentaudit-cli	This repo -- CLI + MCP server source
🐛	Report Issues	Bug reports and feature requests

📄 License

AGPL-3.0 — Free for open source use. Commercial license available for proprietary integrations.

Protect your AI stack. Scan before you trust.

Trust Registry · Leaderboard · Report Issues

Available Tools

5 tools

audit_packageA

Deep security audit of a Git repository. Clones the repo and returns source code with a 3-pass audit methodology (UNDERSTAND → DETECT → CLASSIFY). You then analyze the code and call submit_report with findings. Use check_package FIRST to see if an audit already exists — only use this for unaudited packages or when a fresh audit is requested.

ParametersJSON Schema

Name	Required	Description	Default
`source_url`	Yes	Git repository URL to audit (e.g., https://github.com/owner/repo)

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses the 3-pass methodology, that it clones the repo, and that the user must analyze and call submit_report. It does not detail side effects like permissions or error states, but is sufficient for understanding behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded with purpose, methodology, and usage guidance. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no output schema, and good sibling context, the description is nearly complete. It could mention the return format explicitly but is sufficient for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description for source_url. The description adds 'Clones the repo' context, but this is already implied. No additional parameter meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs a 'Deep security audit of a Git repository' with a specific methodology (UNDERSTAND → DETECT → CLASSIFY). It distinguishes from sibling tools like check_package (pre-check) and submit_report (post-audit) by outlining the workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to 'use check_package FIRST to see if an audit already exists — only use this for unaudited packages or when a fresh audit is requested.' This provides clear guidance on when to use and when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_packageA

Look up a package in the AgentAudit security registry. USE THIS FIRST whenever the user wants to install, add, evaluate, or learn about a specific MCP server or package. Returns risk score, findings, and official audit status if available. If the package is not yet in the registry, suggests running an audit. This is the go-to tool for any "is this safe?" or "should I install this?" question.

ParametersJSON Schema

Name	Required	Description	Default
`package_name`	Yes	Package name or slug to look up (e.g., "fastmcp", "mongodb-mcp-server")

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It transparently describes the return values: 'risk score, findings, and official audit status,' and explains behavior for missing packages (suggests running an audit). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose. Every sentence earns its place—first states action, second adds usage guidance and fallback behavior. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 param, no output schema, no annotations), the description is sufficiently complete. It covers purpose, returns, and usage context. Missing information about authentication or rate limits is acceptable given the tool's nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds the example values 'fastmcp', 'mongodb-mcp-server', but this is largely redundant with the schema's description. No additional semantic meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Look up a package in the AgentAudit security registry.' It uses a specific verb and resource, and immediately distinguishes itself from siblings by instructing to use this first for installations or safety queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use: 'USE THIS FIRST whenever the user wants to install, add, evaluate, or learn about a specific MCP server or package.' It also provides context for not-found cases. However, it lacks explicit exclusions or direct mention of alternative sibling tools like audit_package.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

discover_serversA

Scan local config files to list ALREADY INSTALLED MCP servers (Claude Desktop, Cursor, Windsurf, VS Code). Use ONLY when the user wants to review/list their existing servers. Do NOT use this when the user wants to install, evaluate, or look up a specific package — use check_package for that instead.

ParametersJSON Schema

Name	Required	Description	Default
`check_registry`	No	If true, also check each discovered server against the AgentAudit registry (default: true)

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses the action (scanning local config files, listing servers) and implies it is a read-only, non-destructive operation. Could explicitly state no side effects or permissions required, but current text adequately conveys the behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no waste: first sentence declares action and scope, second sentence provides usage guidance and alternative. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description covers purpose and usage fully. No output schema, but the tool's output (list of servers) is implied. Could benefit from mentioning the output format or what each entry contains, but still sufficient for a discovery tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter (check_registry). The description adds no extra meaning beyond the schema's own description, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scans local config files to list already installed MCP servers, specifying the exact apps (Claude Desktop, Cursor, Windsurf, VS Code). It differentiates from sibling check_package by explicitly contrasting use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use ('when user wants to review/list existing servers') and when-not-to-use ('install, evaluate, or look up a specific package'), with a direct alternative ('use check_package instead').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_tool_poisoningA

Scan MCP tool definitions for hidden instructions, unicode tricks, obfuscated payloads, and manipulation patterns. Use this to check if a server's tools contain poisoning indicators (prompt injection in descriptions, zero-width characters, cross-tool manipulation, homoglyph attacks). Provide tool definitions directly OR a source_url to extract them from code.

ParametersJSON Schema

Name	Required	Description
`tool_definitions`	No	Array of tool definition objects to scan. Each object should have: name (string), description (string), inputSchema (object, optional).
`source_url`	No	Git repository URL. If provided (and no tool_definitions), will clone the repo and attempt to statically extract tool definitions from source code.
`server_name`	No	Name of the MCP server being scanned (for reporting purposes).

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses what it scans for and input methods, but lacks details about side effects (e.g., whether source_url clones a repo, output format, or if it is read-only). It adds context but is not fully exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second covers usage and input options. No wasted words, front-loaded with critical information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite good input guidance, the description omits output information (what returns, format, status codes). With no output schema, this is a significant gap for an agent to understand the tool's behavior fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaningful context by explaining the structure of tool_definitions objects and the conditional usage of source_url. This goes beyond the schema's descriptions, which only list properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs and resources: 'Scan MCP tool definitions for hidden instructions, unicode tricks, obfuscated payloads, and manipulation patterns.' It clearly distinguishes from sibling tools that deal with packages or servers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use it ('check if a server's tools contain poisoning indicators') and provides input options (tool_definitions or source_url). However, it does not mention when not to use it or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

submit_reportA

Submit a completed security audit report to the AgentAudit registry (agentaudit.dev). Call this after you have analyzed the code from audit_package. The report becomes publicly available and helps other agents make install decisions.

ParametersJSON Schema

Name	Required	Description	Default
`report`	Yes	The audit report JSON object. Required fields: skill_slug, source_url, risk_score (0-100), result (safe\|caution\|unsafe), findings (array), findings_count, max_severity, package_type.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states the report becomes publicly available, implying permanence, but does not disclose other behaviors like permissions needed, error cases, or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two clear sentences: one for what it does, one for when to use it. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter and no output schema, the description covers purpose, prerequisite, and outcome. Could be improved by mentioning success/failure indicators or error handling, but still sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with comprehensive subfield descriptions. The tool description adds no extra meaning beyond 'submit a completed report', so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool submits a completed security audit report to AgentAudit registry, distinguishing it from sibling tools like audit_package (analysis) and scan_tool_poisoning (scanning).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to call after analyzing code from audit_package, providing clear usage context. However, does not explicitly mention when not to use or list alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv3.14.0Jun 8, 2026
- First observedaudit_package
- First observedcheck_package
- First observeddiscover_servers
- First observedscan_tool_poisoning
- First observedsubmit_report

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct action and object: audit_package for deep code audit, check_package for registry lookup, discover_servers for local installation listing, scan_tool_poisoning for tool definition analysis, submit_report for report submission. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase with underscores: audit_package, check_package, discover_servers, scan_tool_poisoning, submit_report. The verbs clearly indicate the action.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of security auditing of MCP packages. Each tool serves a necessary step in the audit workflow without unnecessary redundancy.

Completeness5/5

The tool set covers the full audit lifecycle: check if audit exists (check_package), perform audit (audit_package), scan for poisoning (scan_tool_poisoning), submit results (submit_report), and discover installed servers (discover_servers). No obvious missing functionality.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
shadowgate-mcp
io.github.josephibra
Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.
Security Monitoring
2
Frogeye Security Scanner A
io.github.frogeye-ai
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security Penetration Testing
2
Helixar Security A
ai.helixar
Security tools for AI agents: scan MCP servers, validate HDP delegation chains, audit releases.
Security Penetration Testing
2

Related MCP Servers

inkog
Security Testing & QA Tools AI & Machine Learning
inkog-io
A
license
A
quality
C
maintenance
Security co-pilot for AI agents. Scans for vulnerabilities like prompt injection, infinite loops, and token bombing in AI Agents, audits MCP servers, verifies AGENTS.md governance, and generates EU AI Act compliance reports.
Updated 3 months ago (2026-06-07 12:07 UTC)
10
86
3
Apache 2.0
Mund
Security Testing & QA Tools Autonomous Agents
Tyox-all
A
license
Not graded
quality
A
maintenance
MCP security scanner for AI agents - detects prompt injection, secrets, PII, and vets MCP servers before installation
Updated 13 days ago (2026-08-24 15:08 UTC)
Apache 2.0
MCPAmpel
Security Developer Tools Monitoring
MCPAmpel
A
license
A
quality
D
maintenance
A security scanner that evaluates installed MCP servers for vulnerabilities by aggregating findings from 16 scanning engines into detailed trust scores. It enables users to scan their local AI agent configurations or specific repository URLs for potential security risks.
Updated 5 months ago (2026-04-02 20:32 UTC)
4
2
Apache 2.0
AgentAuditofficial
Penetration Testing Security Code Analysis
agentaudit-dev
A
license
A
quality
D
maintenance
Enables AI agents to scan MCP servers and AI packages for vulnerabilities, prompt injection, and supply chain attacks.
Updated 6 months ago (2026-03-01 09:32 UTC)
7
29
AGPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/agentaudit-dev/agentaudit-cli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🛡️ AgentAudit

📑 Table of Contents

What is AgentAudit?

🚀 Quick Start

Option A: CLI (recommended)

Option B: MCP Server in your AI editor

📋 Commands Reference

Scan & Audit

Community

Configuration

Global Flags

Exit Codes

⚖️ Quick Scan vs Deep Audit

🔌 MCP Server

Workflow

🎯 What It Detects

🧠 How the 3-Pass Audit Works

Adversarial Verification Pass (v3.14+)

Model Accuracy (Real-World Data)

🔄 CI/CD Integration

JSON Output Examples

📊 Dashboard & Community

Interactive Dashboard

Standalone Commands

⚙️ Configuration

Credentials

LLM Providers (13 supported)

Other Environment Variables

📦 Requirements

❓ FAQ

How do I set up AgentAudit?

Do I need an API key?

Setting up your LLM key for deep audits

What data is sent externally?

Can I use it offline?

Can I use it as an MCP server without the CLI?

How does discover know which editors I use?

🔗 Related

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

AgentAuditofficial

Latest Blog Posts

MCP directory API

How does `discover` know which editors I use?