A tool registry is a catalog that lists the tools an AI agent or application can use, along with the metadata needed to call them correctly.
When you build an agent that can search, fetch data, send messages, or run internal workflows, the model needs more than just a tool name. It needs to know:
A tool registry solves that discovery problem. Instead of hard-coding every tool into the agent logic, you keep a structured source of truth that the agent, runtime, or orchestrator can read. In practice, teams reach for a registry when they want tools to be added, removed, versioned, or permissioned without rewriting the agent.
A tool registry usually stores one entry per tool. Each entry includes a name, description, input schema, and sometimes auth requirements, ownership, version, or execution endpoint.
At runtime, the agent or middleware queries the registry to learn which tools exist and how to use them. The registry may then be used to:
The exact design varies. Some systems keep the registry in code as a static list; others expose it as an API or database-backed service. In agent frameworks and tool-calling systems, this idea is closely related to the “tool schema” or “function definition” mechanism described in official docs.
A minimal registry entry might look like this:
{
"name": "search_docs",
"description": "Search the internal documentation index",
"input_schema": {
"type": "object",
"properties": {
"query": { "type": "string" }
},
"required": ["query"]
}
}
An agent sees this entry, decides it needs document search, and emits a call like:
{"name":"search_docs","arguments":{"query":"refund policy"}}
The registry lets the agent know that query is required and that the tool is meant for internal docs, not web search.