Agent infrastructure
Agents in production
Agent tool registry explained: what it is, why it becomes the bottleneck at scale, how it differs from MCP servers, and what production-grade registries hold.
An agent tool registry is the catalogue and control plane that tells an agent which tools exist, what each one does, how to call it, and who's allowed to. It sits between the model that reasons and the products that get acted on. Every agent project builds one eventually. Most build it badly, twice.
The question isn't whether you need a registry. If your agent calls more than a handful of tools, you already have one — it's just scattered across prompts, config files, and someone's head. The question is what a real one looks like, what it has to do beyond "list the tools", and where the popular framings (MCP servers, agent frameworks, unified APIs) leave the gap open.
This piece covers five things: what a tool registry actually is, why it becomes the bottleneck as agents scale, how it differs from an MCP server or a service catalogue, what a production-grade registry has to hold, and where the market is heading. Position first: the registry is a runtime concern, not a documentation artefact. Treating it as the latter is why agent projects stall.
A tool registry is the authoritative index of every tool an agent can invoke. At minimum it holds the tool's name, description, input and output schema, and the endpoint or handler that executes it. That's the shape everyone starts with — a JSON file, a Python module, a decorator pattern like the one LangChain or the OpenAI Agents SDK exposes.
That definition is correct and useless. It describes the file, not the system. A real registry has to answer questions the file can't: which version of this tool is current, who is allowed to call it, what happens when the underlying API changes, how does the agent discover new tools without a redeploy, and how do you audit what was called when something goes wrong.
The useful definition is closer to this: a tool registry is the runtime index that lets an agent discover, select, and safely invoke tools, with the metadata and controls needed to keep that working as tools, permissions, and products change. Every word in that sentence is load-bearing. Drop "runtime" and you get a spec file. Drop "safely" and you get a security incident. Drop "as things change" and you get a system that works for two weeks.
The secondary keyword variations — tool registry for AI agents, AI agent tool catalog, central tool registry MCP — all point at the same object viewed from different angles. Catalog frames it as a browsing surface. Registry frames it as a source of truth. MCP-prefixed framings assume the Model Context Protocol is the transport. The object underneath is the same.
At five tools, you don't need a registry. You need a list. At fifty, the list stops working, and not for the reason people expect.
The first thing that breaks isn't selection accuracy — the model can still pick between fifty tools if the descriptions are good. What breaks is maintenance. Every tool description drifts against the underlying API. Every auth scope has to be re-verified when the product ships a new permission model. Every schema change silently invalidates cached tool definitions. We've written about connector deprecation being a permanent operating condition rather than a scheduled event. The registry is where that condition lives or gets buried.
The second thing that breaks is selection. In our experience, somewhere around a few dozen tools the model starts picking wrong tools in ways that look like model failures but are registry design failures. We covered the mechanics in agent tool selection and how many tools an agent should have. The registry has to support retrieval, filtering, and scoping — not just enumeration. If your registry answer to "which tools should this agent see right now" is "all of them", you're going to hit a selection wall.
The third thing that breaks is identity and permissions. A registry that returns the same tool definitions to every caller is fine in a demo. In production, the tools available depend on the authenticated user's role, the tenant's plan, and the agent's operating scope. That's not a metadata problem — it's a runtime authorisation problem attached to the registry surface.
At portfolio scale, one more thing breaks: discovery across products. A company with six SaaS products building agents on all of them ends up with either six sibling registries that don't know about each other, or one central registry that no product team owns. Neither ends well without deliberate design.
These three get conflated constantly. They're not the same thing.
An MCP server is one possible transport for a registry. The registry is the underlying data and control plane; the MCP server is one wire format for exposing it. You can have a registry with no MCP server (many production agents don't use MCP at all) and you can have an MCP server that's just a thin file (many public ones are). The "central tool registry MCP" search term reflects a real question — teams want to know if their MCP server is their registry. Usually it shouldn't be, because the registry has to serve callers beyond MCP clients, and it has to hold state (versions, permissions, audit) that a stateless MCP server doesn't.
A service catalogue like Backstage is adjacent but different. Catalogues are primarily for humans finding owners and dependencies (though agents are starting to read them too). Registries are for agents finding capabilities. The overlap is metadata; the divergence is the primary consumer and the update cadence.
Worth naming what a registry is not, given the crowded adjacent categories: it's not an API gateway (gateways front APIs that exist; registries index tools regardless of what's behind them), it's not an agent framework's tool decorator (that's a way of defining tools, not a system for managing them), and it's not a unified API (unified APIs normalise third-party schemas; registries manage the tools calling into any schema).
Strip away the terminology and there are seven things a registry that survives contact with production has to do. Miss any of them and you'll rebuild the registry within twelve months.
1. Versioned tool definitions. Tools change. Parameters get renamed, added, deprecated. Agents in flight need to see a coherent version; agents starting fresh should see the current one. This is OpenAPI spec drift applied to tool schemas — the drift is worse because there are more of them and they change more often.
2. Scoped discovery. Not every agent should see every tool. Scoping happens on multiple axes: user role, tenant plan, agent purpose, environment (dev vs prod), sensitivity tier. A registry that returns a flat list is a registry that's about to leak either capability or attack surface.
3. Runtime authorisation, per invocation. Listing a tool and being allowed to call it are different concerns. The registry has to either enforce authorisation itself or delegate to a runtime that will. The identity that matters is the authenticated user's — not a shared service account. We've written about this at length in agent identity vs user identity.
4. Structured descriptions the model can actually use. Tool descriptions aren't docs. They're prompt inputs. Descriptions that make sense to a human but confuse the model are a registry problem, and one that has to be evaluated systematically — not by vibes. Registries need a place to store both the human-readable and the model-optimised description, and to A/B them when selection accuracy drops.
5. Change detection and drift alerts. When the underlying API changes shape, the registry needs to know before the agent's next call fails. This is contract testing plus schema diffing plus a way to route the alert to whoever owns the tool. Most homegrown registries skip this and find out the hard way.
6. Audit trail per invocation. Every tool call needs to be logged with the calling agent, the authenticated user, the tool version, the inputs, and the outcome. This is table stakes for any security review and non-negotiable for regulated industries. It has to be structural, not bolted on.
7. Deprecation and migration paths. Tools get replaced. When they do, the registry has to hold both versions long enough for callers to migrate, communicate the deprecation, and eventually enforce the cutover. If your registry has no story here, every deprecation becomes an incident.
Notice what's not on this list: a beautiful UI, a marketplace, or a public directory. Those are features, not requirements. The requirements are all about what the runtime needs to trust the registry as a source of truth.
A registry that does all seven things well has a lot of moving parts. A registry that does none of them is a JSON file. Most teams sit uncomfortably in the middle — enough infrastructure to feel like a system, not enough to actually hold. The honest trade-off is between building a registry that's coupled to your product (fast to ship, brittle across products) and one that's a proper platform surface (slower to ship, holds at portfolio scale). If you have one product, the coupled version is fine. If you have five, it isn't.
The reason we talk about the registry as a runtime concern rather than a documentation artefact is that it's where the tools-layer problem actually shows up. Pontil is a Tools-as-a-Service platform — we generate the tools agents call from the APIs a product already has, run them under the authenticated user's identity, and keep them current as the underlying product changes. The registry is the surface that ties those three things together.
What that means practically: the tool definitions, the versioning, the per-user scoping, the change detection, and the audit trail aren't seven separate things to build. They're one thing, aligned to the product's SDLC, generated from the code that already exists. The alternative — a bespoke registry per product plus bespoke connectors plus bespoke auth plumbing — is the shape of most stalled agent projects. If you're trying to figure out where your project is going to stall, our why agent projects stall explainer walks through the pattern.
The interesting question isn't whether registries will become standard infrastructure — they will, the same way service catalogues did a decade ago. The interesting question is who owns them.
Today there are three plausible owners. Agent framework vendors want the registry to live inside the framework, because that's where their surface is. MCP-native platforms want the registry to be an MCP server catalogue, because that's the protocol they're betting on. Product teams end up owning the registry by default, because the tools describe their product and change when their product does — and neither the framework nor the protocol layer knows when their API changed.
Our read is that the registry belongs with the product, not the framework or the protocol. Frameworks change every 18 months. Protocols evolve. Products, and the APIs behind them, are what the registry actually has to stay accurate against. Anything else is putting the source of truth in the wrong place.
The part worth watching is how registries handle scale across a portfolio — the case where one company has multiple products and wants agents that can reach across all of them without collapsing every product team's tools into one undifferentiated pile. That's the harder problem, and it's the one nobody has cleanly solved yet.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
