The concept
Yesterday (Day 37): the model asks, your app runs the tool. Today: what makes a tool easy for a model to use correctly, and hard to misuse.
Think of each tool as a job description for a new hire who reads only that page. Vague page, vague work.
Walkthrough: a bank's customer assistant
Bad design: one tool that does everything.
do_banking(action, data)
"Performs banking operations."
What goes wrong:
- The model must invent the "action" names. Is it "balance", "get_balance" or "check"?
- "data" could be anything, so mistakes show up only when something fails.
- The same tool that reads a balance can also move money. One wrong guess becomes a real transfer.
Good design: small tools that each do one clear job.
get_account_balance(account_id)
"Returns the current and available balance for one account the signed-in customer owns."
list_recent_transactions(account_id, days)
"Returns transactions from the last N days. days: whole number from 1 to 90."
Now a customer asks: "Did my $120 gym payment go through this week?"
- The model calls list_recent_transactions(account_id="CHK-01", days=7).
- Clear name, typed inputs, limits stated. Little room to guess.
Five design rules
- Clear names: verb plus object, like get_account_balance.
- Good descriptions: what it does, when to use it, what it returns.
- Typed inputs: say "whole number from 1 to 90", not just "data".
- Helpful errors: "days must be 1 to 90; you sent 365" lets the agent fix itself. "Error 500" doesn't.
- Least privilege: give only the access the job needs. Read-only tools for questions. A money-moving tool like transfer_funds lives separately, with limits and a human confirmation step.
Where you see it at work
- Banking: separating read tools from payment tools maps to the access controls auditors already expect.
- Insurance: get_claim_status and update_claim_reserve should never be the same tool.
- Healthcare: a scheduling tool shouldn't be able to read full medical records.
- Business analysts and product owners: write each tool like a user story, with inputs, outputs, error messages and who's allowed to call it.
In one sentence
Give an agent small, clearly named tools with typed inputs, helpful errors and only the access each job needs, and it will guess less and break less.