Keep your MCP server package maintained

What we checked

We looked at your package’s publish history to gauge whether it’s actively maintained. The signal passes when there’s been a recent release. Otherwise:

Why it matters

Maintenance is a leading indicator, not busywork. An unmaintained package is where unpatched vulnerabilities pile up, where dependency advisories go unanswered, and where attackers look for a takeover target precisely because nobody’s watching. A steady release cadence, even small releases, signals that someone is still home and that a security fix would actually ship.

It’s a signal, not a verdict, and the package rubric weights it as one: a small, finished tool can be stable rather than abandoned. But for the median package, recency correlates strongly with being safe to depend on.

How recently must I publish to count as maintained?

There’s no magic number you have to hit; we’re looking for evidence that the package is still tended, not a specific date on the calendar. As a reference point for what “active” tends to mean across the industry, the OpenSSF Scorecard Maintained check awards its top score for roughly a commit a week over the previous 90 days. Small, routine releases (a dependency bump, a docs fix) are enough to read as maintained; a long, silent gap (well over a year without a release) is what tips a package into reading as stale.

How to fix it

Keep a visible cadence and keep dependencies current:

• Publish regular releases, even small ones: a dependency bump or a docs fix is a real release.
• Keep dependencies current so security updates flow through (pair this with patching known vulnerabilities).
• Automate releases so cutting one is cheap. A tag-triggered workflow removes the friction that lets packages drift:

name: release
on:
push:
  tags: ["v*"]

permissions:
contents: read
id-token: write  # enables npm provenance attestations

jobs:
publish:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
        registry-url: https://registry.npmjs.org
    - run: npm ci
    - run: npm publish --provenance --access public
      env:
        NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

My version is deprecated

A deprecated version scores 0 on maintenance however recently the package was published. The publisher has told everyone installing it to stop, so it isn’t a version anyone is maintaining. We read the flag for the exact version your registry entry names; a deprecated older version doesn’t count against a newer one.

• If the version was superseded, publish a supported release (if there isn’t one already) and point your MCP registry entry at it.
• If the deprecation was a mistake, remove it on the registry. For npm, deprecating with an empty message clears it:

npm deprecate my-package@1.2.3 ""

How we re-check

We re-read your publish history on our next crawl. Once a recent, correctly-dated release is visible, the signal flips to a pass on the following score refresh.

Give this to your AI

Paste this into Claude Code (or any coding agent) from inside your server's repository. It states the failing signal, the outcome we re-check for, and the format the fix has to take.

Context: this repository publishes an MCP server. VerifyMCP's maintenance
check failed, which means there's been no recent release for long
enough that the package reads as unmaintained, the latest release
carries a timestamp in the future, or the version being scored has been
marked as deprecated on the registry.

Goal: a recent, correctly-dated, non-deprecated release is visible in
the publish history, so the next crawl records it.

Do this:
1. Check your package's publish history on the registry to see which
   case applies.
2. If stale: if there is real, unreleased work (dependency bumps, fixes,
   docs), cut a genuine release for it. If the project is instead
   intentionally finished and stable, ask me before forcing a release
   just to move the needle, the rubric treats a small, finished tool as
   a legitimate exception, not a defect.
3. Add a tag-triggered release workflow (push a `v*` tag, publish from
   CI) so future releases are cheap and the cadence doesn't drift again.
4. If future: check the system or CI runner clock and your release
   pipeline's timestamp handling, fix the actual source of the bad
   timestamp, then cut a fresh release with a correct date.
5. If deprecated: find out why the version was deprecated (the
   registry shows the deprecation message). If it was superseded,
   prepare a supported release and update the MCP registry entry to
   point at that version. If the deprecation was a mistake, tell me:
   removing it is my call.

Rules:
- Never run the publish command (`npm publish`, `twine upload`, `dotnet nuget
  push`, `cargo publish`, a release tag that triggers one) yourself. A
  published version is permanent and notifies every downstream consumer:
  prepare the change, show me the diff, and let me publish it.
- Never run `npm deprecate` (with or without a message) yourself, whether
  to add a deprecation or to remove one. It changes what every consumer
  is told about that version: tell me the command and let me run it.
- Never backdate, forward-date, or otherwise hand-edit a release
  timestamp to fake recency; fix the clock or pipeline that produced it.
- Never publish a release whose notes or version bump misrepresent what
  changed, an empty tag pushed purely to trip this check is not a real
  release.
- Ask me before deciding whether the project needs new work or is
  genuinely done.

Report back: which case applied, the release you published (or the clock
fix you made), and where I can see the corrected publish date on the
registry.

Reference: https://verifymcp.io/docs/packages/maintenance