# Pinning an MCP Server Version: Registry Drift vs a Locked Spec > Source: > Published: 2026-10-30 04:12:19+00:00 **Quick answer:** Pointing an agent at a registry entry that always resolves to "latest" means the tools it calls can change underneath you without a commit or review, and a passing build today is no guarantee of the same behavior tomorrow. Pinning the MCP server to a specific version — derived from a locked OpenAPI spec in your repo — makes tool behavior reproducible and turns updates into deliberate, reviewed changes. Use a registry for discovery, but lock the version your agent actually consumes so drift cannot reach the agent silently. Registries exist to make MCP servers discoverable and easy to install, which is valuable on the way in. The convenience becomes a risk once the server is part of an automated workflow: a maintained, version-less endpoint can add tools, change parameters, or alter behavior, and every client starts using the new version immediately. Teams that treat a registry URL like a dependency with no lockfile end up debugging behavior that no change in their own repository produced. The problem is not registries; it is consuming mutable, unpinned endpoints in a system that needs reproducibility. There are three concrete ways a "latest" pointer changes behavior, and they are easy to miss because the client config never changes. `// mutable: resolves to whatever the registry currently serves { "mcpServers": { "orders": { "url": "https://registry.example.com/mcp/orders" // no version } } } // a server update changes the tool list with no change to this file` The reliable pattern mirrors dependency management: resolve a specific version, lock it, and update only through a deliberate change. Where the server is generated from OpenAPI, the spec in your repository is the natural lock — pinning a release that corresponds to a committed spec means the tools match a reviewed artifact. Keep the version alongside the spec revision in the repo so the relationship is explicit. When the contract changes, regenerate the server, cut a new version, and update the pointer in a commit that reviewers can see. The change is then attributable, and bisecting a regression works the same way it does for any dependency. | Dimension | Registry "latest" | Pinned version from locked spec | |---|---|---| | Discoverability | High | Discovery still happens first | | Reproducibility | Not guaranteed | Same tools every run | | Updates | Automatic, unreviewed | Deliberate version bump | | Regression source | Can be external | Always a visible commit | | Rollback | Hard, no fixed target | Revert the version | | Best for | Initial exploration | Production automation | When an MCP server is generated from the OpenAPI document, the strongest arrangement is to version the server from the spec and host it on a gateway that serves immutable, versioned endpoints rather than relying on a mutable registry install. The registry remains useful for discovery and documentation, but the agent consumes a pinned gateway URL that corresponds to a contract revision in source control. A contract-driven workflow can also verify the pinned server's tools against the spec, catching a mismatch before the agent ever calls the wrong operation. It delivers fixes and breaking changes with equal lack of ceremony. In production, the safer path is to get notified of a new version, review it against the spec, and move the pin deliberately so a fix cannot arrive bundled with a behavior change you did not test. Prefer a gateway that can serve immutable versions, or self-host the generated server at a versioned path. If only a mutable endpoint exists, mirror and lock it in infrastructure you control rather than pointing the agent directly at an unpinned registry URL. It is the same principle: lock a resolved version so installs are reproducible and updates are reviewed. The artifact is a running MCP server rather than a package, but the risk of floating "latest" and the value of a lockfile are identical. No. Use the registry to find and evaluate servers, then pin the specific version for actual use. Discovery and immutable consumption are separate concerns; you do not have to abandon the registry to avoid its drift. This is part of the [Powerduck vs Smithery](https://www.powerduck.com/blog/powerduck-vs-smithery/) comparison — start there for the full decision of where to host and how to version an MCP server.