Tools MCP and External Integration
Tool Registry — Stack
Tool registry › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
What you are choosing is where a tool contract lives, who is allowed to change it, and how a change reaches the things that call it.
- Authoring workflow. Whether an entry is created by a pull request against a file, a form in a portal, or a call to an admin API. This single choice decides whether review, blame, and rollback come for free or have to be rebuilt.
- Contract expressiveness. Whether the store can hold the governance fields a tool entry needs — effect class, idempotency, data sensitivity, deprecation date — or only a name and a schema, forcing the rest into a side table nobody keeps current.
- Propagation. How long after a change before callers see it, and whether propagation is a push, a poll, or a redeploy. Deprecation enforcement is only as fast as this number.
- Query surface. Whether you can ask "every mutating tool touching customer records" in one query, which is what an audit actually needs, or only fetch entries by name.
- Availability coupling. If the catalogue is on the call path, its uptime becomes the floor for every tool invocation; if it is not, staleness becomes the problem instead.
- Change audit. Whether the history of who altered which field, and when, survives independently of the storage engine's backup policy.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Contract files in a Git repository with CI validation | Teams that want review, history, and rollback without building them | No runtime query surface; propagation requires a build or a sync job |
| Internal developer portal catalogues (Backstage and similar) | Organisations that already run one for services and want ownership and lifecycle fields reused | Entity models are service-shaped; tool-level fields arrive as free-form annotations |
| OpenAPI documents plus a developer portal | Tools that are thin wrappers over existing HTTP APIs | An HTTP operation and a model-facing tool are not one-to-one; descriptions need rewriting for a model reader |
| Dedicated schema registries (Confluent Schema Registry, Buf Schema Registry) | Shops that already enforce compatibility rules on message schemas and want the same discipline here | Built around message evolution, not around ownership, permission, or effect metadata |
| Key-value service registries (Consul, etcd) | Deployments that need fast runtime reads and watch-based change propagation | Everything beyond the key is an opaque blob you must validate yourself |
| In-code tool decorators from an agent framework | A single service where the code is the only consumer | The catalogue cannot be queried without running the application; governance has nowhere to live |
| Commercial AI and API gateway catalogues | Getting a central inventory quickly across teams that will not adopt a shared repo | The inventory reflects what is routed through that product, which is rarely everything |