Function and Tool Calling: How AI Agents Use Real Capabilities

Learning outcome: By the end of Day 8, you will understand how an agent selects a tool, supplies its inputs, receives the result, and continues the task.

This lesson is part of the AI Agents in 30 Days roadmap.

An AI model can explain how to calculate something, but your application may need the actual result. It may also need current information, private data, or permission to perform an action.

That is where function and tool calling comes in.

The most useful mental model is:

The model chooses. Your application executes.

The model does not automatically gain access to your database, calculator, or API. You describe the tools it may request. When the model decides a tool is needed, it returns a structured tool call containing the tool name and arguments. Your application validates that request, runs the corresponding code, and returns the result.

OpenAI describes function calls as model-generated requests to use one of the tools provided by an application. The application must execute the function and return its output before the model continues. See the current OpenAI function-calling guide. Anthropic documents the same client-tool boundary: the model returns a structured request, the application executes it, and the result is sent back. See Anthropic's tool-use overview.

The tool-calling loop

Tool calling is a controlled round trip:

1. Your application sends the user's request and a list of available tool definitions to the model.

2. The model either answers normally or requests one or more tools.

3. Your application checks the tool name and arguments.

4. Your code executes the allowed function.

5. The tool returns data or an error.

6. Your application sends that result back to the model.

7. The model uses the result to continue or produce the final answer.

The model is responsible for choosing. Your application remains responsible for permissions, validation, execution, timeouts, and error handling.

Practical example: a study-planner agent

Imagine a learner asks:

Which assignment is due first?

Without access to the learner's saved deadlines, the model should not invent an answer. A study-planner agent can instead request a local-data tool:

Tool: getUpcomingDeadlines
Purpose: Fetch assignments saved for one student
Input: studentId
Output: A list of assignment titles and due dates

The sequence becomes:

Student question
    ↓
Model requests getUpcomingDeadlines(studentId)
    ↓
Application validates student access
    ↓
Database lookup returns saved deadlines
    ↓
Model identifies the earliest deadline and revises the study plan

The tool supplies the evidence. The model turns that evidence into a useful explanation or plan.

A completed tool definition

Here is a simplified TypeScript-shaped example. The exact API syntax varies between providers, but the contract remains the same.

const getUpcomingDeadlinesTool = {
  type: "function",
  name: "getUpcomingDeadlines",
  description: "Return upcoming assignments saved for a student.",
  parameters: {
    type: "object",
    properties: {
      studentId: {
        type: "string",
        description: "The authenticated student's internal ID."
      }
    },
    required: ["studentId"],
    additionalProperties: false
  }
};

Your application might execute the requested tool like this:

async function executeTool(name: string, args: unknown) {
  if (name !== "getUpcomingDeadlines") {
    throw new Error("Tool is not allowed");
  }

  const input = validateDeadlineInput(args);
  authorizeStudent(input.studentId);

  return deadlineRepository.findUpcoming(input.studentId);
}

Notice what the model does not control. It does not choose arbitrary code, bypass authorization, or directly connect to the database. It requests a named capability exposed by the application.

Function calling versus structured outputs

Day 7 covered structured outputs. The two concepts are related, but they solve different problems.

A tool call itself is structured, but its purpose is to ask another part of the system to do something.

Try this today

Design one tool for an agent you want to build. Write four fields:

1. Name: What should the function be called?

2. Purpose: When should the agent use it?

3. Inputs: What information is required?

4. Output: What data or error can it return?

Completed example:

Name: calculateStudySessions
Purpose: Calculate how many equal study sessions fit into a time budget
Inputs: availableMinutes, sessionMinutes
Output: { sessionCount, unusedMinutes }

Optional build exercise: implement the function, return sample JSON, and test three cases - a valid request, invalid input, and a tool execution error.

Common mistakes

1. Giving the model too many vague tools

Overlapping names and weak descriptions make tool selection harder. Prefer a small set of clearly differentiated capabilities.

2. Trusting tool arguments without validation

Model-generated arguments are application inputs. Validate types, ranges, permissions, and ownership before execution.

3. Returning unhelpful errors

If a tool fails, return a clear machine-readable error that helps the agent decide whether to retry, ask the user, or stop.

4. Letting the model control secrets

Keep API keys and credentials inside your trusted application environment. A tool can use them internally without exposing them to the model or user.

5. Treating every question as a tool call

Tools add latency and failure modes. Let the model answer directly when the required information is already available and no external action is needed.

Quick knowledge check

1. Does the model directly execute a client-side function?
No. It requests the function; your application validates and executes it.

2. What should a good tool definition contain?
A clear name, purpose, input schema, and expected result.

3. What should happen when a tool fails?
Return a clear error so the system can retry safely, ask for help, or stop.

4. When should you avoid a tool call?
When the model can answer from information already in context, and no external capability is required.

Continue learning with Korshub

Korshub helps learners discover courses and course deals across multiple learning platforms. If you want a deeper course on AI agents, APIs, or application development, explore current listings on Korshub and continue to the official course platform when you are ready to enroll. Availability and pricing can change, so review the current course page before purchasing.

Series navigation

• Previous: Day 7 - Structured Outputs

• Roadmap: AI Agents in 30 Days

• Next: Day 9 - Memory and Sessions will be linked after publication.