Skip to main content
Tool presentation controls how the tools bound to an agent or gateway are shown to the model. It is one setting with four values, and it exists because tool choice degrades as a tool list grows.

​
The problem

Bind a handful of capabilities and you can easily land at 40 or 50 tools. Every one of them, with its full JSON Schema, goes into the prompt on every turn. That costs tokens, and past a certain surface size the model gets worse at picking. Tool presentation gives you three ways to shrink what the model sees, plus a default that picks between two of them for you.

​
The four modes

Set per agent and per gateway. The stored value is one of direct, discovery, unified, adaptive.

Direct

Every bound tool is listed as itself. What the model sees is what you bound.

Discovery

Three meta-tools replace the list: discover_tools, get_tool_schema, execute_tool. The model searches, reads one schema, then calls.

Unified

One tool, unified_tool. Describe the task in natural language; a discovery step picks the tool and maps the arguments.

Adaptive (default)

Resolves to Direct or Discovery based on how many tools are actually bound.

​
Adaptive

Adaptive is the platform default for new agents and gateways. At the point the tool surface is opened it counts the customer-bound tools and resolves:
  • fewer than 30 tools → Direct
  • 30 or more → Discovery
Adaptive never resolves to Unified. Unified is an explicit authoring decision — the natural-language-dispatcher pattern — not something the platform falls into because a surface got large. The 30-tool threshold is a fixed platform constant, not a per-agent setting. It sits in the middle of the band model vendors document as the point where tool-choice quality starts to fall off.

​
Discovery, concretely

In Discovery mode the model does not see your tools. It sees three: The underlying tools are not directly callable in this mode. A call has to go through execute_tool, and it is validated against the corpus snapshot taken when the surface opened. Guessing a tool name and calling it directly does not work.

​
Unified, concretely

Unified exposes a single unified_tool. The caller passes a natural-language request, optionally with context and a list of preferred_tools. A discovery step selects a tool and maps parameters, then executes it. The response carries the result plus metadata about how it got there: which tool was discovered, a confidence score, and the parameters that were mapped. The confidence threshold is 0.7, global and not configurable.

​
What this does not change

Tool presentation is about presentation. It does not change what an agent is allowed to do.
  • Authorization is unaffected. Every call, whether it arrives directly or through execute_tool or unified_tool, goes through the same admission path.
  • System tools are always direct. Skills, workflow, journal, and form tools are appended as themselves in every mode. They are never folded behind a meta-tool.
  • The meta-tools themselves bypass the gate — they recurse back into normal tool dispatch, which is where the real decision happens.

​
Choosing a mode

Direct when the surface is small and you want the model reasoning over real schemas. This is the best-quality option below roughly a couple dozen tools. Discovery when the surface is large. You trade an extra round trip or two for a much smaller prompt and a better-focused choice. Unified when you want a single natural-language entry point — an agent whose whole job is “say what you want and I will find the tool”. It is the least transparent option: one call in, one result out, with the tool choice made inside. Adaptive when you would rather not think about it, and your tool count moves over time.

​
Where to set it

In the Portal: an agent’s Advanced settings carry a “Tool presentation” section; a gateway has its own Tool Presentation view. Gateway autonomy settings live inside that same view.
Next: Workflows for durable multi-step automation, or see how to configure tool presentation on a specific agent.