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. The microwave from last lesson wants a power level and a time. A calendar won't accept "sometime Tuesday" — it wants a date, a start time, and a duration. An email won't send without an address.
These are the tool's parameters: the inputs a tool requires before it can act at all.
Two tools, spelled out
schedule_meeting( date, start: 24-hour HH:MM, duration: whole minutes, title )
send_email( to: email address, subject, body )
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 calendar, four honest contracts
- Why is "2:30 PM" a perfectly good answer for calendar B and a meaningless one for calendar A?
- What happens to the conversation if the LLM starts issuing "2:30 PM" commands at calendar 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 writing times 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.)
You have the following tools available for use:
- find_free_slot( date, duration: whole minutes )
- schedule_meeting( date, start: 24-hour HH:MM, duration: whole minutes, title )
- send_email( to: email address, subject, body )
Task: Schedule a 45-minute project check-in with Ingrid and Tomas next Tuesday, June 9, and email them both the details. Their addresses: ingrid@uio.no and tomas@ntnu.no.
Rules: the same five rules as before.
Step 1: Use find_free_slot( 2026-06-09, 45 ) - Find an opening before promising anyone a time.
The calendar returns one free slot: 10:15.
Step 2: Use schedule_meeting( 2026-06-09, 10:15, 45, Project check-in ) - Booking the slot we just found.
The meeting is created.
Step 3: Use send_email( ingrid@uio.no, Project check-in Tuesday, "Hi Ingrid — our check-in is Tuesday June 9, 10:15–11:00. See you then." ) - One participant at a time.
The email to Ingrid was sent.
Step 4: Use send_email( tomas@ntnu.no, Project check-in Tuesday, "Hi Tomas — our check-in is Tuesday June 9, 10:15–11:00. See you then." ) - And the second participant.
The email to Tomas was sent.
END
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, say, the escape systems of an alien spaceship:
You have the following tools available for use:
- cook_alien_pizza( toppings )
- play_beatles_music( song )
- open_dimensional_portal( destination on Earth )
Descriptions: cook_alien_pizza bakes one pizza in the ship's galley synthesizer — Zorblaxian guards cannot resist the smell and will leave their posts to investigate. play_beatles_music plays one song over the ship-wide speakers; Beatles harmonies put Zorblaxians into a trance for exactly 3 minutes. open_dimensional_portal opens a portal in the cargo bay for 30 seconds, and takes 2 minutes to charge — the charging whine is loud enough to alert any guard nearby.
Task: I am locked in the cargo bay's holding cell, the cell door unlatches from outside the bay, and two guards are posted here. Get me back to Earth.
Rules: the same five rules.
Step 1: Use cook_alien_pizza( quadruple gloop-cheese ) - The smell will pull both cargo-bay guards to the galley, on the far side of the ship — and someone leaving usually unlatches the cell to gloat first. Tell me what happens.
The synthesizer hums. Both guards sniff the air, unlatch my cell to taunt me about pizza, and hurry out toward the galley.
Step 2: Use play_beatles_music( Here Comes the Sun ) - Three minutes of trance covers the portal's two-minute charging whine — even if the pizza brings them back early.
The speakers ring out. Somewhere down the corridor, two Zorblaxians are swaying and humming along.
Step 3: Use open_dimensional_portal( Nashville, Tennessee ) - Charged under cover of the trance. You have 30 seconds — run.
A shimmering portal opens in the cargo bay. I jump through — I'm standing on Broadway in Nashville, Tennessee.
END
- List three things the agent "knew" about the ship's tools. Point to the words in the conversation each one came from.
- Why did the music come BEFORE the portal? Which two description details make that ordering necessary?
- 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.