Every MCP server has two publication steps and most people only do one.
You publish the binary to npm or PyPI. You publish the metadata to the official MCP Registry. Directories like Glama, PulseMCP, mcp.so and Smithery re-scan and cache what the registry exposes. The registry is the source of truth. The directories are copies of it.
The part that bites: the registry stores metadata, not the binary. Publish 1.5.0 to npm and skip the registry step, and version=latest keeps returning the old version with isLatest set to true. Clients install the build you thought you replaced. Two systems, two commands, guaranteed drift.
The registry API is public, so you can see it yourself:
Four fields carry the weight: version, updatedAt, isLatest, status. Resolve versions/latest, compare the version to npm view version, and read the _meta block. If the registry version trails your package manager, the listing is stale.
Directory lag runs longer. As of 5 October 2026, Glama's page for our own server still carried the pre-rename brand, weeks after the app became MetricBridge. Caches refresh when something re-scans them, not when you publish.
For health data the description does extra work. A directory that ranks a cloud connector above a local one is reading timestamps, not making a privacy judgement. If your server is local and read-only, say so in the registry description, because that is the string directories and LLMs both quote.
Full audit, the real API response, and the 60-second checklist: https://www.healthexport.dev/blog/where-agents-find-mcp-servers?utm_source=devto&utm_medium=social&utm_campaign=exp-20261005-hea182-registry
Top comments (0)