Feature request: re-check published entries periodically (more than 1 in 8 have a problem the registry doesn't catch)

Start with internal/validators/registries/npm.go, pypi.go, and ValidateUpdateRequest, then trace ValidatePackage to understand the existing publish-time checks. Identify the registry’s job or background-worker entry point and the storage used for registry metadata, noting the overlap with issues #93, #1579, and #1484. Done requires a maintainer to choose the validation cadence and failure-status policy, implement and test periodic rechecks, and record results without automatically deleting entries.

Summary

I measured every latest entry in the registry (38,977 entries from 23,016 publisher namespaces, registry snapshot 2026-10-04) against what npm, PyPI and GitHub reported on 2026-10-06. 5,435 entries (13.9%; 3,169 publisher namespaces, 13.8%) have at least one problem the registry doesn't catch — most commonly a repository link that isn't publicly reachable, or a listed package version that is withdrawn upstream or can't be installed. Part of that count is a design choice rather than a problem (see the websiteUrl note below); setting that part aside, the figure is still at least 5,192 entries (13.3%).

This is not a security report, and it isn't a criticism of publishers: things change upstream after an entry is published, and some checks were never part of publishing. The registry's validation is good at publish time; it just has no timer that runs it again. Below are the numbers, what the code does, and some small proposals.

The registry has changed since my snapshot, so exact counts today will differ. I have not re-pulled it for this issue.

Disclosure: I built ProtocolProbe, a free directory that reads the registry's public data. This issue is about the registry, not about my project.

Related, already open (I found these after measuring): #93 (remove entries that reference invalid packages, with a check "at least ~daily"), #1579 (active entries with neither remotes nor packages), #1484 (repository URLs that point at renamed or transferred repositories). Discussions #1547 and #1591 measured remote endpoints; this covers package and repository records instead, so the counts are not comparable. This issue adds whole-registry numbers across several kinds of drift and a way to record them without deleting anything.

What the registry checks (read from source at c384c4b, re-read at HEAD 11b7b0e, 2026-10-11)

• At publish, it checks the exact listed version. internal/validators/registries/npm.go fetches /{identifier}/{version} and requires a 200 plus a matching mcpName; pypi.go fetches /pypi/{identifier}/{version}/json and requires the mcp-name: token. This has been the case since the validators were added in September 2025. It runs only when ENABLE_REGISTRY_VALIDATION is on (default true; I can't see production's setting).
• It runs again only when a publisher edits an entry. UpdateServer calls ValidateUpdateRequest, which repeats the package ownership check (skipped for deleted entries). I found no timer, cron or background job that validates entries on a schedule. An entry nobody edits is checked once.
• repository.url is checked for format only (IsValidRepositoryURL, a regular expression), never fetched.
• The schema requires name, description and version — neither packages nor remotes. The docs describe entries with only a websiteUrl as a supported "custom installation path".

What I found (whole registry, no sampling)

Every percentage below uses the same base — all 38,977 entries, or all 23,016 publisher namespaces — so no row can exceed the total. Each row's own subset is given in the fourth column for context.

The 243 entries that have a websiteUrl follow the documented custom-installation pattern, so they may be intended. The 216 that have neither a way to run nor a page to read are the ones a client can do nothing with. The "any of the below" row counts all 459; without the 243 it is at least 5,192 (13.3%), because removing 243 entries cannot lower the total by more than 243.

All 157 entries whose listed version doesn't exist were published after the existence check was introduced — so, if validation was enabled (it is by default), they existed at submission and were removed afterwards. For withdrawn versions and archived repositories I can't tell when the change happened: npm/PyPI don't record when a version was deprecated or yanked, and GitHub doesn't expose when a repository was archived. The registry doesn't check either, at publish or later.

Publisher-supplied deprecation messages for the 663 withdrawn versions, grouped by publisher namespace: renamed to another package (89), backing service shut down (16), npm staff "no longer supported" notice (24), publisher-declared security issue (12), plus discontinued / upgrade-advised / moved distribution.

Proposals

1. Re-run the existing package validation on a schedule (e.g. weekly; #93 suggests daily), reusing ValidatePackage. On failure, don't silently delete — record it, e.g. a _meta field such as lastVerifiedAt + verificationStatus: ok | version-missing | package-missing, so clients can choose what to do.
2. Surface upstream withdrawal state. When the listed npm version is deprecated or the PyPI release is yanked, expose that (with the upstream message) in _meta. Registry-driven clients currently install a withdrawn version with no signal, because version must be exact.
3. Optionally check repository.url reachability at publish and during re-validation, or mark it as unverified.
4. Treat "no packages, no remotes, no websiteUrl" as incomplete (216 active entries in my snapshot) — a distinct status or a publish-time warning — and leave the documented websiteUrl-only pattern alone.

Happy to share the full dataset and method (one record per entry; npm/PyPI/GitHub/OSV sources, every field marked declared / undeclared / not-applicable with a reason), and to help with an implementation. The dataset is archived with a DOI under CC BY 4.0: https://doi.org/10.5281/zenodo.23386799. The report with each figure's source and date is at https://protocolprobe.com/mcp/reports/registry-vs-reality.

Method notes

• Registry snapshot 2026-10-04 (full pagination, 131,427 version rows, one latest row per name); npm, PyPI and GitHub lookups on 2026-10-06.
• npm/PyPI checks use the exact version the registry lists, parsed with semver / PEP 440.
• A 404 on a repository link means missing or private; I don't distinguish the two, and I haven't separated renamed repositories from missing ones (see #1484).
• Rate-limited lookups were retried and are never counted as missing data.
• Counts are given per entry and per publisher namespace, because a few namespaces publish hundreds of entries and would otherwise dominate.
• I did not run or call any MCP server for any of this; everything comes from the registry and public package records.
  Drafted with help from Claude (AI); the data, method and checks are mine and I've reviewed every number.