# When a Registry Tool Is Removed: Owning the Spec vs Depending on the Catalog

> Source: <https://dev.to/jeff_pdc/when-a-registry-tool-is-removed-owning-the-spec-vs-depending-on-the-catalog-4cg2>
> Published: 2026-10-30 07:14:11+00:00

**Quick answer:** A registry is a discovery channel, not a guarantee of availability. If your agent workflow depends on a server pulled from a public catalog and that entry is removed, renamed, or taken over, an integration that worked yesterday can break with no change on your side. Owning the underlying spec and generating the MCP server from it removes that single point of failure: the catalog may list your server, but it is not the thing your workflow depends on. The registry becomes optional marketing, while the source of truth is a file in your own repository.

Registries are genuinely useful. They make a server discoverable, handle distribution, and lower the friction of adoption. The risk is treating that convenience as a dependency. A maintainer can delete a package, a registry can change its terms, and a name can be re-registered by someone else after a removal. None of these are hypothetical; they are the same supply-chain concerns teams already apply to package managers. The mitigation is not to avoid registries, but to keep the ability to run the server without them.

The two postures differ sharply in what happens when an external entry changes.

| Dimension | Registry-only dependency | Owned spec, generated server | 
|---|---|---|
| Source of truth | External catalog entry | Spec in your repo | 
| Entry removed | Workflow breaks | Server regenerated locally | 
| Name takeover | Trust risk | Irrelevant to your runtime | 
| Version control | Whatever the catalog holds | Locked in git | 
| Registry role | Hard dependency | Optional distribution | 

An MCP server generated from the OpenAPI document lives in your build, so a catalog disappearing does not affect the running integration. The registry can still publish it for discoverability, but nothing in the critical path requires the catalog to be reachable.

`# generate the server from the spec in your repository; the output is # yours and does not depend on a registry entry existing openapi-to-mcp generate \ --spec ./openapi.yaml \ --output ./mcp-server \ --operations listOrders,getOrder,createOrder # run it locally or self-host it; a public catalog is not required node ./mcp-server/start.js`

When you do consume a third-party server from a registry, pin a specific version and verify its provenance rather than tracking a floating name. For your own servers, keep the spec authoritative so a registry outage is at most a loss of external discovery, never a loss of function.

`# even when using a registry, pin a version and record the checksum so # a re-registered or silently changed entry is detected mcp install example-service \ --version 1.4.2 \ --verify-checksum sha256:9f2c... \ --source https://your-registry.example.com # a mismatch fails loudly rather than pulling whatever now owns the name`

A local-first workflow keeps the OpenAPI document and generated server under version control, with the registry as an optional place to publish for adoption. This gives the discoverability benefit without the supply-chain fragility, and it means a removed or re-registered catalog entry is an event you can observe and route around rather than an outage. The underlying principle is the same one behind lockfiles and vendored dependencies: external channels are great for distribution, but the thing your production system relies on should be something you own.

No. Publish for discoverability and adoption, but keep the generated server runnable from your own spec so the registry is not a hard dependency of your runtime.

It is uncommon but high-impact, and the same class of risk exists across package ecosystems. Pinning versions and verifying checksums makes a takeover or silent change detectable rather than silently trusted.

Pin the version, record the checksum, and where licensing permits, vendor or mirror the artifact so a removal does not remove your ability to run it.

Owning the spec and generating the server is the core protection; where you host it, including a managed gateway, is a separate choice. The key is that the source of truth and the ability to run are in your control.

This is part of the [Powerduck vs Smithery](https://www.powerduck.com/blog/powerduck-vs-smithery/) comparison — start there for the full decision around hosting MCP servers.