Tools and Structured Outputs

Fact-check status

Reviewed claim by claim on 2026-09-02 against the primary or official sources identified inline as S1 and S2. Recommendations are design guidance unless a cited standard makes them normative.

Key jargon

Term	Plain-language meaning
Tool schema	A machine-readable contract describing an operation and its arguments. S1
Structured output	Model output constrained to a defined data shape such as JSON Schema. S1
Validation	Checking types, ranges, formats, and invariants before data is used. S1
Tool result	The trusted application's report of what happened after execution. S1

Key concepts

A model emits a candidate tool request; it does not execute the tool by merely naming it. S1
Schema validity is necessary but does not establish authorization or business correctness. S1

Concept map

flowchart LR
    A["Model proposes structured call"] --> B["Validate schema"]
    B --> C["Authorize and execute"]
    C --> D["Return observed result"]

Diagram semantics verified against S1 and S2 on 2026-09-02.

A tool definition is an interface contract, not permission. The model may propose a call; the harness authenticates, authorizes, validates, executes, and records it. S1

Tool contract

Field	Purpose
Name and description	Make intended use unambiguous S1
Input schema	Constrain arguments and types S1
Identity	Bind user, tenant, and workload S1
Authorization	Check this action on this resource now S1
Side-effect class	Read, create, update, delete, communicate, purchase S1
Idempotency/effect key	Prevent accidental duplicate effects S1
Timeout and error model	Support predictable recovery S1
Output schema	Separate trusted result from display text S1

Validate model-produced JSON with a real schema. Then validate business semantics: a syntactically valid transfer or deletion can still be unauthorized. S1

Exercise

Design a read-only lookup_order tool. Include allowed fields, tenant binding, timeout, error codes, logging, and data minimization.