Allows auditing npm package versions by querying npm registry metadata for package and version existence, deprecation state, install scripts, provenance, and declared repository, along with OSV.dev advisories and typosquat checks.
Allows auditing PyPI package versions by querying PyPI metadata for package and version existence, yanked state, provenance, publish recency, and declared repository, along with OSV.dev advisories and typosquat checks.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-supply-audit Is the MCP server modelcontextprotocol/filesystem safe to install?"
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.
Audits MCP servers as software artifacts: registry entries, packages, configs, tool definitions.
An MCP server. Static checks only. It never runs the code it inspects.
Status: pre-release, in development. Not yet published. Nothing here is a security guarantee.
Most MCP security scanners focus on tool descriptions. This project looks at the server as a supply-chain artifact: does the registry entry match its package and repo, is the name close to a popular one, what do the package version's own metadata and advisories say, and what does the config you are about to copy actually do.
Related MCP server: mcpaudit
Six tools, served over stdio by a FastMCP server (tool surface). All are read-only and take names or pasted text, never a path.
audit_server: runs the checks below that apply to one server (a registry name, or a package
name plus pypi/npm) concurrently under a 30 s deadline, and returns one merged report. A check
that fails or times out is listed as skipped; the rest of the report still returns.
audit_registry_entry: an MCP Registry entry's repository consistency with its packages, owner
match, package and version existence, ownership markers, status, and remote URLs (as text).
audit_package: one PyPI or npm package version's OSV.dev advisories, yanked or deprecated
state, install scripts (npm only), provenance, publish recency (PyPI only) and declared repository.
check_typosquat: whether a name is close to one in a dated reference list (curated PyPI and
npm names; for registry names, also names crawled from the MCP Registry).
scan_mcp_config: an MCP client config's servers, for unpinned runners, plain-http remotes,
hardcoded secrets, shell wrappers, broad paths, non-registry sources and risky env.
scan_tool_definitions: checks a tools/list snapshot for hidden Unicode, instruction-like
phrasing, cross-tool references, exfiltration phrasing, encoded blobs, and other indicators.
Outbound requests go only to registry.modelcontextprotocol.io, pypi.org, registry.npmjs.org and api.osv.dev.
Not on PyPI yet: these commands work once the package is published. Until then, run it from a source checkout.
For Claude Code, with uv:
claude mcp add mcp-supply-audit -- uvx mcp-supply-auditPinned to one version (uvx's package@version form):
claude mcp add mcp-supply-audit -- uvx mcp-supply-audit@0.1.0scan_mcp_config flags the first form in the configs it scans (CF001, unpinned package runner).
Run it from a checkout of this repository with uv:
cd mcp-supply-audit
uv syncThen point an MCP client at the mcp-supply-audit console script in that checkout. For Claude
Code:
claude mcp add mcp-supply-audit -- uv --directory /path/to/mcp-supply-audit run mcp-supply-auditFor clients configured with JSON (e.g. Claude Desktop's mcpServers):
{
"mcpServers": {
"mcp-supply-audit": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-supply-audit", "run", "mcp-supply-audit"]
}
}
}Then ask, for example, "Is the MCP server <namespace>/<name> safe to install?" and the client
can call audit_server. Read the report's skipped checks: a report with no findings is not proof
of safety.
Never executes a scan target. Static analysis and metadata only. No tool accepts a filesystem path.
Hostile input by default. Text from a target is sanitized, capped, and returned only as quoted
evidence under untrusted_text. Hidden characters are shown as visible \uXXXX escapes.
Deterministic rules, no LLM in detection. Results are reproducible and unit-tested.
Findings are indicators, not verdicts. Every report lists which checks ran and which were skipped, and states that no findings is not proof of safety.
Mapped to the OWASP MCP Top 10 (beta, v0.1), by ID.
Static checks cannot see runtime behavior. Audit and telemetry gaps, shadow servers, and context over-sharing are outside what this tool can detect.
Per-check limits: registry checks, package checks, typosquat checks, config checks.
No benchmark has been run yet.
uv sync
uv run pytest -q
uv run ruff check
uv run ruff format --checkTo report a vulnerability in this project, see SECURITY.md.
MIT
Check one PyPI or npm package version's supply-chain signals: known vulnerabilities (OSV.dev), yanked or deprecated state, install scripts (npm), provenance, publish recency (PyPI) and declared repository (PK001-PK006).
Use when: the user asks about a specific package (and version), e.g. one a config pins. Prefer another tool when: the user wants a full check of a server (audit_server).
Limits: large PyPI projects need an explicit version, because their project document exceeds the size cap used to resolve the latest. There is no install-script check for PyPI (build code is only in the sdist, which is never downloaded). npm version documents have no publish time, so recency is not checked for npm. Download counts, package age and owner history are not available. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | PyPI or npm package name. | |
| version | No | Exact version to audit. Empty: resolve the latest. | |
| ecosystem | Yes | pypi or npm. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint, it discloses substantial operational context: large PyPI projects require an explicit version due to a size cap, npm versions lack publish time so recency is skipped, PyPI has no install-script check, and download counts/age/owner history are unavailable. It also frames findings as indicators not verdicts and points to the coverage field for ran/skipped checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the cap description, then clearly labeled Use when / Prefer / Limits / caveat blocks; nearly every sentence carries unique information. The limits block is dense and long relative to the rest, but it is structured rather than rambling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter read-only audit with an output schema present, the description covers what is checked, what is deliberately not checked, ecosystem-specific gaps, and the interpretation caveat about findings. Nothing an agent needs to call it correctly or to caveat its answer is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains why an explicit `version` matters (large PyPI project documents exceed the resolution size cap) rather than just what the field is. The ecosystem/name semantics are already fully covered by the schema, so it doesn't go higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check one PyPI or npm package version's supply-chain signals') and enumerates the concrete checks (OSV vulnerabilities, yanked/deprecated, install scripts, provenance, recency, repo). It explicitly differentiates itself from the sibling audit_server, so an agent can pick it without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has an explicit 'Use when' clause (the user asks about a specific package/version, e.g. one a config pins) and an explicit 'Prefer another tool when' clause naming audit_server for full server checks. Both the selection and deselection conditions are stated, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an MCP Registry entry: declared repository URLs are consistent with its packages, the entry's owner matches its repository, its packages and versions exist, ownership markers, status (deleted, deprecated), and remote URLs (RG001-RG011).
Use when: checking a registry listing's consistency, status, ownership markers or remote URLs. Prefer another tool when: the user wants a full check of a server (audit_server).
Names are case-sensitive: copy the name exactly as the registry shows it; a name in another case is reported as not found. Remote and repository URLs are checked as text and never contacted. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | MCP Registry server name, <namespace>/<name>, e.g. io.github.zqvex-owner/zqvex-server. Case-sensitive. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint it discloses that remote and repository URLs are compared as text and never contacted — a material behavioral fact for an open-world tool — and frames findings as indicators rather than verdicts, with an explicit caveat that an empty report is not proof of safety. It also notes coverage lists which checks ran and which were skipped. The only shortfall is that it does not say where the registry data comes from or how fresh it is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then separates conditional guidance into labeled "Use when" / "Prefer another tool when" blocks, followed by caveats. The opening sentence is a long dash-delimited run-on list, but every sentence carries non-redundant information and nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with a full schema, annotations, and an output schema, this covers everything an agent needs: what is checked, when to use it instead of audit_server, the exact-case requirement, the non-contact behavior, the interpretive limits of findings, and the presence of a coverage field explaining skipped checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the <namespace>/<name> format and case sensitivity, so the baseline would be 3. The description adds operative meaning beyond the schema by stating that the name must be copied exactly and that a different case is reported as not found, which explains the consequence of getting the value wrong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Check an MCP Registry entry") and enumerates the concrete checks performed: repository URL/package consistency, owner vs repository, package/version existence, ownership markers, status, remote URLs, with rule IDs RG001-RG011. It explicitly contrasts itself with the sibling audit_server, so the agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains an explicit "Use when" clause naming the triggers (consistency, status, ownership markers, remote URLs) and a "Prefer another tool when" clause naming audit_server for full server checks. It also warns that names are case-sensitive and that a wrong-case name yields a not-found result, which is real routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Check whether a package or MCP registry server name is suspiciously close to a known MCP server or package name: edit distance, confusable characters, affixes, and scope or namespace changes (TS001-TS006).
Use when: the user asks whether a name looks like a known MCP server or package, or is about to install something by a name they typed or were given. Prefer another tool when: the name is one the user already trusts and has verified, or the user wants a full check of a server (audit_server).
The name is compared against a dated reference list, never live popularity data. The reference list (data/reference_names.json) is dated 2026-11-03 (its generated_at field, returned in each report as data_sources[].as_of) and has 55988 entries: 6 PyPI and 4 npm names, which are curated names only, and 55978 registry names, crawled from the MCP Registry plus curated ones. A name close to none of them is not shown to be legitimate: the list is incomplete by nature. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name, or registry server name for registry. | |
| ecosystem | Yes | pypi, npm, or registry (MCP Registry server names). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing that comparison is against a dated static reference list, never live popularity data, and by stating the list's as_of date, size, and per-ecosystem breakdown. It also correctly frames findings as indicators rather than verdicts and warns that no findings is not proof of safety, consistent with openWorldHint=false. Minor gap: the TS001-TS006 finding codes are cited but never explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose, then when-to-use, then when-not-to-use, then caveats, so an agent can stop reading early. The caveat paragraph is long and includes very granular figures (55988 / 6 / 4 / 55978) plus an unexplained TS code range, some of which could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers scope, caveats, and reliability limits thoroughly for a two-parameter read-only check, and the presence of an output schema relieves it of describing return values. It even flags that the report includes coverage and data_sources[].as_of, tying back to the reference list's dated nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents both parameters, including the enum values, so the baseline is 3. The per-ecosystem entry counts (6 PyPI, 4 npm, 55978 registry) implicitly signal how much coverage each ecosystem value carries, which is modest added meaning but not parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (check a package or registry server name) plus the exact signals examined: edit distance, confusable characters, affixes, scope/namespace changes. This is clearly narrower than the sibling audit_* tools, which check whole 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'Use when' trigger (user asks whether a name is suspicious, or is about to install a name they typed or were given) and an explicit 'Prefer another tool when' branch routing full-server checks to audit_server. Both the positive and negative cases are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an MCP client config (Claude Code, Claude Desktop, Cursor or VS Code) for unpinned package runners, plain-http remotes, hardcoded secrets, shell wrappers, broad filesystem paths, non-registry package sources and risky env entries (CF001-CF007).
Use when: the user is reviewing a config they have or are about to copy. Prefer another tool when: the user asks about one server's tools (scan_tool_definitions), or whether a pinned package is safe (audit_package).
Takes pasted text only, never a path; no config value appears in the report. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| config_text | Yes | The text of an MCP client config (JSON), max 256 KiB. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds genuinely new behavioral context: input must be pasted text, never a filesystem path; no config values are echoed into the report; findings are indicators not verdicts; an empty report is not proof of safety. The one gap is that the schema's 256 KiB limit is left to the schema rather than reinforced, but the safety and privacy semantics are unusually well disclosed for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then explicitly labeled sections for when to use and when to prefer alternatives, then caveats. Every sentence carries information, though the multi-line wrapping mid-sentence makes it slightly harder to scan than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return-value explanation is not required, yet the description still explains the coverage field and its skip reasons, which is the part an agent needs to interpret results honestly. Combined with the caveat that findings are indicators, nothing needed to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one parameter, so the schema does most of the work. The description still adds meaningful meaning by clarifying that config_text is pasted config content rather than a path, which is the most likely misuse of a single string argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Check') and resource ('an MCP client config'), names the client families covered, and enumerates the seven check categories (CF001-CF007) plus what they target (unpinned runners, plain-http remotes, hardcoded secrets). An agent can distinguish this from every sibling without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' guidance (reviewing a config the user has or is about to copy) and explicit 'Prefer another tool when' routing to scan_tool_definitions and audit_package with the exact conditions that select them. Both inclusion and exclusion criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a server's tool definitions (a tools/list snapshot) for poisoning indicators: hidden Unicode, instruction-like phrasing aimed at the model, references to other tools, exfiltration phrasing, encoded blobs, overlong descriptions, free-text parameters that invite conversation content, and duplicate names (TD001-TD008).
Use when: the user has a server's tool list (pasted JSON) and wants it checked. Prefer another tool when: the user only has a package or registry name, or wants a full check of a server (audit_server, which also takes the snapshot).
Takes pasted JSON text only (an object is rejected), never a path; nothing is fetched. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| snapshot | Yes | A tools/list result, {"tools": [...]}, as JSON text (not an object). Max 1 MiB, nesting depth 64. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, it discloses that nothing is fetched, that only pasted JSON text is accepted (an object is rejected, never a path), and that findings are indicators rather than verdicts with a no-findings result not constituting proof of safety. The coverage field behavior (checks run vs. skipped, with reasons) is also described, which the output schema alone would not make meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and scope are front-loaded, then the when/when-not routing is presented in a scannable parallel structure, followed by input constraints and result caveats. The enumerated indicator list is long but every item is a concrete check name, so no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter, an output schema, and annotations covering the safety profile, the remaining burden is input format and interpretation of results, both of which are addressed. An agent has everything needed to call this correctly and to caveat its findings appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already states the JSON-text-not-object constraint plus the 1 MiB / depth-64 limits, so most of the description's input guidance is reinforcement. It does add the operationally useful fact that a path is never accepted and nothing is fetched, which the schema does not say.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Check a server's tool definitions (a tools/list snapshot)') and enumerates the exact indicator classes scanned (hidden Unicode, instruction-like phrasing, exfiltration phrasing, encoded blobs, duplicate names, TD001-TD008). This is clearly distinguishable from siblings like audit_package or check_typosquat, which operate on different inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit 'Use when' condition (user has pasted a tools/list JSON) and an explicit 'Prefer another tool when' condition (only a package or registry name, or a full server check), naming audit_server as the alternative and explaining the differentiator. Nothing about tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0audit_packageaudit_registry_entryaudit_servercheck_typosquatscan_mcp_configscan_tool_definitionsScored across 6 tools
Each tool targets a distinct input artifact: a registry listing, a tools/list snapshot, a package name, a client config, a name for typosquat comparison, or the aggregate server audit. The descriptions explicitly state when to prefer another tool, and audit_server's overlap with the individual checks is disambiguated by its 'prefer another tool when the user wants only one specific check' guidance.
All names are lowercase snake_case with a verb_noun shape, so the pattern is predictable. The mix of audit_ (composite analysis), scan_ (pattern detection over pasted text) and check_ (single yes/no question) is meaningful rather than arbitrary, though three different verbs is a minor deviation from a single consistent verb.
Six tools map cleanly onto the five distinct supply-chain inputs plus one aggregate entry point, with no redundant members. Each tool earns its place and the count is well within a comfortable range.
The surface covers registry entries, package metadata, typosquatting, tool-definition poisoning, client configs, and an aggregator that composes them with documented limits and skipped-check reporting. Minor gaps exist around server runtime/behavioral auditing and bulk multi-server sweeps, but these are outside the stated static-audit scope and are workable around.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Audit your MCP servers for poisoned tools and leaked secrets, and check AI-generated code for flaws.
Audit MCP servers for tool poisoning and shadowing. Scan a remote server by URL or paste its tools.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.