TL;DR
The model never sees your function's source code. It sees a schema: a name, a plain-English description, and a typed parameter list. From that schema alone it decides whether the tool fits and what arguments to pass. The description is load-bearing — vague descriptions make the model guess; precise ones tell it exactly when and how to call.
The idea
When you register a tool, you don't hand the model your code. You hand it a schema — a structured description of the tool's interface:
{
"name": "calculator",
"description": "Evaluate a basic arithmetic expression. Supports digits, + - * / and parentheses only.",
"input_schema": {
"type": "object",
"properties": {
"expression": { "type": "string", "description": "e.g. \"(47362 * 1989) / 7\"" }
},
"required": ["expression"]
}
}
That's everything the model knows about the tool. It picks a tool by reading descriptions and matching them to the user's request, then fills in arguments that satisfy the typed parameter list.
Why the description is load-bearing
Same code on your side; wildly different behavior from the model — driven entirely by the words in the description.
| Description | What the model does |
|---|---|
| "does math" | Guesses. Calls it for things it shouldn't, skips it when it should. |
| "Evaluate a basic arithmetic expression — digits, + - * / and parentheses only" | Calls it for exactly the right requests, with a clean expression. |
The typed parameters do the matching for inputs. If expression is declared as
a string, the model won't pass a number; if it's required, the model knows it
can't omit it. The schema is a contract — and unlike a code comment, this contract
is read by the model, on every turn, to decide what to do.
Analogy
A schema is a job posting written for the model. A vague posting ("help with stuff") attracts the wrong applicants for the wrong tasks. A sharp posting ("evaluate arithmetic expressions; inputs: one expression string") gets you exactly the right call at exactly the right moment.
Try it yourself
Below is a calculator tool with an editable description. Change the wording,
hit Run, and watch whether the model decides to call the tool at all. A clear
description gets called; a vague one might get skipped entirely — even though the
underlying code never changed.
Common mistake
When two tools have overlapping descriptions, the model can't tell them apart and picks unpredictably — or calls the wrong one. The fix is in the schema, not the code: make each description state what makes this tool different ("look up an account by email" vs. "look up an account by order ID"). Distinct descriptions, distinct jobs.
Key takeaways
Key takeaways
- The model sees a schema (name, description, typed inputs), never your code.
- The description decides when and whether the tool is called — write it precisely.
- Typed,
requiredparameters constrain the arguments the model may pass. - Overlapping descriptions confuse the model; make each one distinct.
Go deeper: why typed inputs beat free-form text
You could ask the model to "just write the SQL" or "just give me the email body" as plain text. Typed input schemas are better for three reasons:
- Validation. A typed schema lets your code reject malformed calls before
running anything — a missing
requiredfield fails fast instead of halfway through. - Fewer degrees of freedom. The narrower the input, the less the model can
get creative in ways you didn't intend.
{ "order_id": "string" }is much harder to misuse than "describe what you want to look up." - Portability. The same JSON-Schema shape is understood across providers and tooling, so your tool definitions travel.
Rule of thumb: make the input schema as narrow as the task allows. Every optional, loosely-typed field is a place the model can wander.