Tool Use in Agentic AI

Steroids for LLMs.

From Chatbots to Agents

A chatbot answers questions.

An agent can:

• Observe
• Reason
• Retrieve
• Decide
• Act

Tool use is the bridge between language understanding and real-world execution.

Without tools:

$$Agent \approx Chatbot$$

With tools:

$$Agent \approx Reasoning + Actions$$

And that is why tool use has become one of the foundational building blocks of modern Agentic AI systems.

How LLMs Interact with the Real World

Large Language Models are impressive.

They can write code, summarize documents, explain quantum mechanics, and generate human-like conversations.

But despite these capabilities, a standalone LLM has a fundamental limitation:

It cannot interact with the outside world.

An LLM does not know:

• Online information
• Database Items
• Calendar events
• Email status
• File contents

These limitations arise because the model can only reason over:

• Training data
• User prompts
• Provided context

Without tools, an LLM operates as:

$$Response = LLM(Prompt)$$

This is where Tool Use transforms an LLM from a chatbot into an agent.

With tools:

$$Response = LLM(Prompt + ExternalData)$$

The difference is profound.

The model no longer relies solely on its training data.

Instead, it becomes capable of:

• Retrieving live information
• Executing actions
• Interacting with enterprise systems
• Orchestrating workflows

---

What Is Tool Use?

Tool use is the ability of an LLM to request the execution of external functions.

Instead of answering directly, the model can decide:

"I need additional information before I can answer."

The workflow becomes:

sequenceDiagram
    participant User
    participant LLM
    participant Tool

    User->>LLM: What is the weather in Munich?
    LLM->>Tool: get_weather("Munich")
    Tool-->>LLM: 21°C Sunny
    LLM-->>User: It is 21°C and sunny.

This enables access to:

• APIs
• Databases
• Search engines
• File systems
• Internal business systems
• Tools: calculators, calendars

The Tool Calling Architecture

Modern agent systems typically follow this pattern:

graph LR

    U[User Request]

    U --> L[LLM]

    L --> T1[Weather API]
    L --> T2[Database]
    L --> T3[Calendar]
    L --> T4[Calculator]

    T1 --> L
    T2 --> L
    T3 --> L
    T4 --> L

    L --> R[Final Response]

The LLM acts as an orchestration layer.

Tools provide capabilities.

Tool Use vs Retrieval-Augmented Generation

Tool use extends beyond information retrieval. It enables action.

These concepts are often confused.

RAG:

Retrieve Information

Tool Use:

Retrieve Information
+
Take Actions

Difference

Capability	RAG	Tool Use
Search documents	✓	✓
Query databases	✓	✓
Create meetings	✗	✓
Send emails	✗	✓
Update records	✗	✓
Execute workflows	✗	✓

---

A Simple Weather Agent

Consider a user asking:

What's the weather in Munich today?

The model cannot know the current weather.

However, we can provide a weather function.

Full Execution Flow

The LLM does not execute functions.

The LLM only requests function execution.

Developer provides function, LLM decides to use it, LLM outputs request, developer’s system executes the function, result fed back to LLM

sequenceDiagram
    participant User
    participant LLM
    participant App
    participant WeatherAPI

    User->>LLM: Weather in Munich?

    LLM->>App: Call get_weather(Munich)

    App->>WeatherAPI: Request weather

    WeatherAPI-->>App: 21°C Sunny

    App-->>LLM: Tool Result

    LLM-->>User: It is 21°C and sunny.

The Critical Detail Most Beginners Miss

Notice that the model never directly talks to the API.

The application remains in control.

For example, the model may return:

{
  "tool_calls": [
    {
      "function": {
        "name": "get_weather",
        "arguments": {
          "city": "Munich"
        }
      }
    }
  ]
}

This means:

Please call get_weather("Munich")

Your application executes the function.

The result is then returned to the model.

Tool Definition

The function acts as a bridge between the model and external systems.

def get_weather(city: str):

    return {
        "city": city,
        "temperature": 21,
        "condition": "Sunny"
    }

Defining Tools for OpenAI Models

Modern LLM APIs allow developers to expose functions as tools.

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get current weather",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {
                        "type": "string"
                    }
                },
                "required": ["city"]
            }
        }
    }
]

The schema describes:

• tool name
• purpose
• parameters
• expected inputs

This information is provided to the model.

Implementing Tool Execution

response = client.chat.completions.create(
    model="gpt-4.1",
    messages=messages,
    tools=tools
)

If the model requests a tool:

tool_call = response.choices[0].message.tool_calls[0]

city = json.loads(
    tool_call.function.arguments
)["city"]

result = get_weather(city)

Then return the tool result:

messages.append(
    {
        "role": "tool",
        "content": json.dumps(result)
    }
)

Finally:

final_response = client.chat.completions.create(
    model="gpt-4.1",
    messages=messages
)

The model now has access to live weather data.

---

Multi-Tool Agents

Real agents rarely use a single tool.

Consider a calendar assistant.

Available tools:

check_calendar()
create_meeting()
cancel_meeting()

User request:

Schedule a meeting with Alice on Thursday.

Execution plan:

sequenceDiagram
    participant User
    participant LLM
    participant CalendarAPI

    User->>LLM: Schedule meeting with Alice on Thursday.

    LLM->>CalendarAPI: check_calendar(Thursday)

    CalendarAPI-->>LLM: Available slots

    LLM->>CalendarAPI: create_meeting(Alice, Thursday 3pm)

    CalendarAPI-->>LLM: Meeting created

    LLM-->>User: Meeting scheduled for Thursday at 3pm.

The LLM decides:

1. Which tool to call
2. In what order
3. Which parameters to provide

This is where simple tool use evolves into an agentic workflow.

Tool Chaining

Advanced agents often perform multiple tool calls.

Example:

Find a free slot tomorrow and schedule a meeting with Alice.

The agent might execute:

sequenceDiagram
    participant User
    participant LLM
    participant CalendarAPI

    User->>LLM: Schedule meeting with Alice tomorrow.

    LLM->>CalendarAPI: check_calendar(tomorrow)

    CalendarAPI-->>LLM: Available slots

    LLM->>CalendarAPI: create_meeting(Alice, tomorrow 2pm)

    CalendarAPI-->>LLM: Meeting created

    LLM-->>User: Meeting scheduled for tomorrow at 2pm.

This creates a chain of actions.

Formally:

$$Task = {t_1, t_2, t_3, ..., t_n}$$

where each tool output becomes the input to the next step.

---

Enterprise Tool Use

Most production agents operate against internal systems.

Common tools include:

Tool	Purpose
CRM API	Customer lookup
Inventory API	Product availability
Billing API	Payment status
Search Engine	External information
Vector Database	Semantic retrieval
Calendar API	Scheduling
Ticketing System	Incident management
GitHub API	Repository operations

This is why tool use is foundational to enterprise AI.

Security Considerations

Tool use introduces risk.

Consider:

Delete all customer accounts.

If a destructive tool is exposed without controls, the consequences can be severe.

A common pattern is:

graph TD

    A[Tool Request]

    A --> B{Safe?}

    B -->|Yes| C[Execute]

    B -->|No| D[Human Approval]

Production systems often require:

• approval workflows
• permission boundaries
• audit logging
• rate limiting

before allowing sensitive actions.

---

Model Context Protocol

MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.

• MCP provides a standardized way to connect AI applications to external systems.