Module 1 · Foundations of Agentic AI · scripted
Tool Parameters and Descriptions
Tools have controls
Declaring which tools exist bounds what actions the agent can take. But a real tool also constrains how it may be used. A microwave doesn't accept "warm it gently" — it accepts a power level and a time. An oven wants a temperature, a rack position, and which heating elements are on: top, bottom, or both.
These are the tool's parameters: the inputs a tool requires before it can act at all.
Two tools, spelled out
Say exactly what the tool accepts
Here is where precision starts to matter enormously. How a parameter must be expressed depends on the actual tool — and the LLM can only know what the conversation tells it:
The same microwave, four honest descriptions
- Why is "power 60%" a perfectly good answer for microwave B and a meaningless one for microwave A?
- What happens to the conversation if the LLM starts issuing "power 60%" commands at microwave A?
Why be this careful? Because of everything we know about trajectories. At the start of the conversation, we want to provide enough information that the LLM heads off on a trajectory that leads efficiently to a correct solution. If it begins specifying power levels in a format the tool doesn't accept, those invalid actions are now in the conversation — conditioning what comes next, costing correction turns, and bending the trajectory. (There are ways to catch and repair invalid tool use, which come later — but repair is always the expensive path. Precision up front is the cheap one.)
Reheat my leftover fiskesuppe. Tools: MICROWAVE (power: integer 1–5; time: seconds). It's a creamy soup, so be gentle — high power splits the cream.
Gentle it is: microwave at power 2 for 90 seconds, then stir and tell me how it feels — we'd rather sneak up on hot than split the cream.
Stirred. Warm at the edges, cold in the middle.
Classic microwave cold spot. Power 2 for another 60 seconds, stir again. If it's still not hot after this round, we'll go to power 3 in 30-second bursts.
Tools the LLM has never heard of
There is a second thing every tool may need: a description. Not all tools are well known to the LLM. It has never seen your lab's equipment, your company's internal software — or the gadget you bought from a TV offer last month, which did not exist when the model was trained:
New tool in my kitchen. GRILLVENN G-1: a countertop gadget that clamps around a fish fillet and cooks it from both sides at once between two ribbed ceramic plates. Parameters — plates_temp: LOW | MED | HIGH; clamp_time: whole minutes, 1–10. It beeps when done and must rest closed for 1 minute after beeping before opening. Now: cook my salmon fillet with it.
Understood — the GRILLVENN does the whole job, both sides at once, so there's no flipping step. For a standard fillet: plates_temp MED, clamp_time 4 minutes. When it beeps, don't open it — let it rest closed for its 1 minute so the juices settle. Then open and check the center; if it needs more, we'll clamp again at LOW for 1 minute rather than re-firing at MED.
- List three things the agent "knew" about the GRILLVENN. Point to the words in the conversation each one came from.
- What would the agent have done with "GRILLVENN G-1" and no description?
- Which of your own domain's tools would an LLM genuinely know — and which only feel well-known to you?
So a tool, fully stated, has three parts: a name, a description of what it does and how it behaves, and parameters with exactly what values they accept. Get those three right in the conversation, and the agent's actions arrive legal, precise, and executable — which is exactly what we'll need when the participant performing the actions stops being a patient human and becomes a computer.
Take one real tool from your research — an instrument, a dataset query, a piece of software. Write its name, description, and parameters precisely enough that an LLM could operate it without a single invalid action. Then test it: give the spec and a goal to an LLM, and audit every action it proposes against your spec.