Skip to main content
Glama

NPMScan

by io.github.salemalem

Find every package an npm maintainer account touches, and flag a tight publish cluster

check_maintainer_blast_radius
Read-only

Given an npm username, finds every package npm's own maintainer: search index currently returns for that account (registry.npmjs.org's /-/v1/search — the same reverse lookup npmjs.com's own site search uses; the public registry API has no dedicated 'list packages by maintainer' endpoint otherwise) and looks for a tight cluster of packages whose LATEST version was published within a short rolling window of each other. That's the shape of a compromised-account supply-chain attack: a stolen or phished credential doesn't get used on one package, it gets used on every package that account can publish to, usually within hours — the exact pattern behind the September 2025 chalk/debug ('qix') compromise, which hit roughly 18 packages within about 2 hours. A large total package count is NOT itself a red flag — many legitimate maintainers publish hundreds of packages over a career — only a tight publish-time cluster is scored, weighted up by how many packages it includes and by their combined weekly downloads/dependentsCount, since a burst touching a handful of near-zero-download packages is a very different event than one touching something with billions of weekly downloads. A cluster where most of the packages share one npm scope (e.g. @docusaurus/*) is dampened, since that's the shape of a project's own monorepo doing one coordinated release, not a compromised account spread across unrelated packages — this is why a large official org account (e.g. facebook/fb) publishing several of its own monorepos still lands well below what a plain sum of its cluster count would suggest. Multiple distinct clusters on one account combine with diminishing returns (the single worst cluster counts in full; each additional one contributes half the previous one's weight), not a plain sum — an account that does many independent, legitimate coordinated releases over its lifetime should not accumulate an unbounded score purely from being prolific. avatarUrl is the same Gravatar image npmjs.com's own profile page shows for this account, derived from the email already public in the registry's own maintainer records but served from our own /api/avatar/:hash proxy rather than linking gravatar.com directly (null only if no returned package still lists an email for this exact username). Each returned package's CURRENT maintainer list is cross-checked against the queried username (isCurrentMaintainer), since access is often already revoked by the time this runs. Natural follow-up to check_maintainer_changes: when that tool flags a newly added or fully turned-over maintainer on one package, call this with that maintainer's username to see whether the same account touched other packages around the same time. Known limitations: npm's search index is a text-relevance index, not a guaranteed-complete/real-time reverse index (results can lag or omit edge cases); results are capped at one page (up to 250 packages, ranked by npm's own relevance/popularity scoring, NOT by recency) so a very large footprint may be truncated (see resultsTruncated/totalPackagesFound) and a real cluster outside that page could be missed; and lastPublished reflects only each package's latest version, not its full history.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maintainerUsernameYesExact 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
NameRequiredDescriptionDefault
noteYes
clustersYes
findingsYes
packagesYes
riskTierYes
avatarUrlYes
totalScoreYes
npmProfileUrlYes
packagesReturnedYes
resultsTruncatedYes
clusterWindowHoursYes
maintainerUsernameYes
totalPackagesFoundYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • 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"
+]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark the tool as read-only and open-world, and the description adds substantial behavioral detail beyond that: it names the exact npm search endpoint, warns that results are capped at 250 and may lag or be truncated, explains how current maintainer membership is cross-checked, and details scoring behavior such as popularity weighting and diminishing returns for multiple clusters. No contradiction with the annotations exists.

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?

The description is long but front-loaded and organized: it begins with the core operation, then explains the threat rationale, scoring behavior, and known limitations. Every section adds useful context, though some details like the qix compromise example and avatarUrl proxy explanation could arguably be trimmed or moved into the output schema without losing invocation guidance.

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?

Given the tool's complexity, the description is complete: it covers data source, limitations, truncation behavior, scoring semantics, output fields, and the natural relationship to sibling tools. The output schema exists, so the description does not need to enumerate return values, and it still names key output fields like resultsTruncated and totalPackagesFound where interpretation matters.

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%, and the schema already fully documents maintainerUsername as an exact npm username, not an email, package name, or scope. The description reinforces this by saying 'Given an npm username' and by explaining how the username is used in the maintainer search, but it does not add new constraints or examples beyond the schema. 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?

The description states a precise operation: given an npm username, enumerate packages via npm's maintainer search and detect tight publish-time clusters. It clearly names the underlying API source and the threat pattern it detects, and it distinguishes itself from related tools by positioning it as a follow-up to check_maintainer_changes.

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?

The description gives an explicit trigger condition: call this when check_maintainer_changes flags a newly added or fully turned-over maintainer. It also warns that a large total package count is not a red flag, preventing misuse of the tool as a volume metric, and explains the compromised-account scenario it is designed for.

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

All NPMScan toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Most tools have clearly distinct scopes, such as flat vs. transitive vulnerability checks and per-package vs. GitHub-repo audits. The main ambiguity is that several tools all ultimately report OSV/NVD findings or perform install-script risk checks, though the descriptions do draw clear boundaries and include cross-references to steer selection.

Naming Consistency5/5

Every tool follows a consistent lowercase snake_case verb_noun pattern, e.g. analyze_install_script, check_maintainer_changes, prioritize_remediation. The naming is predictable and makes the action and target of each tool immediately clear.

Tool Count3/5

At 22 tools, the surface is at the heavy end of the rubric and pushes beyond the typical 3-15 well-scoped range. The tools are individually purposeful and broad in coverage, but the count is high enough that an agent faces a large decision space and several workflows that overlap or compose in complex ways.

Completeness5/5

The set covers the full npm supply-chain assessment lifecycle: discovery, metadata lookup, vulnerability scanning, transitive dependency analysis, license checks, install-script analysis, maintainer and provenance checks, SBOM generation, dependency diffs, upgrade simulation, remediation prioritization, and alternative suggestion. There are no obvious dead ends or major missing operations for the stated domain.

Resources