NPMScan

Check npm maintainer blast radius

check_maintainer_blast_radius

Read-only

Given an npm username, lists the packages npm's maintainer: search index returns for that account and looks for a tight cluster of packages whose latest version was published within a short rolling window of each other — the shape of a compromised-account supply-chain attack, where a stolen credential is used on every package the account can publish to within hours (e.g. the September 2025 chalk/debug compromise, ~18 packages in ~2 hours). A large total package count is not itself a red flag; only a tight publish-time cluster is scored, weighted by its package count and combined weekly downloads/dependentsCount. Clusters mostly within one npm scope (a monorepo release) are dampened, and multiple clusters combine with diminishing returns. isCurrentMaintainer shows whether the account still maintains each package. avatarUrl is a proxied Gravatar image (null if no email is on record). Natural follow-up to check_maintainer_changes: call this with a newly added maintainer's username to see whether the same account touched other packages around the same time. Limitations: npm's search index can lag or omit packages; results are capped at 250 packages ranked by relevance, not recency (see resultsTruncated/totalPackagesFound); lastPublished reflects only each package's latest version. npmscanUrl is the account's npmscan profile; npmProfileUrl is its npmjs.com page.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	How many packages to list (default 50, max 250), most-downloaded first. Totals still cover every package found.
`maintainerUsername`	Yes	Exact npm username, e.g. "sindresorhus" — as shown at npmjs.com/~username. Not an email address, not a package name or scope.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	Yes
`clusters`	Yes
`findings`	Yes
`packages`	Yes
`riskTier`	Yes
`avatarUrl`	Yes
`npmscanUrl`	Yes
`totalScore`	Yes
`npmProfileUrl`	Yes
`packagesOmitted`	Yes	Packages left out of `packages` by `limit`; totals and scoring still include them.
`packagesReturned`	Yes
`resultsTruncated`	Yes
`clusterWindowHours`	Yes
`maintainerUsername`	Yes
`totalPackagesFound`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 6, 2026

addedInput schema / properties / limit

Added value: +{
+  "description": "How many packages to list (default 50, max 250), most-downloaded first. Totals still cover every package found.",
+  "maximum": 250,
+  "minimum": 1,
+  "type": "integer"
+}

addedOutput schema / properties / packagesOmitted

Added value: +{
+  "description": "Packages left out of `packages` by `limit`; totals and scoring still include them.",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "maintainerUsername",
-  "npmscanUrl",
-  "npmProfileUrl",
-  "avatarUrl",
-  "totalPackagesFound",
-  "packagesReturned",
-  "resultsTruncated",
-  "clusterWindowHours",
-  "packages",
-  "clusters",
-  "findings",
-  "totalScore",
-  "riskTier",
-  "note"
-]New value: +[
+  "maintainerUsername",
+  "npmscanUrl",
+  "npmProfileUrl",
+  "avatarUrl",
+  "totalPackagesFound",
+  "packagesReturned",
+  "resultsTruncated",
+  "packagesOmitted",
+  "clusterWindowHours",
+  "packages",
+  "clusters",
+  "findings",
+  "totalScore",
+  "riskTier",
+  "note"
+]

Changed2 schema fields changedSep 8, 2026

addedOutput schema / properties / npmscanUrl
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "maintainerUsername",
-  "npmProfileUrl",
-  "avatarUrl",
-  "totalPackagesFound",
-  "packagesReturned",
-  "resultsTruncated",
-  "clusterWindowHours",
-  "packages",
-  "clusters",
-  "findings",
-  "totalScore",
-  "riskTier",
-  "note"
-]New value: +[
+  "maintainerUsername",
+  "npmscanUrl",
+  "npmProfileUrl",
+  "avatarUrl",
+  "totalPackagesFound",
+  "packagesReturned",
+  "resultsTruncated",
+  "clusterWindowHours",
+  "packages",
+  "clusters",
+  "findings",
+  "totalScore",
+  "riskTier",
+  "note"
+]

Changed2 schema fields changedSep 5, 2026

addedOutput schema / properties / avatarUrl

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "maintainerUsername",
-  "npmProfileUrl",
-  "totalPackagesFound",
-  "packagesReturned",
-  "resultsTruncated",
-  "clusterWindowHours",
-  "packages",
-  "clusters",
-  "findings",
-  "totalScore",
-  "riskTier",
-  "note"
-]New value: +[
+  "maintainerUsername",
+  "npmProfileUrl",
+  "avatarUrl",
+  "totalPackagesFound",
+  "packagesReturned",
+  "resultsTruncated",
+  "clusterWindowHours",
+  "packages",
+  "clusters",
+  "findings",
+  "totalScore",
+  "riskTier",
+  "note"
+]

AddedSep 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description goes well beyond them: it explains the scoring model (cluster weighted by count and downloads, dampened for single-scope monorepos, diminishing returns for multiple clusters), discloses hard limitations (index lag, 250-package relevance-ranked cap, resultsTruncated/totalPackagesFound, lastPublished only covers latest version), and interprets output fields.

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 the core action and the attack pattern it detects, then limitations. Every sentence carries information, though the density is high and some field explanations (avatarUrl proxying) are marginal for tool selection.

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?

For a complex heuristic-scoring tool, the description is thorough: it defines the detection model, the caveats that affect interpretation, and the auxiliary output URLs. An output schema exists, yet the added interpretation of scores and truncation flags is exactly the context an agent needs to act on results.

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% and both parameters are self-documenting, so baseline is 3. The description adds real value by clarifying that results are 'capped at 250 packages ranked by relevance, not recency' and that the limit is 'most-downloaded first' while totals still cover everything found — semantics the schema alone does not convey.

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 ('lists the packages npm's maintainer:<username> search index returns') plus the analytical goal (detecting a tight publish-time cluster). It explicitly distinguishes itself from the sibling check_maintainer_changes by naming it as the natural predecessor, so an agent can route between them without opening schemas.

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?

Gives clear context for use ('Natural follow-up to check_maintainer_changes: call this with a newly added maintainer's username') and names the alternative tool and trigger condition. It stops short of explicit when-not-to-use guidance, but the operational trigger is unambiguous.

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

All NPMScan tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?