← Table of Contents · Page 138 of 868
WHAT TOOLS ARE
Part 3 of 8
INPUT AND OUTPUT SCHEMAS
If the model and the harness are going to exchange tool requests and replies reliably, they must agree on the exact shape of those messages.
That agreement is the schema.
A schema is a formal description of a structure: which fields exist, what type each field holds, which fields are required, and what values are allowed.
Imagine a paper form with labeled boxes.
The Name box takes words, the Age box takes a number, and the Email box expects something with an at symbol.
A schema is the blank form, and a tool call is the filled-out form.
An input schema describes what a tool needs.
For example, a get_stock_price tool might require one field called ticker, which is a text string of one to five capital letters.
An output schema describes what the tool promises to return.
The same tool might promise a number called price and a text field called currency.
Good schemas pay off in many ways.
They let the harness validate inputs before running anything, rejecting a request that is missing a required field or has the wrong type.
They help the model understand how to use the tool, since the schema is usually shown to the model as part of the tool description.
They allow outputs to be parsed reliably.
Parsing means reading a structured piece of data and splitting it into its named parts.
A particularly valuable benefit is stability: the harness can swap the provider behind a tool while the output schema stays the same, so nothing the agent relies on changes.
Careful schema design includes constraints such as minimum and maximum values, lists of allowed choices, and patterns for text.
A field that accepts any text at all, for a purpose that needs a specific format, is a common weakness.
For example, a delete tool that takes a free-text "target" field could be tricked into deleting the wrong thing, whereas one that takes a specific record identifier in a specific format is much harder to misuse.
Advertisement
Read Aloud:
0:00 / 0:00