mcp-audit

See what your AI tools' MCP servers can reach.

MCPAudit reviews MCP server configuration and, when asked, lists the tools a server exposes. It highlights declared capabilities, instruction-shaped text heuristics, and changes from a saved pin so you can decide what to investigate. Findings are review signals: a high score means broader capability exposure, not that a server is malicious or unsafe.

Try it

mcp-audit                              # static review of supported configs
mcp-audit check --config ./mcp.json    # review this file only; no connections
mcp-audit demo                         # see a bundled synthetic example
mcp-audit explain MCP007               # explain a finding offline; no config reads

Install with uv:

uv tool install mcp-audits

Or run without installing:

uvx --from mcp-audits mcp-audit demo

What to do with a finding

Start with the suggested action and inspect the named capability or evidence. For example, if a filesystem server can write broadly, restrict its configured directory and review the report again. Pattern-based instruction checks can miss reworded or obfuscated text and can also need human review. A clean report is not a safety certificate.

Review the server's configured access, narrow it if needed, then run the check again.

Use Start here for a guided walkthrough and Reading results to interpret scores, findings, and coverage. How it works explains the check boundary.

Each rule's meaning, possible consequences, manual fix and confidence limits are in the finding reference; mcp-audit explain MCP013 prints the same entry offline. Explicit --config sources are labeled "explicit file; parsed as Claude-style config"; the parser identity does not establish which client uses that file.

Static tool metadata checks also flag malformed MCP header annotations, credential parameters mapped to headers, external schema references and unexpected icon sources. These checks inspect served metadata without fetching schemas or icons.

Use in CI

MCPAudit can write SARIF and evaluate local policy files. Begin with config-only CI, then enable connected checks only where the workflow should start those servers. See the CI guide and policy examples.

For a pinned release example, the composite Action can upload SARIF to GitHub code scanning:

- uses: saagpatel/MCPAudit@v2.9.0

The release checklist calls out Action references so maintainers can update examples when a new public release is available. Review the action's permissions and inputs before enabling it in a repository.

Choose a review path

The ID for a connected check has the form CLIENT:SCOPE:NAME. Use the exact identity shown by inspect; the command refuses ambiguous selections. A connected check can start the configured local command or contact its endpoint.

checkup writes a local, counts-only share card with no names by default; see the checkup guide.

Keep the evidence in context

Configuration-based findings describe declared access. A connected listing adds the tool metadata the server provides, but does not prove what the server will do later. Connected HTTP scans also send one credential-free server/discover request and, on 401, review bounded public authorization metadata. The probe never uses configuration header values and does not run with --skip-connect or for project sources without connection opt-in. These observations do not prove a completed OAuth flow. The optional canary is bounded and exercises only eligible tools under its documented limits. See How it works for the boundary between those observations.

Reports can contain configuration shape, tool names, and evidence text. Secret redaction is best-effort (known issues); review a report before sharing it. Configs are parsed in full, but environment variable values are discarded during parsing and never reported; reports keep key names for context. The output contract lists stable fields and the limits of these outputs.

More documentation

The documentation index links current guides and references. The sandbox walkthrough is safe to try without connecting to a server. Experimental fixture-based work is grouped under labs; maintainer-only procedures are in maintainers/, with older 1.x material in archive/.

Learn more

• Pinning and drift checks
• Trust packet walkthrough and the MCP trust packet
• Adjusting permission findings
• Sandbox walkthrough using the examples/sandbox/ fixtures
• Output contract
• Documentation index

Experimental, fixture-based tools are documented in the labs. Maintainer procedures and project history live in maintainers/ and archive/.