Function Calling & Tool Use
You'll learn to
- -Understand how an LLM selects and calls a tool
- -Design a tool schema an LLM can use reliably
- -Implement schema validation that catches an incomplete or dangerous call before it runs
Everything covered so far generates text. This tier is about generating action. Analysts want to ask a database question in plain English and get a real SQL query executed, not a paragraph describing what a query might look like. That gap, from "the model describes what it would do" to "the model actually does it", is exactly what function calling closes.
A Tool Definition Is an API Contract for the Model
A tool schema tells the model three things: the tool's name, what it does in plain language, and exactly what parameters it accepts, including which ones are required and what type each one is. The model never executes anything directly. It outputs a structured request to call a specific tool with specific arguments, and the surrounding system is the one that actually runs it.
This is the same shape as a REST API contract. The tool schema is the model-facing equivalent of an OpenAPI spec: name, description, parameters, types. The model reads the contract and decides when and how to use it, the same way a developer reads API docs before writing a call.
Why the Naive Version Fails
A team building natural-language-to-SQL might start by just asking the model to generate a SQL query as plain text, with no schema at all. That version hallucinates column names constantly, since the model has no idea what the actual database schema looks like. Feeding the real table and column names into the prompt, and having the model call a defined run_sql_query tool rather than free-hand generating a query string, is a large, measurable accuracy jump: this is precisely the gap the level 21 case brief centers on, where accuracy moves from roughly 40% to 85% or higher once the schema is actually given to the model instead of assumed.
Validation Is Not Optional
The model can hallucinate a tool call the same way it can hallucinate a fact: a parameter with the wrong type, a required field left out entirely, or a value that technically parses but is unsafe to execute. The fix is strict, boring, and non-negotiable: check the model's proposed call against the tool's real schema before anything runs, and reject the call if it does not match, rather than trusting it and hoping for the best.
Pick a request below and watch the extracted parameters get checked against a real schema, live.
Schema Validation Catching a Bad Tool Call
Pick a request and watch the extracted parameters get checked against the tool's real schema, live.
User request
"Show me all orders over $500 from the sales database"
Selected tool
run_sql_query(...)
Schema requires
- query: string
- database: string
Extracted parameters
{
"query": "SELECT * FROM orders WHERE amount > 500",
"database": "sales_db"
}Every required field is present with a usable value. The system can safely call the real tool.
Strict validation is a safety boundary, not just a correctness check. An unvalidated DELETE query with no WHERE clause, or a missing database name that defaults to production, is exactly the kind of failure that turns a hallucinated tool call into real, expensive damage. Reject first, ask the model to retry with a clearer error message second.
Bounding Cost and Risk
- -Set a timeout on every tool call. A hung database query or a stuck external API should not hang the whole agent.
- -Use a low temperature for tool selection and parameter extraction specifically. This is a precision task, not a creative one, and the level 21 case brief's own guidance is explicit about this.
- -Log every tool call and its result. When a tool call goes wrong, this is the only real record of what the model actually attempted.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.