Wire Up the First Real Tool
A four-step demo of the tool-calling loop; three tasks: pick a tool, write a three-line description, run the loop and deliberately break it once
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Wire Up the First Real Tool”?
A four-step demo of the tool-calling loop; three tasks: pick a tool, write a three-line description, run the loop and deliberately break it once
Follow the handoffs, not the demo. A system becomes dependable at the boundaries between model, tools, state, permissions, and people. Read each handoff as a place where you can observe, test, and recover.
Name the input, owner, approval, and recovery action for one automated step.
A successful run that cannot explain what happened or be safely repeated.
“Wiring up a tool” sounds like engineering. The chain is only four steps, and the model never executes anything — it just asks. The framework does the work. See these four steps and you’ll know which one to check when something breaks.
From the model asking to the result feeding back
The model asks
It outputs JSON: which tool, with what params
The framework validates params
Is the format right? Is the value legal? If not, bounce it back
Real execution
Query a database, send a request, write a file — this is the step that touches the real world
Result feeds back
The result goes back into the conversation. The model digests it, then talks like a human
How to pick the first tool
Three criteria, none optional: high frequency (you’ll almost always need it in your scenario), low risk (read-only first — checking weather or searching docs is safer than sending email), clear inputs and outputs (two or three params, a fixed return shape). This chapter covered the craft of tool descriptions: for the same function, a good description vs a bad one can triple the call success rate. So after you pick, write the description clearly before you talk about wiring it up.
This Chapter's Hands-on Checklist
0 / 3 done
Pick the first tool
15 min EveryoneUsing the three criteria above (high frequency, low risk, clear I/O), pick the first tool from your scenario and write down: tool name, one-line function, and what the two or three params are. If you can’t pick one, use “search my [whatever] docs” — it fits almost every scenario.
What counts as done
Write the tool description in three lines
1 hour If you want it called accuratelyLine 1: when to use this tool (also write when not to); Line 2: each param’s meaning, format, and an example value; Line 3: what it returns and what to do with the result. Then self-check from the “5 messages behind one conversation” lesson: the model decides how to call from these three lines alone. It cannot see your code.
What counts as done
Run one complete loop
Half a day Ready to actually build oneOn a platform you already use (Coze, Dify, Cursor, or just write code), actually wire this tool up. Ask a question that must use it, and watch all four steps finish. Then break it on purpose: ask something with vague params, see which step it sticks on and what feedback the user gets. This chapter covered five Agent deadlock patterns — you should see at least one with your own eyes.
What counts as done
The handoffs inside “See it first · One complete tool-calling loop”
““Wiring up a tool” sounds like engineering.” shows that an Agent is not defined by the model alone. Each handoff between model, context, tools, state, permissions, and people affects both progress and recovery.
Write the state before adding capability
Starting from “It outputs JSON: which tool, with what params”, split the workflow into starting state, next action, tool result, state update, and stop condition. Debugging then means finding the first lost piece of information or authority instead of saying vaguely that the model “got worse”.
A happy path is not reliability
Use “For M2, record: the tool’s name, how you wrote the description, and what the first successful run and the first stuck run looked like.” to replay one successful and one failed run. Record the context, tool result, and owner at each turn; the workflow is maintainable when a second person can follow it without the original builder.
From “See it first · One complete tool-calling loop” to “Hands-on checklist · Pick one, start it, tick it off”
“See it first · One complete tool-calling loop” grounds the problem in ““Wiring up a tool” sounds like engineering. The chain is only four steps, and the model never executes anything — it just asks. The framework does the work. See these four steps and you’ll know which one to che…”. “Hands-on checklist · Pick one, start it, tick it off” then moves it toward “Using the three criteria above (high frequency, low risk, clear I/O), pick the first tool from your scenario and write down: tool name, one-line function, and what the two or three params are. If you can’t pick…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
When analyzing an Agent, trace state, action, tool result, and next step in order. Each handoff should explain where information came from, who confirmed it, and where failure stops.
- “See it first · One complete tool-calling loop”: “Wiring up a tool” sounds like engineering. The chain is only four steps, and the model never executes anything — it just asks. The framework does the work. See these four steps and you’ll know which one to che…
- “Hands-on checklist · Pick one, start it, tick it off”: Using the three criteria above (high frequency, low risk, clear I/O), pick the first tool from your scenario and write down: tool name, one-line function, and what the two or three params are. If you can’t pick…
- “The closing point”: Line 1: when to use this tool (also write when not to); Line 2: each param’s meaning, format, and an example value; Line 3: what it returns and what to do with the result. Then self-check from the “5 messages b…
The final “The closing point” brings the discussion to “Line 1: when to use this tool (also write when not to); Line 2: each param’s meaning, format, and an example value; Line 3: what it returns and what to do with the result. Then self-check from the “5 messages b…”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.