Stale package

What mcp-scan saw

The package scanner fetched registry.npmjs.org for the package and read time.modified, then computed the gap to now in 30-day months. More than six of those months pushes this finding. It only runs for npx and npm servers where a package name resolves from the args.

Why it fires

time.modified moves on any registry write, so six months without one means no release, no dependency bump, and no security patch in that window. For a package that runs with your filesystem and your keys, an unpatched transitive dependency is the concrete risk, which is why this is graded HIGH rather than as an informational note.

When this is a false positive

• A small, finished package with no dependencies has nothing to release. Age is not decay when there is no surface to patch.
• The threshold uses 30-day months, so the real boundary is 180 days rather than six calendar months. A package published seven calendar months ago and one published 181 days ago are graded the same.
• time.modified reflects registry writes, not repository activity. A package with an active repository that simply has not cut a release reports as stale.
• A package that was recently deprecated gets its time.modified bumped by the deprecation itself, which suppresses this finding for the package you most want flagged.

How to fix it

1. Check the package's repository for recent commits. Registry silence and repository silence are different signals and only the second one matters.
2. Look at whether the package has dependencies at all. A zero-dependency package with no network or filesystem reach can be old and fine.
3. If it is genuinely unmaintained, find a maintained replacement, or vendor the code into your own repository where you can patch it.
4. If you keep it, pin the exact version in the args so the behaviour cannot change under you, and note the decision.
5. To suppress, add 'stale-server' to suppressRules in .mcp-scan.json, or add the server's config key to .mcp-scan-ignore.