The core idea
A model does not directly send UPI, edit your database, or call an API. It emits a structured tool request, then your app or the provider executes that tool and sends the result back.
Tools are how an agent acts. Without tools, the model can only answer from text it already has.
What counts as a tool
A tool can fetch data, run code, call an external API, use a computer, or call another agent. Current SDKs group tools in different ways, such as hosted tools, built-in execution tools, function tools, and agents-as-tools.
For this track, start simple. A function tool is enough: you wrap a local function with a JSON schema so the model knows its name, description, inputs, and expected output.
Tiny mental model
Imagine a campus event helper. A student asks, “What events are open today?” The model should not guess. It should call a tool that reads your events data.
The tool call is not the final answer. It is a request for your program to do work.
User: What events are open today?
Model returns a tool request:
{
"tool": "list_open_events",
"arguments": {
"date": "2026-09-21"
}
}
Your app runs list_open_events(date).
Tool result:
{
"events": ["AI project clinic", "Web dev sprint"]
}
Model returns final answer:
Today you can join AI project clinic or Web dev sprint.The basic loop
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Common wrong idea
Beginners often think the model “uses the API” by itself. Usually it does not. The model selects a tool and provides arguments. Your code is responsible for execution, errors, permissions, and logging.
Older tutorials may show tools only as function calling. That is incomplete now. Function tools are still useful, but modern agent platforms also include hosted tools, built-in execution tools, MCP tools, and agents-as-tools.
Name actions clearly
Tool names should sound like safe functions, not vague wishes. Use get_fee_status instead of handle_student. Use create_invoice_draft instead of do_payment.
A clear name and description help the model choose the right tool. They also help your reviewer understand your public repo quickly.
First repo note
Before writing SDK code, add a small design note. This makes your project easier to review and keeps your agent scoped.
Use this as a starting file in your repo.
File: docs/agent-tools.md
Project: Campus Event Helper
User goal:
Find open college events and draft a registration message.
Tools the agent may call:
1. list_open_events
Purpose: Read events available on a given date.
Inputs: date
Output: event names, timings, venue
2. get_event_details
Purpose: Get rules and registration deadline for one event.
Inputs: event_id
Output: rules, fee, deadline
3. draft_registration_message
Purpose: Draft a message the student can review before sending.
Inputs: student_name, event_id
Output: message text
Tools the agent must not call yet:
- send_message
- make_payment
- update_database
Why:
This first version can read and draft. It cannot take high-risk actions.Do this now
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done