The MCP Registry is the source of truth that directories like Glama only mirror

Publishing an MCP server involves two separate steps, and developers who complete only one of them will quietly ship outdated software. That is the central argument of a dev.to post by PhilipAD, published on 5 October 2026, which walks through where AI agents actually look up MCP servers and concludes that the official MCP Registry, not the better-known directory sites, is the system of record.

Two publishes, not one

The first step is familiar to anyone shipping a package: push the server binary to npm or PyPI. The second, which the author says most people skip, is publishing metadata to the official MCP Registry. Directory sites such as Glama, PulseMCP, mcp.so and Smithery are not independent registries. According to the post, they re-scan and cache whatever the official registry exposes. The registry holds the authoritative record; the directories are downstream copies.

The registry stores metadata, not code

This split creates a concrete failure mode. Because the registry holds metadata rather than the binary itself, updating npm alone does nothing to the registry's view of your server. The author describes publishing version 1.5.0 to npm while skipping the registry step: the registry's latest endpoint keeps returning the previous version, still flagged with isLatest set to true. Clients that resolve through the registry then install the old build rather than the one intended to replace it. With two systems updated by separate commands, drift is inevitable unless both are kept in sync.

How to check for drift

The registry's API is public, so the mismatch is verifiable. The post points to a versioned endpoint on registry.modelcontextprotocol.io that resolves a server's latest entry, and highlights four fields that carry the weight: version, updatedAt, isLatest and status. The recommended check is to resolve the latest version through the registry, compare the returned version string against what the package manager reports, and read the response's _meta block. If the registry trails the package manager, every listing built on top of it is stale too.

Directories lag even further

Directory caches fall behind by a wider margin. As of 5 October 2026, according to the author, Glama's page for their own server still displayed the pre-rename brand weeks after the application had become MetricBridge. The lesson is that caches refresh when something re-scans them, not when you publish, so a directory page can trail both npm and the registry at the same time.

Descriptions shape discovery

For servers handling sensitive data, the registry description does extra work. A directory that ranks a cloud connector above a local one is reading timestamps, not making a privacy judgement. The author's advice for local, read-only servers is to state that explicitly in the registry description, because that string is what both directory listings and LLMs quote back to users during discovery.

Why it matters

MCP has become a standard mechanism for extending AI agents, and discovery increasingly flows through the registry and the directories that mirror it. A stale registry entry is not merely a cosmetic problem on a listing site: it is the mechanism by which agents decide what to install, so outdated metadata translates directly into outdated software running on user machines. Teams shipping MCP servers should treat the registry publish as a required part of the release process rather than an afterthought, and audit the four metadata fields whenever a version bump does not appear where agents expect it.