As browser capabilities grew, the descriptions an agent could read grew too. Supplying all of them on every turn made a small reading task carry an unnecessarily large command catalog. I separated discovering the needed contract from executing an operation.
Knowing the catalog differs from knowing the next contract
Reading the current title does not require every parameter for uploads, reservations and plugin editing. The caller can inspect the reading family first and learn the inputs for observation, search and extraction. If field input becomes necessary, it can discover that family then.
This does not permanently remove the other capabilities. A discovery operation remains available while the immediate problem receives a smaller description. Reducing explanatory context and reducing execution permission are different purposes. Authorization still comes from the user request and host-side checks.
Derive descriptions from the actual contract
externalSchemas selects family members from the real ToolCall options and converts them to JSON Schema. That is easier to keep aligned than maintaining an unrelated handwritten copy of every field. Retrieving a schema does not start the operation it describes.
The MCP surface supplies northstar_tools with a family and, when needed, a name. A known name can narrow discovery further. Otherwise the caller reads the family before choosing. Discovery prepares the exact input contract for the next operation; it does not perform that operation itself.
A family label is not proof of permission or side effects
The reading family includes contracts for waiting, scrolling and selecting a tab as well as observation. Its name cannot establish that every member changes no state. Families organize discovery; the actual behavior and conditions require the individual contract.
Likewise all does not expose every internal function without limits. Blocked internal-agent repair tools remain excluded. A historical ToolCall member does not automatically become callable through the current external MCP. Classification and the actual allowed boundary need separate treatment.
Validate again after discovery
An agent can still construct invalid input after reading a schema. The real call supplies a task ID and call object and passes through ExternalRequest and ToolCall validation. A prior discovery event is not a ticket to skip checks at execution time.
The same applies to input retained from an older contract. Guessing new parameters or silently ignoring unknown fields would weaken the boundary. The caller must inspect and adapt to the current contract while the host checks current context and actual targets. Discovery and validation remain distinct responsibilities.
Check family membership and exclusions
The integration test checks that reading includes observe and excludes fill. It also verifies that all excludes internal repair and that arbitrary evaluation and an extra JavaScript field are rejected. For this article I compared that actual test code with the current filtering function.
I did not invoke a new model to measure tool-selection accuracy or a token-saving percentage. Smaller descriptions alone cannot establish a fixed speed improvement for an entire conversation. Repeatedly discovering unnecessary families could add overhead, so real workflow records still need inspection.
The cost of finding a capability is part of the product
Having many functions differs from finding the needed one easily. Agents face that problem too. A small entry surface followed by task-specific detail makes the relationship between explanation and execution clearer.
Another system need not copy this exact number of families. Group tools around actual usage and change boundaries, and derive descriptions from one executable contract. Record discovery success, operation success and workflow completion separately to learn where the structure actually helped.