The moment a schema stops being documentation and starts actually shaping what a model decides to do.
1The tools Field Changes What a Model Can Return
Passing a tools array in a chat completion request tells the model it's allowed to respond with a structured tool_calls entry instead of plain text, whenever it judges a tool would answer the question better than generating text alone. The model itself decides — you're offering options, not issuing a command.
2Tool Selection Is Entirely Schema-Driven
The model has no access to your handler code, your registry, or your data — only the name, description, and parameters you send in the tools array. This is exactly why the schema-writing work from Module 1 matters: a vague description leads directly to the model picking the wrong tool, or no tool at all.
3Step-by-Step Breakdown
Handing Your Tools to a Real Model. A model can only decide to call a tool if it's actually told the tool exists. This lesson sends your real read_file and list_files schemas to a live model alongside a real question — watch it decide, on its own, which tool (if any) to call first.
Watch a Real Model Choose a Tool. Ask about the project's files with both real tools available. Look at the response closely: instead of text, a well-behaved model returns a tool_calls entry naming exactly one of your tools with concrete arguments — it decided list_files is the right first step, without being told which tool to use.
The model was never told 'use the list_files tool.' How did it decide to call it instead of just answering in plain text?
- →It reasoned from each tool's name, description, and schema that list_files matched the question better than answering from its own (nonexistent) knowledge of your project's files.
- →The API silently forces every request that mentions a folder to trigger a tool call.
A Decision, Not Yet an Answer. The model decided to call a tool — but nothing actually ran yet. It just produced a tool_calls entry describing what it wants. Your server still has to parse that, run the real handler, and get a real result. Next lesson: doing exactly that.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Surface Which Tool Was Called in Any Chat UI
When a model's turn is a tool call rather than a text reply, render that explicitly (e.g. 'Called list_files') rather than showing a blank or loading state with no explanation.
<span>🔧 Called list_files(prefix="src/")</span>SEO Implications
- 1
Target 'OpenAI function calling tutorial' and 'MCP tool selection example' separately
Developers search for the underlying API mechanic and the MCP-specific schema-to-tool-call flow as distinct concerns.
Best Practices
Offer Only the Tools Relevant to the Current Task
Sending every tool your server has on every request gives the model more chances to pick the wrong one — scope the tools array down when you already know the likely task.
Frequent Bugs
Assuming a tool_calls response means the tool already ran.
A tool call is only the model's request to run something — your code still has to parse it, execute the real handler, and feed the result back before there's a final answer.
Real-World Examples
Multi-Tool Assistants
A coding assistant offered read_file, run_tests, and git_log at once relies entirely on well-written descriptions to pick the right one per question — ambiguous descriptions measurably increase wrong-tool selections.
tools = [read_file, run_tests, git_log]