mcp-supply-audit

Overview Schema Source Related Servers Discussions Admin

Audit Server

audit_server

Read-only

Runs all applicable supply-chain checks on one MCP server and returns a single merged report, so you can answer whether that server is safe to install.

Instructions

Run every check that applies to one MCP server and return one merged report.

Use when: any "is this MCP server safe to install?" question. Prefer another tool when: the user wants only one specific check.

For a registry name: audit_registry_entry, then audit_package for each pypi or npm package the entry lists (at most 3, at the listed version), and check_typosquat on the registry name and each package name. For a package name: audit_package and check_typosquat; the registry checks are recorded as skipped (a package name does not identify a registry entry). With tools_snapshot (JSON text only; an object is rejected), scan_tool_definitions too. Checks run concurrently under a 30 s deadline; a check that fails or does not finish is a skipped check naming it, and the rest of the report still returns. Coverage, findings and locations are prefixed with the sub-check name. The limits of each sub-check apply (see audit_package, audit_registry_entry and check_typosquat). Findings are indicators, not verdicts, and a report with no findings is not proof of safety. coverage lists the checks that ran and those skipped, with reasons.

Input Schema

Name	Required	Description
`name`	Yes	A registry server name (<namespace>/<name>, case-sensitive), or a package name together with ecosystem.
`version`	No	Package version, package names only. Empty: the latest.
`ecosystem`	No	Required for a package name; empty for a registry name.
`tools_snapshot`	No	Optional tools/list result, {"tools": [...]}, as JSON text (not an object), to scan as well. Max 1 MiB, nesting depth 64.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the readOnlyHint/openWorldHint annotations: concurrent execution under a 30 s deadline, failure or timeout degrading to a named skipped check while the rest of the report still returns, coverage listing ran/skipped with reasons, and the caveat that findings are indicators not verdicts. It also warns that tools_snapshot must be JSON text and an object is rejected, which prevents a predictable invocation error.

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

Conciseness4/5

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

Front-loaded with purpose, then a labeled 'Use when' / 'Prefer another tool when' pair before the procedural detail, so the agent can stop reading early. The orchestration paragraph is dense and long-sentenced, but each clause carries information the agent needs to assemble a correct multi-step audit.

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

Completeness5/5

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

An output schema exists, so return shape need not be described, yet the description still explains what coverage contains and how partial failures surface. For a four-parameter aggregator with a deadline and degradation behavior, nothing an agent needs to call it correctly is missing.

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%, so the baseline is 3; the description adds real orchestration semantics on top, such as auditing at most 3 packages at the listed version and recording registry checks as skipped when only a package name is given. It mostly reinforces the schema's own wording for tools_snapshot and ecosystem rather than adding new syntax detail.

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?

States a specific verb and resource: 'Run every check that applies to one MCP server and return one merged report.' The 'every check' / 'merged report' framing immediately separates it from the single-check siblings (audit_registry_entry, audit_package, check_typosquat, scan_tool_definitions).

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?

Explicit when-to-use ('any "is this MCP server safe to install?" question') and explicit when-not ('the user wants only one specific check'), plus concrete orchestration recipes for registry names vs package names, including the skipped-registry-check case. Nothing is left to inference about when this aggregator is the right choice.

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

Deploy Server