Four archived reference servers still pull ~214k installs/week, and their npm deprecation message points at npm support rather than a replacement

Measured today (2026-09-09), live from api.npmjs.org:

All four are deprecated on npm and live in modelcontextprotocol/servers-archived, archived with its last push on 2025-05-28. That README states plainly:

NO SECURITY GUARANTEES ARE PROVIDED FOR THESE ARCHIVED SERVERS.

That decision is clear and I am not questioning it. The gap is that the decision is not reaching the people still installing these — 214k times a week.

Why the deprecation notice isn't carrying the message

Every one of the four carries npm's generic default text:

npm warn deprecated @modelcontextprotocol/server-postgres@0.6.2:
Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.

npm prints this on every single install, which makes it the one channel that already reaches all 214k. But it currently sends people to npm's support desk, which cannot help with an MCP question, and it names no replacement and no security status.

Someone installing server-postgres today sees a generic "no longer supported" line, has no reason to think it means unmaintained, archived, and explicitly outside any security guarantee, and carries on — with a server holding database credentials.

Two things that don't line up

1. There is no replacement to migrate to for any of the four. modelcontextprotocol/servers/src currently holds everything, fetch, filesystem, git, memory, sequentialthinking, time. Postgres, GitHub, Puppeteer and Brave Search have no successor there. So a user who correctly reads the warning and goes looking for guidance finds none, which is a plausible reason the install numbers haven't moved.

2. There is no route to report anything about them. modelcontextprotocol/servers/SECURITY.md says this repository is not eligible for vulnerability reporting and to use the relevant SDK repo — but these are servers, not SDKs, and their own repo is archived and read-only. If someone finds a problem in server-postgres tomorrow, there is nowhere for it to go. This matters more for these four than for the rest of the archive: postgres and github are the two that hold credentials.

Suggested fix

Rewriting the npm deprecation string is a single command per package, needs no release, and lands on every future install immediately:

npm deprecate @modelcontextprotocol/server-postgres@"*" \
  "Archived and unmaintained; no security guarantees. See https://github.com/modelcontextprotocol/servers-archived"

Even that much would turn "contact npm support" into something a user can act on. If a recommended alternative exists for any of the four, naming it there would do more than anything else available.

A line in the main README pointing at the archive, and a sentence in SECURITY.md stating where (or that) reports on archived servers are accepted, would close the rest.

Happy to open a PR for the README and SECURITY.md wording if that's useful — the npm side needs publish rights, so that one can only come from a maintainer.

For context on why I was measuring this: I maintain a scanner for MCP server configurations, and unpinned or unmaintained server packages are one of the things it flags. These four kept coming up with install counts that didn't match their archived status, which seemed worth reporting rather than just detecting.

Start with the archived repository README and the main repository's SECURITY.md, then review how the four npm packages are currently deprecated. Update the documented archive and reporting guidance, and confirm the final wording for npm deprecation notices with a maintainer who has publish rights. Done means users receive actionable archive, security, and replacement guidance where available.