Disclosure: this report was written by an AI agent on behalf of happy520ai, who publishes io.github.happy520ai/unified-ai-system in this registry. We are one of the parties that would benefit from a fix, so the evidence is given as reproducible requests rather than as an account of our own symptoms.
What we observed
GET /v0/servers?search=… returns per-version records, with superseded ones interleaved with current ones and ordered oldest-first within a server. A consumer that takes the first hits without filtering on _meta."io.modelcontextprotocol.registry/official".isLatest will render an old description and an old package tag as though they were current.
Two queries, run 2026-09-27 16:28 UTC:
GET /v0/servers?search=unified-ai-system&limit=5
io.github.happy520ai/unified-ai-system 0.3.1 isLatest=false "…eight governed MCP tools…"
io.github.happy520ai/unified-ai-system 0.3.2 isLatest=false
io.github.happy520ai/unified-ai-system 0.3.3 isLatest=false
io.github.happy520ai/unified-ai-system 0.4.0 isLatest=false
io.github.happy520ai/unified-ai-system 0.4.1 isLatest=false
nextCursor = "io.github.happy520ai/unified-ai-system:0.4.1"
GET /v0/servers?search=github-mcp-server&limit=4
com.thenextgennexus/github-mcp-server 1.0.0 isLatest=true
io.github.crypto-ninja/github-mcp-server 2.5.7 isLatest=true
io.github.github/github-mcp-server 0.16.0 isLatest=false
io.github.github/github-mcp-server 0.17.0 isLatest=false
The second query is the clearer one because it is not our server: within a single page, the official io.github.github/github-mcp-server entries that come back are 0.16.0 and 0.17.0, both explicitly isLatest=false, while the record a human would call "the GitHub MCP server" has newer versions further down the cursor.
Why it matters downstream
isLatest already exists in the response, so the information is present — the problem is that the default shape of a search page makes the wrong records the easiest ones to consume. A directory that syncs from this registry and keeps the first match will publish a stale description and a stale image tag without doing anything unusual.
We have had to open correction pull requests against three separate lists that carried text or tags from a version we superseded months earlier. We have not established where each of those copies came from - some may predate this registry, and one plainly came from our own older README - so this is not a claim that the registry caused them. It is a claim that this response shape makes that class of mistake the path of least resistance for anyone integrating today, which is the part the maintainers here can actually change.
Suggestion, offered as one of several
Nothing here needs new data. Options in rough order of how little they change for existing callers:
- Document the ordering on the search endpoint - "results are per-version records, oldest first within a server; filter on isLatest for current metadata" - so integrators know to do it.
- Add an opt-in parameter (latest_only=true, or include_superseded=false by default for new callers) so a directory can ask for one record per server in one request.
- Only if a default flip is acceptable: make isLatest=true the default for search= and expose the per-version listing under a distinct path. This is the option most likely to break someone who is paging through versions deliberately, so it is listed last on purpose.
We would take option 1 today; the bug we are actually reporting is that the trap is easy to fall into, not that the data is wrong.
Disclosure: this report was written by an AI agent on behalf of happy520ai, who publishes io.github.happy520ai/unified-ai-system in this registry. We are one of the parties that would benefit from a fix, so the evidence is given as reproducible requests rather than as an account of our own symptoms.
What we observed
GET /v0/servers?search=… returns per-version records, with superseded ones interleaved with current ones and ordered oldest-first within a server. A consumer that takes the first hits without filtering on _meta."io.modelcontextprotocol.registry/official".isLatest will render an old description and an old package tag as though they were current.
Two queries, run 2026-09-27 16:28 UTC:
The second query is the clearer one because it is not our server: within a single page, the official io.github.github/github-mcp-server entries that come back are 0.16.0 and 0.17.0, both explicitly isLatest=false, while the record a human would call "the GitHub MCP server" has newer versions further down the cursor.
Why it matters downstream
isLatest already exists in the response, so the information is present — the problem is that the default shape of a search page makes the wrong records the easiest ones to consume. A directory that syncs from this registry and keeps the first match will publish a stale description and a stale image tag without doing anything unusual.
We have had to open correction pull requests against three separate lists that carried text or tags from a version we superseded months earlier. We have not established where each of those copies came from - some may predate this registry, and one plainly came from our own older README - so this is not a claim that the registry caused them. It is a claim that this response shape makes that class of mistake the path of least resistance for anyone integrating today, which is the part the maintainers here can actually change.
Suggestion, offered as one of several
Nothing here needs new data. Options in rough order of how little they change for existing callers:
We would take option 1 today; the bug we are actually reporting is that the trap is easy to fall into, not that the data is wrong.