Nine of 101 most-installed MCP servers are archived — what the maintenance signal looks like in 2026

Why maintenance is the only time-bomb axis

SkillAudit grades every Model Context Protocol server on six axes — security, permissions, credentials, maintenance, compatibility, and documentation. Five of the six grade the code that is in front of the engine right now. The sixth — maintenance — grades the absence of code that is not arriving. When we audit a repo, we read the GitHub API for three signals: the archived flag, the pushed_at timestamp, and the open-issue count. Each of those rolls up into a deduction against the maintenance axis, and the maintenance axis caps the overall grade just like any other axis (the methodology page documents the cap rules in full).

Here is the thing the maintenance axis catches that no static check ever will: a repo's score gets worse over time even if nobody changes a single line of code. A repo that scores 90 today on every code axis but has not been pushed to in 100 days will lose 10 points off maintenance in 80 days, and 30 points in 280 days, and become uninstallable under any reasonable install-gate policy in 365 days. The other five axes are static; this one is dynamic. It is also the axis that is hardest to game, because it requires actual ongoing engineering effort to keep — not a one-time fix you commit and forget.

That asymmetry is exactly what makes maintenance the killer feature of an install gate. A vendor can ship an A-grade MCP server today and be on the install shortlist next month; if they then archive the repo, the install gate catches that change at the next re-scan and removes the repo from the approved list automatically. Code-axis findings require manual root-cause work to fix; maintenance findings update themselves. The cost to the install-gate operator is one cron job every thirty days.

The remaining three sections name the four maintenance signals the engine fires on, with the corpus data behind each. None of the signals are subtle. Most of them are findings any developer could spot by clicking through to a repo and reading the sidebar. The reason the install gate exists is that every developer doing a manual install does not click through and read the sidebar — they install, the LLM uses the tool, the tool runs, and nobody knows the repo's status until something goes wrong. Codifying these signals into an automated gate is how teams scale past a single security engineer's bandwidth.

Signal 1 — Repository is archived

Signal 2 — No push to default branch in 365+ days

Signal 3 — Aging cliff (180–365 days)

Days-since-push distribution across the 101-corpus

The corpus is bimodal. Fifty-six of 101 repos pushed within the past week (median 3 days). The active end of the distribution is healthy and well-maintained. The other half is the long tail: 13 repos in the 30–90 day range, 9 in the 90–180 day range, and the 11 repos over 180 days that this post calls out individually. There is no soft middle — repos either get touched constantly (median 3 days) or they slide toward archive status. That bimodality is itself a useful install-gate signal: a repo that has been at 100+ days idle is more likely to keep getting older than to suddenly resume active development.

Signal 4 — Triage backlog (open-issue count)

Signal 5 (out-of-band) — No SECURITY.md disclosure file

The four-signal install-gate framework

Combining the four maintenance signals plus the SECURITY.md signal gives a deterministic policy for an automated install gate. The first two signals are unilateral rejects; the last two route to manual review. Run this as a 30-day cron job over your team's MCP server install list:

1. If archived: true, reject. No exceptions. A repo that has publicly declared itself dead cannot fix anything that is found in it. The install can be replaced with the maintainer's named successor (5 of the 9 archived repos in our corpus have one) or with an A-grade alternative from the install shortlist.
2. If days-since-push > 365, reject. A year of no activity is the engine's "functionally archived" cutoff. The four 365+ repos in our corpus would all be rejected by this rule; one of them (anaisbetts/mcp-installer) is not officially archived but should be treated as if it were.
3. If days-since-push 180–365, manual-review. The 70-cap maintenance axis means the overall grade is capped at C in this band; let the gate flag it for review and let a security engineer decide whether the repo's stability matters more than its maintenance velocity. For most use cases the answer is "fork it or pick a different repo"; for some pinned-dependency scenarios it is acceptable.
4. If no SECURITY.md AND any HIGH security finding, manual-review. The combination is the worst case for vulnerability disclosure — a real finding with no place to report it. The reviewer should either find an alternative or work with the maintainer to add a SECURITY.md before the install is approved.
5. Re-scan every 30 days. All four signals are time-dependent; the gate's value is in catching the day a repo flips from "active" to "archived" or "180 days idle" or "365 days idle." A monthly cron picks up these transitions before they propagate to production.

The full install-gate template — including the GitHub Action that gates new installs on the SkillAudit grade, the rollout calendar, and the four week-1 gotchas — is in the install-gate playbook post. This framework is the maintenance-axis counterpart: the playbook covers the code-axis policy, this post covers the calendar-axis policy.

Author checklist — how to keep your repo out of this list

1. If the repo is archived, redirect installers. Set the GitHub repo description to "DEPRECATED — see org/successor-repo" and add the same line to the README's first paragraph. Most package registries (npm, PyPI) will not stop installs from an archived GitHub repo, but the README banner means anyone clicking through sees the redirect. The five archived repos in our corpus that have a documented successor are doing this correctly; the four that do not should adopt it.
2. If the repo is at 90+ days idle, push something. A README typo fix, a dependency bump, an LICENSE-year update — anything that resets the push timestamp. The cost is minutes; the benefit is staying out of the 180-day WARN cliff and the 365-day HIGH cap. A repo that has nothing to commit because it is feature-complete is a healthy repo; the maintenance axis is asking you to demonstrate that by ongoing activity, not by a comment in the README that says "stable." Active maintenance shows up in the GitHub API; comments do not.
3. Ship a SECURITY.md. 30 lines at repo root naming a disclosure email and a coordinated-disclosure timeline. Lifts the docs axis from 90 to 100 on its own. If 84% of A-grade repos in our corpus would be perfect 100s but for this single missing file, you are unlikely to be different. A starter template is two paragraphs (your disclosure email + a 90-day coordinated disclosure window); the rest is optional. The file's main job is to exist so the GitHub UI surfaces a "Report a vulnerability" button to anyone who finds something.
4. Triage your backlog or document why you are not. A 100+ open-issue count is a soft signal but a real one. If the issues are duplicates and out-of-scope feature requests, close them with a one-line "won't fix, see CONTRIBUTING.md" — that closes the count and signals active triage. If they are real but you do not have time, pin a "maintenance status" issue at the top explaining the resourcing situation and what you will and will not work on. Either move drops the WARN finding once the count is below 100; both move re-establish the active-maintainer signal.
5. Re-run the audit. SkillAudit re-scans on demand; once your fixes are in, request a fresh scan and the new grade reflects the current GitHub state. The maintenance axis updates immediately because it is point-in-time on the API call.

Buyer checklist — five clicks before you install

If you are picking which MCP servers to install this week and the repo is not in our 101-corpus, run these five checks in five minutes per repo:

1. Is the GitHub archived banner showing? Top of the repo page, gray banner across the file list. If yes, find a different repo or use the maintainer's named successor.
2. Click the "commits" tab. When was the most recent push? If it is > 365 days ago, treat as functionally archived. If it is 180–365 days ago, fork the repo before installing — you will need to maintain it yourself.
3. Click the "issues" tab. How many open? If it is in the hundreds and the most recent push is > 90 days ago, the maintainer is no longer triaging — assume any disclosed vulnerability will not be patched.
4. Look for SECURITY.md. If absent, plan to disclose any findings via your own GitHub fork or your security team's process. Do not assume the maintainer will see a public issue.
5. Run a SkillAudit. The free tier covers public repos. The grade synthesizes all five signals plus the security / permissions / credentials / compatibility / docs axes into one letter band you can use in your install gate. Submit a repo to audit.

FAQ

Why grade maintenance at all? Isn't security what matters? Because the security axis grades a snapshot, and the snapshot ages. A repo that scores 90 on security today and is then archived will still score 90 on security in five years against the engine — but every CVE in its dependency tree, every protocol revision, every breaking change in the ecosystem will accumulate against it without remediation. The maintenance axis is the one that catches "code that was good last year and is now load-bearing legacy nobody owns." Grading code without grading the calendar is grading half the problem.

How is the 365-day threshold chosen? Calibration. We set the threshold at the point where a repo has missed (a) at least one Node major-version cycle, (b) one MCP protocol specification revision, and (c) approximately twelve monthly dependency-CVE waves. Above that point, the probability that the repo's installable state matches the world it was tested against drops sharply. We also tested 180-day and 540-day cutoffs against the corpus; 365 produced the cleanest signal-to-noise ratio (the 4 repos above it are unambiguously dead; the 7 in the 180–365 band correctly tag the "fork before installing" cases).

Will my repo be re-scanned automatically when I push? No — re-scans are on-demand, the same as the initial scan. The audit pages reflect the state of the repo at the commit hash named on the page. Click "request re-scan" on any audit page (or re-submit the GitHub URL on the home page) to re-run; the engine pulls the latest commit and re-renders. The grade typically updates within minutes.

What about repos that are intentionally feature-complete? They lose maintenance points the same as repos that are abandoned. The audit cannot distinguish "intentional stability" from "actual abandonment" — the GitHub API gives the same answer for both. The fix is to push something periodically (a README clarification, a dependency bump, a tag for a stable version) so the push timestamp stays current. A genuinely feature-complete repo can do this with one annual maintenance commit and stay clear of the 365-day cliff.

How does the maintenance axis interact with the surface-tier rubric? It does not. Surface tiering (production / installer / examples / benchmarks / scripts / test) applies only to the code-axes findings: security, permissions, credentials. Maintenance findings are tagged (meta) and deduct at full weight regardless of where in the source tree they would otherwise be — there is no "test-tier abandonment." The repo is either being maintained or it is not. See the methodology meta-checks section for the full rules.

What if the maintainer is on vacation? Or the project has a release schedule? Three months is a long vacation; the 90-day band's WARN finding is small (10 points off, no overall-grade effect) and disappears the moment the maintainer pushes again. The release-schedule case is a harder edge case for repos that publish quarterly — those will spend most of their time in the 30–90 day band, which the engine treats as healthy. Repos publishing on annual cycles will sit in the 180–365 day band; the install gate's 70-cap is the right policy for those (they are stable but slow-moving and a buyer should know that).

How does this list change in 30 days? If the install-gate's monthly re-scan rule is followed, the prediction is: 5 of the 9 archived repos will still be archived (the official-org ones), 1–2 of the 7 aging-cliff repos will cross into the 365+ band, and 2–3 new repos will join the 180–365 band as their push timestamps cross 180 days. The triage backlog list will shift slightly as issues get opened and closed. The SECURITY.md count is the slowest-moving — adding one is a 10-minute task and a 30-line file, but maintainers historically only do it when prompted by a finding. If the F-grades and anatomy posts succeed in prompting authors to ship them, the next-month re-count should drop.

Related reading

• Anatomy of an A-grade MCP server — five code patterns shared by the 19 — the code-axis counterpart to this post; the SECURITY.md statistic appears in both.
• 29 vendor-official MCP servers earned an F — every name, every file path — eight of the nine archived repos in this post overlap with the F-grade vendor list; this post's lens is "the maintainer stopped" while that post's lens is "the code is broken."
• Block 52 of 101 community MCP servers with one CI gate — the team-policy template that the four-signal framework above slots into. The install-gate playbook handles code findings; this post handles calendar findings.
• The MCP install shortlist — 19 community servers that earn an A — the buyer-side companion. Every repo on the shortlist passes all four maintenance signals plus the code axes.
• Engine v0.3 calibration delta — 22 grades moved when surface tiering shipped — the engineering record of the v0.3 calibration; surface tiering applies to code axes, not to maintenance.
• Methodology — meta-axis checks — the canonical rule documentation for maintenance and docs axes, including the cap thresholds.
• The public audit board — every grade in the 101-repo corpus, every finding linked.