5 exercises — Describe function schemas, tool selection decisions, parallel calls, error handling, and tool result integration precisely.
0 / 14 completed
1 / 14
A teammate reviews a function schema and says: "The description field is too vague — the model picks the wrong tool because it can't tell when to call this function versus the search one." What makes a function description effective for tool selection?
Function descriptions are the model's primary signal for tool selection.
When an LLM chooses which function to call, it relies almost entirely on the description field — not the parameter names or any runtime context. A vague description (e.g., "gets data") causes the model to guess, leading to wrong tool calls or missed calls.
Effective descriptions answer three questions: (1) What does this function do? (2) When should the model call it vs. other available functions? (3) What does it return? For example: "Searches the product catalogue by keyword. Call this when the user asks about a specific product or SKU. Returns a list of matching products with IDs and prices."
Including source code wastes tokens; single-word descriptions remove all semantic signal; and cramming edge cases into parameters confuses the schema rather than clarifying intent.
Key vocabulary:
• function schema — the JSON object describing a callable tool: name, description, parameters, required
• description field — the natural-language text the LLM reads to decide when to call the function
• tool selection — the model's decision of which registered function (if any) to invoke given the conversation
• parameters — the JSON Schema object defining the function's input arguments and their types
2 / 14
After a code review, a senior engineer says: "In my trace I can see the model chose to call get_weather with location='Paris' and then formulated a follow-up using the tool result." Which phrase best describes this sequence using correct vocabulary?
"Tool call → tool result → grounded response" is the standard narration pattern.
The correct vocabulary sequence is: the model issues a tool call (or "function call") specifying the function name and arguments; your runtime executes the function; the output is passed back as a tool result (a special message role in OpenAI / Anthropic APIs); the model then grounds its final answer in that result.
The model never executes code directly — it outputs a structured JSON request, and the application layer runs the function. "Grounded" means the response is based on factual retrieved data rather than parametric knowledge.
Key vocabulary:
• tool call — the structured JSON output from the model specifying which function to run and with what arguments
• tool result — the message containing the function's return value, passed back to the model
• grounded response — an answer based on retrieved or returned data rather than model memory
• agent loop — the cycle of model inference → tool call → tool result → next inference
3 / 14
You're designing an order-processing flow. A colleague proposes: "We can refactor to parallel tool calls — instead of calling check_inventory and get_price sequentially, the model can request both in a single turn." When does using parallel tool calls provide a clear benefit?
Parallel tool calls eliminate unnecessary latency for independent operations.
In sequential tool calling, each function call adds a full model inference round-trip plus the function's execution time before the next call can start. When the calls are independent — neither result is an argument to the other — this serialisation is pure waste.
With parallel tool calls (supported in OpenAI's API as a list of tool_calls in a single response), the model requests all independent functions at once, the application executes them concurrently, and all results are returned together in one tool result message. Total latency drops from sum-of-latencies to max-of-latencies.
Sequential calling is correct when the second call depends on the first result — e.g., look up a user ID, then use that ID to fetch their orders.
Key vocabulary:
• parallel tool calls — requesting multiple independent functions simultaneously in a single model response
• sequential tool calls — chaining calls where each depends on the previous result
• round-trip latency — the time cost of one model inference plus function execution cycle
• independent calls — function calls whose inputs do not depend on each other's outputs
4 / 14
During an incident review, a teammate says: "The tool returned a 429 rate-limit error. Rather than crashing the agent, we formatted the error as a tool result and passed it back — the model retried with exponential backoff." Which vocabulary best describes this pattern?
Passing errors back as tool results keeps the model in the loop for recovery decisions.
In a robust agent loop, tool errors should not silently crash the system or be swallowed. Instead, the application formats the error (code, message, any relevant metadata) as a tool result message and returns it to the model. The model — seeing the error text — can then decide to retry after a delay, call a fallback function, ask the user for clarification, or gracefully report the failure.
This is described as "surfacing the error to the model" or "passing the error back to the model for recovery." The term exponential backoff refers to increasing wait times between retries (1s, 2s, 4s…) to avoid overwhelming the rate-limited API.
Key vocabulary:
• tool error — an exception or error code returned by a function the model called
• error surfacing — returning the error to the model as a tool result rather than silently handling it
• exponential backoff — retry strategy with doubling wait times between attempts
• rate limit (429) — HTTP status indicating the caller has exceeded the API's request quota
5 / 14
A new developer asks: "After the tool result comes back, what exactly does the model do with it? Does it just quote the JSON or does it do something more?" Which answer uses the most accurate vocabulary?
Tool result integration means synthesis, not quotation.
Once a tool result is appended to the conversation context, the model performs another inference pass — now with the full history including the tool output. It synthesises a coherent, natural-language response that may incorporate specific values from the tool result (numbers, names, statuses) while adding reasoning, formatting, and conversational flow.
This is fundamentally different from quoting JSON verbatim. The model reads the structured data and produces a fluent answer, for example: "The current stock of SKU-4421 is 83 units, available for immediate dispatch."
Models do not store tool results in weights (that would require fine-tuning), and no separate summarisation pipeline is needed — tool result integration is a native capability of chat-completion APIs.
Key vocabulary:
• tool result integration — the model's use of a returned tool result when generating its next response
• synthesis — combining retrieved data with reasoning to produce a coherent answer
• context window — the full sequence of messages (user, assistant, tool) the model attends to during inference
• grounded answer — a response based on retrieved or returned evidence rather than model memory alone
6 / 14
Code Review Comment: 'The function's description doesn't clearly specify the expected input format. This leads to inconsistent tool calls and inaccurate results.' Which aspect of a function description is most crucial for ensuring reliable tool usage according to this comment?
The comment highlights a fundamental problem: ambiguity in the input definition. The model needs explicit guidance on *what* it expects to receive from the caller to correctly select and utilize the appropriate tool. Options A and D are peripheral concerns; option C focuses on business context rather than technical specification, and B directly addresses the core issue of defining the expected input.
7 / 14
Slack Message: 'Hey team, I'm seeing the agent consistently using the `get_product_details` tool even when a simple search query would have been more efficient. The output is always parsed and used in subsequent calls. Is there something we can do to guide it better?' What does this Slack message primarily indicate about the LLM's tool usage?
The message points to a lack of efficiency and potentially a flawed approach. The model is using a more powerful tool (get_product_details) for tasks that could be handled by a simpler one (search). This suggests the LLM isn't intelligently selecting the *optimal* tool based on the query's complexity, leading to increased computational cost and potential latency.
8 / 14
PR Description: 'Implemented a new pattern for handling tool results. Instead of directly using the raw JSON, we now extract the key information and format it into a structured object before passing it to subsequent tools. This improves consistency.' What's the primary benefit of this described approach?
The core benefit is standardization of input data. Different tools might have different expectations for the format of the JSON response. By extracting and formatting the relevant information into a consistent object, you eliminate potential parsing errors and ensure that all downstream tools receive the data in a usable manner – crucial for reliable operation.
9 / 14
Standup Update: 'We're seeing some intermittent rate limit errors from the payment processing tool. To mitigate this, we've been formatting the error response as a tool result and letting the agent retry with exponential backoff.' What technique is being employed to handle this specific API limitation?
This scenario exemplifies retry logic with exponential backoff. Rate limit errors are common in APIs and often transient. Instead of letting the agent crash or simply fail, this approach intelligently retries the call after a delay, gradually increasing the delay if subsequent attempts also fail – a standard pattern for handling intermittent API issues.
10 / 14
During a sprint retrospective, the team discussed instances where the LLM agent struggled to utilize tools effectively. A developer noted: 'The model consistently called the `translate_text` tool despite the input being purely English. The function description lacked any context about language detection or fallback mechanisms.' Which of the following best describes the core issue highlighted in this scenario?
This situation points to a fundamental problem with function descriptions: they need to explicitly state the tool's capabilities and limitations. The model lacked context about language detection, leading it to repeatedly call an inappropriate tool. The correct answer reflects the need for clarity in defining the tool's scope.
11 / 14
A senior engineer is reviewing a Slack message from a junior developer: 'I'm getting a lot of 503 errors when calling the `generate_image` tool. The model seems to be generating incredibly large images, and I suspect it's not respecting the size constraints specified in the function description.' Considering this feedback, what is the MOST important action to take?
The Slack message directly indicates a mismatch between the function's defined constraints and the model's behavior. Monitoring usage patterns is crucial to understand *why* the model is exceeding those limits – it's likely the description isn't effectively controlling output size. Updating the description alone won't solve the problem if the model isn't adhering to it.
12 / 14
You are writing a PR description for a change that improves how the LLM agent handles tool failures. The description states: 'We've introduced a new mechanism to transform tool return values into structured objects before passing them to subsequent calls. This ensures consistent data handling and allows us to gracefully manage potential errors.' Which of the following BEST explains why this approach is beneficial?
The key benefit here is standardization. Transforming tool results into structured objects ensures a consistent format for subsequent processing – which is essential for robust error handling and simplifies integration with other components of the system. The standardized output facilitates predictable behavior regardless of the tool's response.
13 / 14
A code review comment reads: 'The function's documentation doesn't specify whether the `get_customer_info` tool should return a full customer object or just essential details. This ambiguity leads to inconsistent calls and incorrect data formatting.' What is the MOST effective way to address this issue?
The core problem is lack of clarity. A precise function description must explicitly define the tool's return type – full object versus partial details. This eliminates ambiguity and prevents inconsistencies in how the model uses the tool's results.
14 / 14
A developer is debugging a scenario where the LLM agent consistently calls the `calculate_shipping` tool even when it's not needed. The agent's internal logs show that it's always passing the same product ID to this tool. Considering the agent's behavior, what's the MOST likely reason for this?
Without a defined condition in the function description, the LLM has no guidance on *when* to invoke the `calculate_shipping` tool. It's essentially operating without constraints, leading it to consistently call this tool regardless of the context. The lack of a conditional statement is the root cause.
What will I practise in "Function Calling & Tool Use Language — LLM App Development"?
5 advanced exercises on function calling vocabulary — schemas, tool selection, parallel calls, error handling, and result integration.
How many exercises are in this module?
This module has 14 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more LLM App Development exercises?
Browse the full LLM App Development hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.