ToolRegistry: Unified Tool Management

• ToolRegistry is a unified tool management system that represents, discovers, and governs tools via explicit metadata and JSON-schema definitions.
• It supports multi-modal registration from raw functions, OpenAPI specs, and third-party libraries to streamline tool discovery and execution.
• Empirical tests show reduced integration code and enhanced concurrent execution, highlighting its efficiency in high-throughput environments.

ToolRegistry denotes a family of registry-centered mechanisms for tool-using systems in which tools are represented, discovered, selected, executed, and governed through explicit metadata and control interfaces rather than ad hoc prompt text. In one concrete formulation, ToolRegistry is a “protocol-agnostic tool management library” that unifies registration, representation, execution, and lifecycle management for function-calling LLMs (Ding, 11 Jul 2025). In adjacent work, closely related registry concepts appear as a training-time catalog of tool schemas and trajectories for LLM agents (Yang et al., 12 Nov 2025), a structured library produced by clustering and aggregating tools (Yue et al., 9 Oct 2025), a parameterized registry encoded directly into model vocabulary (Wang et al., 2024), a compile-time in-RAM block registry controlling tool visibility and ordering (Tomczak, 3 Jun 2026), and distributed metadata registries for service discovery in the Virtual Observatory (Demleitner et al., 2015, Benson et al., 2011).

1. Conceptual scope and defining properties

A common misconception is that a tool registry is only a static catalog of APIs. Recent work instead treats it as a control surface for the entire function-calling stack: tool schemas, semantics, parameter validation, execution, compatibility layers, discovery, composition, and sometimes training data. ToolMind states this explicitly: for tool-using systems, a registry must encode tool schemas and semantics, typical usage patterns, inter-tool dependencies, and examples of multi-turn, multi-tool trajectories; it therefore frames its dataset as both a very large structured tool catalog and a collection of interaction logs showing how an LLM agent should use that catalog in realistic scenarios (Yang et al., 12 Nov 2025).

The implementation-oriented formulation in ToolRegistry is narrower but operationally concrete. It is built as a helper library rather than a framework, with protocol agnosticism, developer simplicity, and execution efficiency as design principles. Its internal architecture has four layers: a tool management layer, a registration and integration layer, an execution engine, and an API compatibility layer. The resulting abstraction is explicitly execution-centric: internally everything is normalized to a Tool with a JSON-schema-like parameter definition, while adapters translate OpenAPI specs, MCP tool definitions, LangChain tool objects, and native Python functions into that internal form (Ding, 11 Jul 2025).

The broader literature expands the term beyond library design. ToolLibGen treats a tool registry as a structured library with creation, organization, aggregation, and retrieval layers rather than a flat set of functions (Yue et al., 9 Oct 2025). ToolGen treats the registry as part of the model’s parameters by representing each tool as a unique vocabulary token, eliminating an external retrieval step during tool selection (Wang et al., 2024). RAMPART generalizes the notion further: tools, instructions, schemas, heuristics, and skills are all blocks inside a programmable registry, and context assembly becomes an explicit compile-time operation (Tomczak, 3 Jun 2026).

2. Representation, schemas, and registration

The core implementation in ToolRegistry centers on a stateless Tool abstraction with fields name, description, parameters, callable, is_async, and parameters_model. The class uses Pydantic for validation and serialization, and Tool.from_function() derives a tool from a Python function by inspecting its signature, type hints, and docstring, generating a JSON Schema for parameters and a Pydantic validation model at registration time (Ding, 11 Jul 2025).

Registration is multi-modal rather than provider-specific. The library exposes register(...) for raw callables or pre-built Tool objects, register_from_class(...) for class or instance methods, register_from_openapi(...) for OpenAPI 3.0/3.1 operations, register_from_mcp(...) for MCP servers over stdio, HTTP, SSE, or WebSocket, and register_from_langchain(...) for LangChain tool objects. This makes protocol translation subordinate to a single source of truth: the internal Tool object and its schema (Ding, 11 Jul 2025).

Schema richness becomes more pronounced in data-centric tool registries. ToolMind formalizes each function as

$$\mathcal{F}=\{f_i\}_{i=1}^N,\qquad f_i:\mathcal{X}_i \to \mathcal{Y}_i,$$

with

$$\mathcal{X}_i=\prod_{k=1}^{m_i} x_{i,k},\quad \mathcal{Y}_i=\prod_{\ell=1}^{n_i} y_{i,\ell},$$

and attaches a description and type to each parameter. When source datasets have incomplete specifications, it prompts an LLM to fill missing descriptions and types, then embeds each parameter as

$$\mathbf{v}(r)=\phi\big(\text{DESC}\ \Vert\ \mathrm{desc}(r)\ \Vert\ \text{TYPE}\ \Vert\ \mathrm{type}(r)\big)\in\mathbb{R}^d.$$

From a registry perspective, this yields not only a name and JSON-like schema but also a semantic representation of arguments and returns (Yang et al., 12 Nov 2025).

A different representation discipline appears in ToolLibGen. There, the final registry entry is an aggregated public Python function backed by one or more classes, with primitive or JSON-string parameters and a Google-style docstring from which JSON function specs can be produced. The emphasis is not merely on executable code but on “lossless abstraction”: the public interface must preserve the functional coverage of the original cluster of tools (Yue et al., 9 Oct 2025).

3. Discovery, retrieval, and structural organization

Large tool sets create a retrieval problem as much as an execution problem. ToolLibGen begins from a fragmented toolset

$\mathcal{T}=\{t_1,\dots,t_M\},$

arguing that flat storage causes linear growth of the search space and retrieval ambiguity among closely related functions. Its remedy is to cluster tools into semantically coherent subdomains,

$\mathcal{C}=\{C_1,\dots,C_K\},$

and then aggregate each cluster into a smaller set of generalized tools

$C_k^*=\{t^*_{k,1},\dots,t^*_{k,m_k^*}\},$

with $m_k^* \ll m_k$. The resulting library combines a topic hierarchy with a semantic vector index over name-plus-description representations (Yue et al., 9 Oct 2025).

ToolMind organizes tool composition through a directed function graph $G=(V,E)$ over functions. For two functions $f_i$ and $f_j$, it computes

$$\mathcal{X}_i=\prod_{k=1}^{m_i} x_{i,k},\quad \mathcal{Y}_i=\prod_{\ell=1}^{n_i} y_{i,\ell},$$0

and creates an edge $$\mathcal{X}_i=\prod_{k=1}^{m_i} x_{i,k},\quad \mathcal{Y}_i=\prod_{\ell=1}^{n_i} y_{i,\ell},$$1 when $$\mathcal{X}_i=\prod_{k=1}^{m_i} x_{i,k},\quad \mathcal{Y}_i=\prod_{\ell=1}^{n_i} y_{i,\ell},$$2, followed by LLM-based validation. Random walks over this graph sample latent workflows, which are then turned into user intents and multi-turn trajectories. In registry terms, this is a tool dependency or compatibility graph that supports discovery, planning, and schema-aware retrieval at more than 20k-tool scale (Yang et al., 12 Nov 2025).

ToolDreamer addresses a different failure mode: user queries are often poorly aligned with the language of tool descriptions. It therefore inserts an LLM-generated bridge in the form of hypothetical tools containing a Thought, Tool Name, and Tool Description. These synthetic descriptions are aligned with gold tools through a similarity matrix and Hungarian matching, then used to train or query sparse and dense retrievers. For training, the anchor can be a TND or QTND string, optimized with an InfoNCE loss

$$\mathcal{X}_i=\prod_{k=1}^{m_i} x_{i,k},\quad \mathcal{Y}_i=\prod_{\ell=1}^{n_i} y_{i,\ell},$$3

At inference, multiple hypothetical-tool retrieval lists are fused with Reciprocal Rank Fusion (Sengupta et al., 22 Oct 2025).

ToolGen proposes a more radical alternative in which the registry is not externally searched at runtime. Given a tool set $$\mathcal{X}_i=\prod_{k=1}^{m_i} x_{i,k},\quad \mathcal{Y}_i=\prod_{\ell=1}^{n_i} y_{i,\ell},$$4, tool virtualization maps each tool to a unique token

$$\mathcal{X}_i=\prod_{k=1}^{m_i} x_{i,k},\quad \mathcal{Y}_i=\prod_{\ell=1}^{n_i} y_{i,\ell},$$5

Retrieval becomes next-token prediction over $$\mathcal{X}_i=\prod_{k=1}^{m_i} x_{i,k},\quad \mathcal{Y}_i=\prod_{\ell=1}^{n_i} y_{i,\ell},$$6, optionally constrained by a trie during Action generation. This reframes tool retrieval and tool calling as a unified generative process rather than a retriever-plus-prompt pipeline (Wang et al., 2024).

4. Execution, lifecycle, and runtime control

Execution-oriented registries must convert model outputs into validated calls, schedule them, and return results in provider-compatible form. ToolRegistry accomplishes this with an Executor that maintains both a ThreadPoolExecutor and a ProcessPoolExecutor, normalizes provider-specific outputs into an internal ToolCall format, validates arguments through the tool’s Pydantic model, and converts results back into API-specific tool messages. It supports sync/async bridging through run(**kwargs) and arun(**kwargs), and it can fall back from process mode to thread mode when serialization fails (Ding, 11 Jul 2025).

Lifecycle management in the same library includes namespaces, registry composition, and selective projection. Namespaces reduce naming conflicts and group tools logically; merge(other_registry, conflict_strategy=...) combines registries; spinoff(names) creates a new registry containing only selected tools; and reduce_namespace() flattens a single remaining namespace. Discovery and introspection operate over _tools, _sub_registries, and the shared executor, with validation of schemas, callability, and external dependencies (Ding, 11 Jul 2025).

RAMPART generalizes lifecycle management into explicit runtime transformation primitives. Its atomic unit is an instruction block

$$\mathcal{X}_i=\prod_{k=1}^{m_i} x_{i,k},\quad \mathcal{Y}_i=\prod_{\ell=1}^{n_i} y_{i,\ell},$$7

stored in an ordered in-RAM block registry. The registry supports five composable operations—promote, gate, write, evict, and rollback—before each model call. Compilation optionally applies relevance gating, then performs an ordered walk under a token budget. For tool governance, the important consequence is that visibility, order, inclusion, and forgetting become programmable runtime operations rather than prompt-editing conventions (Tomczak, 3 Jun 2026).

This registry model also adds permission and provenance semantics. Blocks carry source ∈ {seed, agent, orchestrator}, an author, and a removable flag; non-evictable orchestrator or seed blocks can therefore act as protected tool schemas or constraints. RAMPART further shows that structural removal is stronger than policy text: evicting a schema block yields 0% invocations against 100% with the schema present, because the tool description simply no longer appears in compiled context (Tomczak, 3 Jun 2026).

5. Distributed registries and interoperability models

The Virtual Observatory registry standards provide a mature metadata-centric model for distributed tool and service registries. The architecture distinguishes publishing registries, which expose resource descriptions for harvesting, from searchable registries, which aggregate those records and support discovery. Harvesting is pull-based, incremental through date filtering, and ownership-aware through the reserved OAI-PMH set ivo_managed. Searchable registries expose Search, KeywordSearch, GetResource, and GetIdentity, with an optional XQuerySearch, and can be either local or full registries (Benson et al., 2011).

RegTAP translates this distributed XML metadata model into a relational registry schema accessed through TAP and ADQL. It defines 13 tables, including rr.resource, rr.capability, rr.interface, rr.intf_param, rr.res_table, rr.table_column, rr.relationship, and rr.res_detail, with ivoid as the conceptual global primary key of a resource record. The design is explicitly geared toward easy query authoring through consistent naming and NATURAL JOIN, plus four mandatory UDFs: ivo_nocasematch, ivo_hasword, ivo_hashlist_has, and ivo_string_agg (Demleitner et al., 2015).

The registry interface and the execution-centric ToolRegistry library occupy different points in the design space. The former treats registries as interoperable metadata services, with capabilities, interfaces, access URLs, and harvesting semantics. The latter treats a registry as an in-process runtime component that can emit OpenAI-compatible tool schemas, parse tool calls, and execute them. A plausible implication is that production tool ecosystems may combine both patterns: a distributed searchable registry for discovery and a local execution registry for invocation and lifecycle control (Ding, 11 Jul 2025).

6. Empirical behavior and performance

Execution-centric evaluation shows that a registry abstraction can materially reduce implementation overhead. ToolRegistry reports 60-80% reduction in tool integration code, up to 3.1x performance improvements through concurrent execution, and 100% compatibility with [OpenAI](https://www.emergentmind.com/topics/o3-openai-platform) function calling standards. In the detailed benchmarks, native functions required 45 manual LOC versus 8 with ToolRegistry, OpenAPI integration 120 versus 25, MCP integration 85 versus 12, and multi-protocol setup 250 versus 45. Throughput under 100 concurrent tool calls reached 8,844 calls/s for native class tools in thread mode and 128 calls/s for MCP SSE tools in process mode, the latter corresponding to the cited 3.1× improvement (Ding, 11 Jul 2025).

Data-centric registries show corresponding gains in agent quality. Models fine-tuned on ToolMind improve over baselines on BFCL-v4, τ-bench, and τ²-bench. For [Qwen3](https://www.emergentmind.com/topics/qwen3)‑14B (FC), BFCL-v4 overall increases from 45.14 to 50.54, multi-turn from 44.12 to 51.00, and Agentic Search from 12.50 to 35.50; on τ-bench the average rises from 38.78 to 53.00, and on τ²-bench from 40.63 to 49.07. The ablations further show that removing turn-level filtering degrades generalization, indicating that per-turn validation of registry-derived traces is not merely a data-cleaning convenience (Yang et al., 12 Nov 2025).

Structured organization also improves retrieval and reasoning. ToolLibGen reports that LLM-based clustering has 95% manually verified cluster coherence versus 72% for an embedding-plus-k-means baseline, and that aggregated libraries outperform fragmented or merely clustered toolsets. For GPT‑4.1 on seen cases, average accuracy rises from 55.9% for CoT to 70.3% for ToolLibGen; on unseen SuperGPQA cases, it rises from 57.1% to 60.6%. Tool count is compressed substantially, for example from 175k question-specific tools to 8.9k library tools in Math (Yue et al., 9 Oct 2025).

Retriever conditioning yields additional gains. ToolDreamer improves BM25 and dense retrievers both with and without retraining. Query-only BM25 averages N@10 = 29.55, P@10 = 6.44, R@10 = 36.71, MRR = 32.52, while BM25(QTND) reaches 33.80, 7.49, 43.68, and 35.75. For Qwen3-8B, the standard query-trained baseline averages 39.87, 8.57, 50.18, and 42.07, whereas ToolDreamer Qwen3(QTND) reaches 42.47, 9.34, 54.26, and 43.88 (Sengupta et al., 22 Oct 2025).

Parameterized registries can outperform external retrieval stacks on large tool sets. ToolGen scales to 46,985 added tool tokens and 47k APIs in experiments. On the Multi-Domain retrieval setting, ToolGen reports NDCG@1 of 87.67, 83.46, and 79.00 across I1/I2/I3, compared with 72.31, 64.54, and 52.00 for ToolRetriever. In StableToolBench evaluation with retrieval, ToolGen attains average SoPR of 53.28 and SoWR of 51.51, exceeding ToolLlama‑3’s 51.55 and 49.70 (Wang et al., 2024).

Registry structure also affects runtime cognition. RAMPART finds a position cliff in compile-time context assembly: when the task follows the registry, the cliff falls at roughly the seventh block position; when the task precedes the registry, at roughly the twelfth. Grouping a critical block with content-adjacent neighbors and promoting the group as a unit raises success “by tens of percentage points” where single-block placement fails. Relevance gating reduces prompt cost by 67.8% while recovering 83% of the promoted-condition success rate (Tomczak, 3 Jun 2026).

7. Limitations, misconceptions, and open directions

Several limitations recur across registry designs. ToolRegistry’s process mode depends on Dill serialization, and some complex Python objects may fail to serialize; the implementation is also presently focused on OpenAI-style tools, with more limited provider-native support for Anthropic and Gemini, limited retry policies for network-dependent tools, and no runtime validation of output schemas (Ding, 11 Jul 2025). These are implementation constraints rather than conceptual flaws, but they matter for production adoption.

Data-driven registries inherit the weaknesses of their training sources. ToolMind relies on simulated users and non-executable tools, overrepresents some domains such as data analysis and entertainment, and still leaves room for greater task complexity. ToolLibGen’s coverage guarantees are bounded by the source questions used during reviewing and aggregation. ToolDreamer depends on the quality of hypothetical tool generation, and degraded prompting measurably lowers retrieval quality (Yang et al., 12 Nov 2025, Yue et al., 9 Oct 2025, Sengupta et al., 22 Oct 2025).

Parameterized registries trade off retrieval simplicity against update difficulty. ToolGen removes the external retrieval step, but adding or removing tools requires vocabulary extension, additional memorization and retrieval training, and careful handling of catastrophic forgetting. Its own generalization experiments indicate that unseen-tool generalization remains an open problem for generative retrieval (Wang et al., 2024). By contrast, external registries are easier to update, but they reintroduce a separate retrieval layer and its associated misalignment.

A further misconception is that tool availability is determined only by tool quality or retriever scores. RAMPART shows that visibility and ordering are first-class variables: the same schema can be highly effective, ineffective, or entirely absent depending on compile-time position, grouping, gating, or eviction (Tomczak, 3 Jun 2026). The IVOA standards make a parallel point from the metadata side: registries depend on stable schemas, capability descriptions, and interoperable discovery protocols, not only on the resources being registered (Benson et al., 2011, Demleitner et al., 2015).

The research trajectory therefore points in multiple directions at once: richer schema-first representations with semantic embeddings, automated compatibility graphs over tools, clustered and aggregated libraries, retrievers conditioned by hypothetical tool descriptions, tokenized parameter-space registries, and programmable runtime registries with provenance and eviction semantics. Taken together, these results suggest that ToolRegistry is no longer well described as a simple name-to-function map. It is an increasingly explicit systems layer for representing tool semantics, constraining exposure, organizing retrieval, executing calls, and preserving the interface between agents and the external world.