symfonic.capabilities.tools.catalog¶
catalog ¶
The tool catalogue โ one reading of the registry, shared by everyone.
Before T3.1.2 the same facts were derived in four places: the engine built manifest lines from tool objects, the registry held policy metadata, the react node rebuilt name tuples for rewrite gating, and the prompt builders re-read descriptions. Four derivations of one fact drift independently, and the failure mode is silent โ a tool the model is told it can call but which policy will never bind.
The catalogue is that reading, done once. It is immutable: build a new
one when the registry changes (it is frozen at compile() anyway).
ToolCatalog ¶
An ordered, immutable set of :class:ToolDescriptor readings.
Source code in src/symfonic/capabilities/tools/catalog.py
from_registry
classmethod
¶
Read a registry, lifting each tool's registration metadata.
Source code in src/symfonic/capabilities/tools/catalog.py
from_tools
classmethod
¶
Read a bare sequence of tool objects (no registry metadata).
manifest_entries ¶
The agent-facing manifest: name: summary per visible tool.
This is the single source the system prompt renders. A tool hidden by any of the three visibility signals never appears, so a deliberately-hidden tool cannot leak into a rendered prompt.
Source code in src/symfonic/capabilities/tools/catalog.py
resolve ¶
Return the live tools for names, in catalogue order.
Unknown names are dropped rather than raising: the caller is usually a router repeating a name from somewhere less trusted than the registry.
Source code in src/symfonic/capabilities/tools/catalog.py
subset ¶
A catalogue holding only names, in catalogue order.
ToolRegistryLike ¶
Bases: Protocol
The narrow slice of a tool registry the catalogue reads.
Structural on purpose: the capability layer may not import the
legacy symfonic.core.tools.registry module, and a registry that
answers these two questions is a valid source whatever else it is.