PATTERN Cited by 1 source
Progressive tool disclosure meta-tools¶
Intent¶
Avoid paying the context-window cost of hundreds of tool schemas by collapsing each product namespace into two meta-tools — one for schema discovery and one for execution — while keeping frequently-used tools flat at the top level.
Shape¶
For each product namespace:
-
{product}__get_tool_schema— returns the full input schema for one specific tool on demand. Its tool description carries a compact one-line summary of every tool in the namespace, so the model can scan what's available without paying the full schema cost. -
{product}__invoke_tool— executes a tool in that namespace by name with its arguments.
Additionally:
- Most-used tools (search, file read/write, memory retrieval, entity
linking) stay permanently flat at the top level because they're
called on nearly every turn and are worth the resident schema cost.
- A SKILL.md file per namespace encodes domain-specific business
logic: which tool for which situation, common multi-step recipes,
and gotchas. This often lets the model go straight to invoke_tool
without a separate schema fetch.
Cost model¶
- Schema discovery: fetched once per tool per task (not per iteration). Bounded, predictable.
- Trade-off accepted explicitly: unfamiliar tools require 2 calls (get_schema → invoke) vs 1 for a permanently-flat tool.
- As products add tools, per-iteration context cost stays constant (only meta-tool descriptions grow by one line per new tool).
Seen in¶
- sources/2026-06-18-atlassian-long-horizon-reasoning-engine — Atlassian Long Horizon uses this for Jira, Confluence, Bitbucket, JSM, Compass, and all third-party connectors.