Back to M3 — Tool-Calling Lite + Capstone

Tool-Calling / Single-Agent Loop Lite

Outcome: Wire one function-call agent over the retriever Curated video (IBM Technology): What is Tool Calling? Connecting LLMs to Your Data — https://www.youtube.com/watch?v=h8gMhXYAv1k (verified live via yt-dlp 2026-09-24). Pointer: agent-loop skeleton (starter); shell: courses/video-scripts/genai-rag-agents/04.md.

5 minutesVideo LessonPDF notes

Watch Tool-Calling / Single-Agent Loop Lite on YouTube

🎯 Free Guest Mode: You are learning for free. Sign in to save your completion progress and quiz answers.

Ready to continue?

Mark this lesson as complete when you're ready to proceed.

Key moments

Tool Calling Definition — Tool calling makes the LLM context aware of real-time data like databases or APIs.
Traditional Loop Flow — The client sends messages and tool definitions, the LLM recommends a tool, and the client executes it.
Tool Definition Components — Tool definitions must include a name, a description explaining usage, and necessary input parameters.
Traditional Example Walkthrough — An example shows the LLM using a weather API definition to recommend a call for the temperature in Miami.
Traditional Tooling Downsides — Traditional tool calling risks LLM hallucination or the creation of incorrect tool calls.
Embedded Tool Calling Intro — Embedded tool calling uses a library or framework between the application and the LLM.
Embedded Loop Flow — The library appends the tool definition, receives the tool recommendation, and executes the tool call internally.
Embedded Benefits — The library handles tool execution and retries, preventing the LLM from hallucinating.

PDF notes

Bottom line: You will be able to define and differentiate between traditional and embedded LLM tool-calling architectures. You can trace the steps of the single-agent loop, understanding how external data sources like APIs or databases are integrated into the LLM workflow.

This lesson on Tool-Calling / Single-Agent Loop Lite is hands-on and example-driven. You will be able to define and differentiate between traditional and embedded LLM tool-calling architectures. You can trace the steps of the single-agent loop, understanding how external data sources like APIs or databases are integrated into the LLM workflow.

What You'll Be Able To Do

Define the purpose of LLM tool calling.
Describe the components required for a tool definition.
Trace the steps of the traditional tool-calling loop.
Compare the responsibilities of the client application in both architectures.
Explain how embedded tool calling mitigates LLM hallucination.
Identify examples of external tools usable by an LLM.

Topics Covered in Tool-Calling / Single-Agent Loop Lite

Tool Calling Definition (0:00 - 0:15) — Tool calling makes the LLM context aware of real-time data like databases or APIs.
Traditional Loop Flow (0:15 - 0:45) — The client sends messages and tool definitions, the LLM recommends a tool, and the client executes it.
Tool Definition Components (0:45 - 1:10) — Tool definitions must include a name, a description explaining usage, and necessary input parameters.
Traditional Example Walkthrough (1:10 - 1:45) — An example shows the LLM using a weather API definition to recommend a call for the temperature in Miami.
Traditional Tooling Downsides (1:45 - 2:05) — Traditional tool calling risks LLM hallucination or the creation of incorrect tool calls.
Embedded Tool Calling Intro (2:05 - 2:30) — Embedded tool calling uses a library or framework between the application and the LLM.
Embedded Loop Flow (2:30 - 3:00) — The library appends the tool definition, receives the tool recommendation, and executes the tool call internally.
Embedded Benefits (3:00 - 3:25) — The library handles tool execution and retries, preventing the LLM from hallucinating.

SQL Cheat Sheet

Tool Calling — LLM accesses real-time data, APIs, or databases

SELECT temperature FROM weather_api WHERE location = 'Miami';

Tool Definition — Specifies tool name, description, and input parameters

SELECT tool_name, params FROM tool_registry WHERE tool_name = 'weather_api';

Traditional Tool Calling — Client executes the tool recommended by the LLM
```
SELECT * FROM client_app_log WHERE action = 'Execute Tool';
```

Embedded Tool Calling — Library handles tool definition and execution internally

SELECT final_answer FROM llm_library_cache WHERE query = 'weather in Miami';

Tool Response — Data returned to the LLM after tool execution
```
SELECT 71 AS degrees, 'Fahrenheit' AS unit;
```

Comparison Table

Feature	Traditional Tool Calling	Embedded Tool Calling
Tool Execution	Client application is responsible.	Library handles execution internally.
Definition Location	Sent by client to LLM.	Defined within the library/framework.
Primary Risk	Risk of hallucination/errors.	Prevents hallucination; retries calls.
Loop Structure	Multi-step loop (Client-LLM-Client).	Single interaction (Client-Library-LLM).

Common Pitfalls

Pitfall: {'Mistake': 'Assuming the LLM executes the tool itself.', 'Avoid': 'Remember the client or library must execute the recommended call.'}
Pitfall: {'Mistake': 'Providing vague tool descriptions.', 'Avoid': 'Use the description field to specify when and how to use the tool.'}
Pitfall: {'Mistake': 'Relying solely on traditional tool calling for critical tasks.', 'Avoid': 'Use embedded tool calling to minimize hallucination and ensure retries.'}

FAQs

What types of tools can be defined? Tools can be APIs, databases, or code interpreted via a code interpreter.
What is the primary risk of traditional tool calling? The LLM might hallucinate or recommend incorrect tool calls that the client then executes.
Who is responsible for creating the tool definition? The application developer is responsible for defining the tool's name, description, and parameters.
How does embedded tool calling prevent hallucination? The intermediary library manages execution and retries, ensuring reliable tool interaction before returning the final answer.

Common pitfalls

Assuming the LLM executes the tool itself. — Remember the client or library must execute the recommended call.
Providing vague tool descriptions. — Use the description field to specify when and how to use the tool.
Relying solely on traditional tool calling for critical tasks. — Use embedded tool calling to minimize hallucination and ensure retries.

So what is tool calling? Tool calling is a powerful technique where you make the LLM context aware of real-time data, such as databases or APIs. Typically, you use tool calling via a chat interface. So you would have your client application in one hand and an LLM on the other side. From your client application, you would send a set of messages together with a tool definition to the LLM. So you would have your messages here together with your list of tools. The LLM will look at both your message and the list of tools and it's going to recommend a tool you should call. From your client application, you should call this tool and then supply the answer back to the LLM. So this tool response will be interpreted by the LLM and this will either tell you the next tool to call or it will give you the final answer. In your application, you're responsible for creating the tool definition. So this tool definition includes a couple of things, such as the name of every tool. It also includes a description for the tool. So this is where you can give additional information about how to use the tool or when to use it, and it also includes the input parameters needed to make a tool call. And the tools can be anything. So the tools could be APIs or databases. But it could also be code that you interpret via a code interpreter. So let's look at an example. Assume you want to find the weather in Miami. You might ask the LLM about the temperature in Miami. You also provide a list of tools, and one of these tools is the weather API. The LLM will look at both your question, which is what is the temperature in Miami? It will also look at the weather API, and then based on the tool definition for the weather API, it's going to tell you how to call the weather tool. So in here, it's going to create a tool that you can use right here on this side where you call the API to collect the weather information. You would then supply the weather information back to the LLM. So let's say it would be 71 degrees. The LLM will look at the tool response and then give the final answer, which might be something in the trend of the weather in Miami is pretty nice, it's 71 degrees. This has some downsides. So when you do traditional tool calling where you have an LLM and a client application, you could see the LLM hallucinate. Sometimes the LLM can also make up incorrect tool calls. That's why I also want to look at embedded tool calling. We just looked at traditional tool calling, but traditional tool calling has its flaws. As I mentioned, the LLM could hallucinate or create incorrect tool calls. That's why I also want to take embedded tool calling into account. With embedded tool calling, you use a library or framework to interact with the LLM and your tool definitions. The library would be somewhere between your application and the large language model. In the library, you would do the tool definition, but you would also execute the tool calls. So let's draw a line between these sections here. So the library will contain your tool definition. It will also contain the tool execution. So when you send a message from your application to the large language model, it will go through the library. So your message could still be what is the temperature in Miami. The library will then append the tool definition and send your message together with the tools to the LLM. So this will be your message plus your list of tools. Instead of sending the tool to call to the application or the user, it will be sent to the library, which will then do the tool execution. And this way, the library will provide you with the final answer, which could be it's 71 degrees in Miami. When you use embedded tool calling, the LLM will no longer hallucinate as the library to help you with the tool calling or the embedded tool calling is going to take care of the tool execution and will retry the tool calls in case it's needed. So in this video, we looked at both traditional tool calling and also embedded tool calling, where especially embedded tool calling will help you to prevent hallucination or help you with the execution of tools, which could be APIs, databases or code.

Frequently asked questions

What types of tools can be defined?

Tools can be APIs, databases, or code interpreted via a code interpreter.

What is the primary risk of traditional tool calling?

The LLM might hallucinate or recommend incorrect tool calls that the client then executes.

Who is responsible for creating the tool definition?

The application developer is responsible for defining the tool's name, description, and parameters.

How does embedded tool calling prevent hallucination?

The intermediary library manages execution and retries, ensuring reliable tool interaction before returning the final answer.