# "Our MCP directory said \"active\". The publisher had deprecated it five days earlier." > Source: > Published: 2026-10-29 13:41:18+00:00 I run ProtocolProbe, a directory of facts about every server in the official MCP Registry: each server gets a page, read from public records (the registry, npm, PyPI, GitHub), with a date on every fact. A publisher emailed us. They had renamed their server, marked the old registry entry as deprecated, and added a message pointing to the new name. Our page for the old entry still said **active**. I told them it would update on our next daily run. That was wrong. This post is about why, and what we changed. Our daily job pulls the full registry list, compares it with yesterday's, and loads what changed: new servers, new versions, removed servers. For those, it re-reads the package and repository facts the same day. The publisher's change was none of those. The registry lets a publisher change an entry's **status** (active → deprecated) and its **status message** without publishing a new version. Same version, different status. Our job noticed it: it counted it as a "metadata-only" change. It just never loaded it. The page kept the old status, and the run still finished with `ok`. One report can be a coincidence, so we compared every stored record with the registry list of that day, field by field (read-only, 51,834 servers): | | mismatches | |---|---| | servers missing / extra | 0 / 0 | | version | 0 | | status (stored `active` , registry`deprecated` ) | **53** | | status message | 60 | So the parts the job was built for were exact, and the gap was precisely the case it skipped: entries deprecated by their publishers that we still showed as active. Our own record check "deprecated in the registry" gave the wrong answer for all of them. The registry is the source of truth for a few fields: status, status message, published and updated dates. Now, after every daily load, the job compares those fields for **all** servers with the registry list and patches the ones that differ at the same version: First run: **59 servers patched** (some had changed since the count above). A second comparison right after: **0 mismatches** across 52,138 servers. The deeper problem was not the missing field. It was that the job reported success without looking at what visitors see. So the job now ends with a live check: after the pages are refreshed, it takes a small fixed sample of the day's changed servers (new, new version, status patched) and opens their **public pages**. We first tried reading our own public API instead. It was the wrong thing to check, for two reasons we found by reading our code: Each server page now carries a small machine-readable marker in its head: version, status, a short hash of the status message (never the message itself), and the snapshot date. The job compares that with what it loaded. While checking this, we found a quieter version of the same problem on our leaderboards. They said "facts checked 2026-10-29". That was the newest date among the records, which meant the servers that changed that day. Most stars and download counts behind the ranking had been read days earlier. The page now shows the range: "facts checked 2026-10-24 to 2026-10-29". We measured it. We re-read the free facts (npm/PyPI, OSV, GitHub) of 1,729 servers that had **not** changed in the registry, a 1/30 slice of the catalogue. It took about 14 minutes and about 1,200 GitHub API requests. **614 of them (35%)** had at least one fact that had changed since our last read: None of these show up as a registry change. We built a daily rotation that re-reads such a slice every day, so every server is re-read at least monthly. It is switched off until we have watched a few normal runs of the new checks. `ok` for days while pages were wrong. Every change the job records is public, by day, at [protocolprobe.com/mcp/changes](https://protocolprobe.com/mcp/changes), and in a free API with no key ([/docs/api](https://protocolprobe.com/docs/api)). If you run an MCP server and something on its page looks wrong, [/operators](https://protocolprobe.com/operators) says how to tell us.