A tool is a sentence about a tool

Put yourself where the model is. Your input is a sequence of tokens. Somewhere in it is a list of things you may call. In this example, the implementation is hidden; you see its declared interface.

You have the name, a sentence, and a parameter list. You choose by reading.

Switch the descriptions from careful to careless and watch the choice fall apart.

Try it

go to public fact and switch to careless. Two different tools now say “search stuff”. The descriptions no longer explain which tool is suited to the request.

The interface is prose

The model uses a tool’s name, description, and parameter schema to decide when and how to call it. The description explains what the tool does; the schema defines the inputs it accepts. If the description omits an important capability, the model may overlook the right tool.

So the failure mode is not a crash. quarter_revenue sat right there in the list and was passed over, because “does numbers” never claimed to be the thing that knows revenue. You get a worse answer and no error.

Which makes the practical rules fall out of the setup rather than out of taste:

• One tool, one job. A tool that searches and summarises is harder to describe honestly, so it is harder to choose correctly.
• Say when not to use it. The model is discriminating between candidates, so the useful sentence is the one that rules the others out.
• Make errors legible. Invalid date format, expected YYYY-MM-DD tells the model what to change. Error 400 leaves it to guess.

Structure, so the call cannot be misread

Early agents wrote prose — “I will now search for the weather in Philadelphia” — and the harness pattern-matched it back into a function call. That parse is guesswork, and it fails on phrasing the author never anticipated.

The fix is to have the model emit the call in a fixed shape, validated against a schema that declares each parameter’s type and whether it is required:

weather_current(location="San Francisco", units="imperial")

Look at what the model actually contributed. The user typed “check for rain in SF”. Nowhere in that is a value the schema will accept. The model’s real job here is turning loose human phrasing into something a strict parameter list will take — and marking units optional matters, because a required field the user never mentioned is a field the model has to invent.

Go deeper: tools compose without anyone arranging it

“What’s the weather where Einstein was born?” needs two tools in order: find the birthplace, then look up the weather there. Nobody wires that pipeline.

It falls out of the loop from the last chapter. Search returns Ulm, Germany; the observation lands in the prompt; the next thought now has a place name; the next action is a weather call. The thought between the calls is the join — which is exactly what the act-only trace was missing.

Today

Frontier models are trained on tool-use transcripts, so emitting a well-formed call against an unfamiliar schema is a learned skill rather than a prompting trick — which is what makes the next chapter possible.

Every tool so far was one you chose in advance. The next chapter shows how to supply descriptions of tools introduced after the model was trained.

Sources · 2

1. Yao, Shunyu, et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023; arXiv:2210.03629.
2. Anthropic. “Model Context Protocol — specification.” modelcontextprotocol.io (accessed 2026).

Full bibliography →