Day 6
Tool Calling Basics
Learn how agents discover, select, and invoke external tools.
Tool calling is how agents interact with the outside world. Instead of relying solely on training data, an agent can query databases, call APIs, run computations, and act on real-time information. The ability to design and use tools is the most frequently tested skill in Agentic AI interviews.
Today’s Lesson
Read
Tool Creation
Typed schemas, resilient wrappers, and safe tool calls.
Practice
Apply what you learned by solving these coding problems.
Review
Test yourself with these interview-style questions.
1Describe the process of dispatching a tool call from the agent loop. Walk through what happens from the moment the LLM produces a tool action to the point where the observation is returned. Focus on the validation, execution, and error-handling steps.+
After the LLM produces a tool action with name and arguments, the runtime first validates the tool name against the registry. If not found, it returns an observation listing available tools. Next, it validates required arguments against the tool's schema — if a required key is missing, it returns an error naming the missing field. Finally, it calls the tool function in a try-catch and formats the result or exception as a string observation. Errors are returned as structured observations, never as crashes, so the LLM can self-correct on the next iteration.
Read full answer
Tool dispatch has three phases between LLM output and observation. Validation phase: first check the tool name exists in the registry. If it is missing, the LLM hallucinated a tool name — the best response is an observation listing all available tools so the LLM can pick a valid one. Second, validate that all schema.required keys are present in the provided arguments. If a required argument is missing, return an observation describing exactly which argument is absent and its expected type. This precise feedback lets the LLM fix the call correctly on the next attempt. Execution phase: call the tool function with the provided arguments wrapped in try-catch. On success, format the return value as a string observation. On exception, format the exception as a structured error observation. The key principle behind this design is that errors should become observations, never crashes. A crashing dispatch kills the entire agent session. An observation gives the LLM a chance to correct its behaviour. In production, I also include the tool's raw return value alongside the string representation, giving the LLM both a human-readable summary and structured data for subsequent steps.
2Compare embedding tool definitions in the system prompt as text vs using the model's native function-calling API. What are the trade-offs in reliability, flexibility, and model compatibility?+
Native function-calling APIs are more reliable (model was fine-tuned for this format) but are model-specific. Text-based definitions work with any LLM but require manual parsing which is error-prone. Native APIs win for single-model production where reliability is paramount. Text-based schemas win for multi-model systems or when using models without native function calling, such as open-source models. A hybrid approach: use native API when available, fall back to text-based for alternatives.
Read full answer
Native function-calling APIs (available in GPT-4, Claude, Gemini) provide structured tool call output parsed automatically. The model was fine-tuned for this task, so it rarely hallucinates tool names or format. Reliability is higher, but you get vendor lock-in. Text-based tool definitions work with any text-generating LLM by embedding descriptions in the system prompt and parsing output with regex. Reliability is lower — the model may format the action incorrectly, miss arguments, or include extra text. In practice, I use native APIs for production systems where I control the model choice, and text-based for research, multi-model systems, or cost-constrained environments. A third hybrid: use native API as primary, with automatic fallback to text-based for providers that lack function calling.
3How does tool description quality affect LLM tool-selection accuracy? Describe an experiment to measure this relationship: test conditions, variables, and metrics.+
Tool descriptions directly determine selection accuracy because the LLM matches user requests against description text via semantic similarity. An experiment: create 100 test queries with known correct tools, run with three description conditions — minimal (name only), medium (one sentence), high-quality (usage examples, parameter hints, disambiguation). Control for model, temperature, and tool count. Measure top-1 accuracy per condition. Hypothesis: high-quality descriptions improve accuracy by 20+ percent, especially as tool count increases, by disambiguating semantically similar tools.
Read full answer
Tool description quality is arguably the most important factor in reliable tool selection. The LLM matches user requests against tool descriptions using semantic similarity in embedding space. Vague descriptions produce broad semantic targets that overlap with multiple tools. Overlapping descriptions like "searches the web" and "queries the internet" are especially problematic. My experiment: create 100 user requests spanning all tool-related intents, each with known correct tool. Three conditions: minimal (name only), medium (one sentence: what the tool does), high-quality (purpose, typical input examples, output format, when to choose this over alternatives). Control for model (same across conditions), temperature (0), tool count (5, 10, 20), and description length. Measure top-1 accuracy, no-selection rate, and inference latency. The hypothesis: high-quality descriptions dramatically improve accuracy, especially at higher tool counts, because they create distinct semantic boundaries. Error pattern analysis would reveal whether failures come from missing descriptions, ambiguous overlap, or the LLM ignoring descriptions.
Back to 30-Day Agentic AI Interview Prep Path