The tool calling simulator
Take the step by step tool_use loop : the user message goes to the model,
the model emits a block
tool_use (a request , not an action!),
your code executes the actual call, returns a tool_result , and the model produces its final response.
⭐ “The model does not run Never Nothing. It issues a structured query.
Your code executes the actual call — with your permissions, your validation, your logging. »
🙋Message
user
user
🧠The model
thinks
thinks
📨Block
tool_use
tool_use
🔧Your code
executed
executed
📬tool_result
returned
returned
💬Answer
final
final
Choose a scenario then click “Next step”. Each step is commented here.
The workshop: build a tool definition
A tool definition has three elements: a name , a description
(which is a prompt : the road model while reading it!) and a input_schema
(JSON Schema — standard for describing JSON structures).
Drag and drop the left pieces into the right slots. Please note: some parts are traps — the workshop will tell you.
Drag and drop the left pieces into the right slots. Please note: some parts are traps — the workshop will tell you.
Objective: the 🗄️ search_client tool
3 rules: one thing · clear name · documented borderline cases
🧰 Parts available
Tip: Read each piece as the model would. Which one would allow you to route well?
🏗️ Your tool definition
name — the technical identifier
description — instructions for use (it’s a prompt!)
input_schema — parameters (several parts possible)
Live JSON preview
{ }
Safety checklist: before exposing a tool
The principle of least privilege (principle of least privilege): only display the tools
whose agent has strictly need. Every tool is a door that you open —
go through this checklist to each tool , before any production.
Click on an item to validate it (and read why it matters).