Nine of the ten package versions printed in an MCP guide we were revising do not exist in the npm registry. A reader copying google-calendar-mcp@1.4.0 gets a 404 at install time. The package itself resolves, the specific version string does not.
The defect came out of the fourth review round of pull request #236. The previous text used floating tags. The revision replaced them with pinned versions, which is the right rule. The version strings supplied just do not exist in the registry.
A bad pin is strictly worse than a floating tag. The floating tag installs something. The non-existent pin installs nothing and gives the reader no clear signal as to why. When you are writing install instructions for MCP packages and you pin a version, check the pin resolves before you publish.
The commit that shipped on 2026-09-11 adds that verification step. Six files changed, 162 lines added, 4 removed.
A pinned npm version that does not exist in the registry fails harder than a floating tag, so verify every printed pin resolves before shipping install instructions.
Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.
Top comments (1)
Hello, Robert
This is a great example of how “more deterministic” doesn’t automatically mean “more reliable.” I’ve seen the same issue in AI/MCP projects where documentation becomes stale faster than the actual code.
I’d probably treat every install command in technical docs almost like executable code—validate the package, version, and command in CI before publishing. Have you considered making that registry check part of the documentation pipeline rather than relying on review alone?