luvv to helpDiscover the Best Free Online Tools
Topic 6 of 8

Tool Use And Function Calling Patterns

Learn Tool Use And Function Calling Patterns for free with explanations, exercises, and a quick test (for Prompt Engineer).

Published: January 8, 2026 | Updated: January 8, 2026

Table of Contents

Why this matters

Mental model

  1. Intent: the model infers which tool (if any) is needed.
  2. Extraction: it fills the tool’s parameters precisely.
  3. Action: your app calls the tool.
  4. Observation: the tool’s result is passed back to the model.
  5. Finalization: the model composes the final user answer or next tool step.

Good prompts make these handoffs explicit and repeatable.

Core patterns

Single Tool Call (direct)

Use when one tool is enough.

  • Describe the tool: name, purpose, parameters, constraints.
  • Tell the model to output only a function call when appropriate.
  • After the tool returns, ask the model to produce a final answer.
{
  "tool": "get_weather",
  "arguments": {"city": "Rome", "date": "2026-04-03"}
}
Plan then Execute (multi-step)

When multiple tools or steps are needed (e.g., search → retrieve → summarize).

  1. Plan briefly (list steps and chosen tools).
  2. Execute step 1, read observation, then step 2, etc.
  3. Stop after achieving the objective or hitting a constraint.
ReAct with Tools (reason then act)

Interleave short reasoning with tool calls. Keep thoughts concise and geared to the next action.

Thought: I need up-to-date price.
Action: {"tool": "price_lookup", "arguments": {"ticker": "AAPL"}}
Router (choose the right tool or none)

Give clear, distinct tool descriptions and ask the model to choose exactly one or return "no_tool" with a reason.

{
  "tool_choice": "translate",
  "reason": "User asked to translate English to Spanish"
}
Validation and Retry (self-heal)

Add a check after argument extraction. If invalid, ask the model to revise and try again.

  • Validate types, ranges, formats, required fields.
  • On failure, return a brief critique and request corrected arguments.
Guardrailed Extraction (strict format)

When you must prevent free text, require the model to output JSON with only allowed fields. Reject extra keys.

Ask-Then-Act (clarify before calling)

If user input is ambiguous (e.g., time zone missing), ask one targeted question before calling a tool.

Worked examples

Example 1: Weather lookup (single tool)

Tool: get_weather(city: string, date: string)

System instruction: "If a date or city is missing, ask one clarifying question. Otherwise, return only a function call."

User: "What’s the weather in Tokyo tomorrow?"

Expected model function call:

{
  "tool": "get_weather",
  "arguments": {"city": "Tokyo", "date": "2026-01-09"}
}

App calls the tool, gets observation, then asks the model for a final natural-language answer using the observation.

Example 2: Calendar scheduling with validation

Tool: create_meeting(title: string, start_iso: string, duration_min: number, attendees: array of emails)

  1. Model extracts arguments from: "Set a 45-minute sync called 'Roadmap' with alex@example.com on Friday 3pm London time."
  2. Validator checks: ISO datetime, duration range (15–120), valid emails, business hours.
  3. If timezone missing or invalid, model asks one question; otherwise returns function call.
{
  "tool": "create_meeting",
  "arguments": {
    "title": "Roadmap",
    "start_iso": "2026-01-09T15:00:00+00:00",
    "duration_min": 45,
    "attendees": ["alex@example.com"]
  }
}
Example 3: Retrieval with ReAct

Tools: search_docs(query), get_doc(doc_id)

Thought: I need sources about streaming evaluation.
Action: {"tool": "search_docs", "arguments": {"query": "LLM streaming evaluation"}}
Observation: found doc ids [D12, D48]
Thought: Get the most relevant doc.
Action: {"tool": "get_doc", "arguments": {"doc_id": "D12"}}
Observation: content: ...
Final Answer: Concise answer citing the doc.

Design checklist

  • Define crystal-clear tool names, purposes, and parameter types.
  • Include constraints: formats, ranges, required keys, and defaults.
  • Limit tools in context to what’s relevant to reduce confusion.
  • Require JSON-only outputs for function calls; reject extra text.
  • Validate and retry on bad arguments; log critiques for improvement.
  • Handle “no tool needed” explicitly.
  • Ask one clarifying question if critical info is missing.

Exercises

Everyone can do the exercises. Progress is saved only for logged-in users.

  1. Exercise ex1: Design a currency conversion tool call (arguments only). See the Exercises section below for full instructions.
  2. Exercise ex2: Build a router that picks one tool or none, with a one-sentence reason.
  • Before submitting, self-check with the design checklist above.

Common mistakes and self-check

  • Mistake: Letting the model answer in prose when a tool call is needed. Fix: "When a tool is needed, output only the function call JSON."
  • Mistake: Ambiguous parameters (missing currency, timezone). Fix: Ask one clarifying question first.
  • Mistake: Overloading the context with too many tools. Fix: Provide only the ones relevant to the task.
  • Mistake: No validation on arguments. Fix: Add validation-and-retry with clear messages.
  • Mistake: ReAct thoughts too long. Fix: Keep thoughts short and action-oriented.
Self-check prompts
  • Can I point to exact required keys, types, and formats?
  • Is "no_tool" a valid explicit option?
  • Do I have a plan for tool errors (timeouts, 400s) and retries?
  • Is the final answer grounded in tool observations?

Practical projects

  • Personal finance helper: tools for categorize_transaction, get_balance, forecast_spend. Add validation on amounts and dates.
  • Study assistant: tools for search_papers, get_paper, cite. Use ReAct to find, fetch, and summarize with citations.
  • Travel planner: tools for flight_search, hotel_search, weather. Use plan-then-execute and ask-then-act for missing dates.

Mini challenge

Design prompts and schemas for a two-tool agent that can "translate_en_es(text)" and "summarize(text, max_words)". Requirements:

  • Router picks one tool or none, with a one-sentence reason.
  • Extraction enforces max_words as an integer (20–200).
  • If input is shorter than 40 words, refuse summarization with a helpful message.
Hint

Keep tool descriptions distinct and include constraints in the prompt. Add a validation-and-retry loop for max_words.

Learning path

  • Start: Single tool calls with strict JSON outputs.
  • Next: Router + ask-then-act for ambiguity.
  • Then: ReAct and plan-then-execute for multi-step workflows.
  • Finally: Add validation, retries, and robust error handling.

Next steps

  • Do the exercises, then take the Quick Test to check mastery.
  • Iterate on one practical project and add validation-and-retry.
  • Keep examples small and verifiable before scaling up.

Quick Test

The Quick Test is available to everyone. Only logged-in users will see saved progress.

Practice Exercises

2 exercises to complete

Instructions

Create a tool definition and prompt snippet that makes the model return only a function call for currency conversion.

  1. Tool name: currency_convert
  2. Parameters: amount (number), from (string, 3-letter code), to (string, 3-letter code), date (string, optional, YYYY-MM-DD)
  3. System rule: If any required field is missing, ask one clarifying question; otherwise output JSON with only tool and arguments.
  4. User: "Convert 39.90 euros to dollars"

Deliver: the expected function call JSON the model should output.

Expected Output
{ "tool": "currency_convert", "arguments": { "amount": 39.9, "from": "EUR", "to": "USD" } }

Tool Use And Function Calling Patterns — Quick Test

Test your knowledge with 8 questions. Pass with 70% or higher.

8 questions70% to pass
Retrieval Augmented Prompting BasicsPlanning And Execution Separation

Have questions about Tool Use And Function Calling Patterns?

AI Assistant

Ask questions about this tool