NPMScan

Check an npm package for maintainer/ownership red flags

check_maintainer_changes

Read-only

Reconstructs a package's maintainer-change history straight from the npm packument — every published version carries the maintainers-list SNAPSHOT as it stood at that publish plus who actually ran npm publish (_npmUser), so diffing consecutive snapshots in publish-time order recovers exactly who was added or removed and when, with no extra API calls. Flags: (1) a maintainer added recently who then published a release shortly afterward on a package with real prior history — the account-takeover/hostile-handoff shape behind incidents like ua-parser-js, event-stream, and the 2025 chalk/debug ('qix') compromise; (2) a full, sudden replacement of the entire maintainer list; (3) a long-standing maintainer quietly dropped from the list; (4) a maintainer-list change that happened on npm's site AFTER the latest release — not yet tied to any published version, which is the more urgent case since it means access changed hands but nothing has shipped with it yet. Also cross-checks the declared GitHub repository: whether it still resolves to the same owner/name (a transfer/rename), whether it's reachable at all, and whether the latest npm release landed long after any real push activity there. Use get_package/check_package_provenance first for the package's general health and publish-integrity signals; use this specifically for the 'who controls this package, and did that change recently' question.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Exact npm package name, e.g. "lodash" or "@scope/name"

Output Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`history`	Yes
`findings`	Yes
`riskTier`	Yes
`npmscanUrl`	Yes
`repository`	Yes
`totalScore`	Yes
`lookbackDays`	Yes
`currentMaintainers`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), it explains the exact mechanism — diffing maintainer snapshots from each published version in publish-time order — and states there are no extra API calls. It also warns about the more urgent case of changes after the latest release, which is valuable behavioral context.

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 longer than average, but the first sentence front-loads the method and each of the four flags earns its place. It remains focused and structured, though the long first sentence and incident-name examples add some nonessential color.

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 single-parameter read-only tool with an output schema and no nested objects, the description covers what information the tool derives, how it derives it, and how to interpret the red flags. Nothing critical for invoking it correctly is missing.

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?

With only one parameter and 100% schema description coverage, the schema already fully documents 'name' as an exact npm package name with examples. The description adds no parameter-specific detail, but none is needed because the schema covers it.

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 names a specific action ('reconstructs a package's maintainer-change history') and a concrete resource ('npm packument'), and enumerates four explicit red-flag shapes it detects. This clearly separates it from siblings like analyze_install_script or check_package_provenance without needing their 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?

It says what the tool is for: checking ownership/maintainer red flags, including both publish-tied changes and post-release list changes, which tells an agent when to invoke it. It does not explicitly list exclusions or name sibling alternatives, so it stops short of full when/when-not guidance.

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

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.3/5.0

Disambiguation4/5

Each tool targets a distinct workflow—install script analysis, transitive dependency resolution, batch OSV queries, provenance verification, CVE lookup, advisory browsing, package metadata, exact-version checks, single-package vuln checks, and search. The only mild overlap is that several get_/query_ tools return vulnerability data, but the descriptions clearly delineate when to use each.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: get_package, query_vulnerabilities, analyze_transitive_dependencies, check_package_provenance, etc. There are no mixed casing styles or vague verbs, making the set highly predictable.

Tool Count5/5

10 tools is well-scoped for an npm security scanning server. Each tool earns its place by covering a distinct facet of the domain without redundancy or bloat.

Completeness4/5

The surface covers package discovery, metadata, exact-version vulnerability checks, batch scanning, transitive graph analysis, install-script heuristics, provenance, advisories, and CVE enrichment. Minor gaps remain—e.g. no full tarball code review and maintainer-history red flags are explicitly out of scope—but core agent workflows are covered.

Resources

Need Help?