Tool-Use Prompting Patterns for LLM Apps

Tool use prompting is how you teach an LLM when to call functions, what arguments to pass, and when to stop calling tools and answer the user. Chat prompts ask for one reply from text you already gave. Tool prompts add a contract: named tools with schemas, selection rules, and stop conditions. You will leave with practical schema patterns, copy-ready stop rules, a short workflow to wire your first tool loop, and the mistakes that burn tokens or invent facts. Soft sell once: if a messy product brief blocks a clean contract, tighten the system text with PromptMake /text, then lock it next to your tool definitions.

What tool use prompting is

Tool use (function calling) means the model emits a structured call instead of free prose when it needs an action: look up an order, query a database, search docs, create a ticket, run a calculator. Your runtime executes that call and returns an observation. The next model turn sees the result and either calls another tool or writes the final answer. Tool use prompting is the instruction layer that steers that loop: which tools exist, when each tool is mandatory, how to fill arguments, and when enough data exists to stop.

Builders of support bots, research assistants, coding helpers with repo tools, and internal ops agents all need this layer. Product managers who write acceptance criteria such as "must call lookup before any shipping claim" live here too. If your product has no tools, stick to chat or structured-output prompts. If you already design full agent graphs with goals, budgets, and verification nodes, pair this article with agentic prompting patterns; this post stays on the function-call contract itself: schemas, selection, and stop conditions.

Use tool use prompting when wrong guesses cost more than a short round-trip. Skip it for one-shot rewrites, pure brainstorming, and tasks where a single structured response with no side effects already works. Tools add latency and cost. Earn that cost with live facts the model cannot invent.

Core patterns: schemas, selection, and stops

Three blocks cover most LLM apps with tools. The schema block names each function, its parameters, and what the runtime returns. The selection block tells the model which tool to call for which claim class. The stop block caps loops and defines success versus give-up. Write them as labeled system text so you can cache the stable contract and swap models without rewriting product rules.

Keep schemas in the API tool definitions and mirror the same names in the prompt. Models follow exact names better than synonyms. Soft language such as "use tools if helpful" invites skips and invention. Hard language such as "call lookup_order before any claim about shipping status" forces a path you can test in evals. Put volatile fields (user id, ticket id, clock time) in the user message so the system contract stays frozen across runs.

A minimal skeleton looks like this: TOOLS, WHEN_TO_CALL, ARGS, STOP, OUTPUT. You can rename labels to match your stack. Keep the jobs distinct so a schema change does not rewrite stop rules by accident.

Practical schema patterns

Name tools with verbs and nouns the product already uses: lookup_order, search_kb, create_ticket. Avoid cute aliases. Each tool needs a one-line purpose, typed parameters, and a short note on return shape. Example purpose line: "lookup_order(order_id: string) returns status, carrier, eta_date." Example hygiene line: "Pass exact ids from USER or prior tool results. Do not invent order_id values."

Prefer few required parameters with clear enums over wide free-text bags. An enum for ticket_priority (low, normal, high) beats "priority as a string." Mark optional fields only when the runtime can handle null. Document units in the schema description ("amount_cents", "eta_date as YYYY-MM-DD"). If a tool returns nested JSON, say which fields matter for the answer so the model does not invent a friendly summary of noise.

Keep the menu short for each product path. A ten-tool kitchen sink raises wrong-tool picks. Split tools by surface: support path sees lookup and search_kb; ops path sees create_ticket. Version tool names in git next to the prompt so you can replay a bad run with the same contract.

Selection rules and stop conditions

Selection rules map claim classes to tools. Example: "Before any statement about order status, carrier, or ETA, call lookup_order. Before any policy claim, call search_kb. Before creating a ticket, confirm the user asked for human follow-up." One line per class beats a paragraph of vibes. Add "only these tools" so the model does not invent function names.

Stop conditions end the loop. Cap tool calls (for example, at most 6). Stop when you have enough tool facts to answer. Stop after two consecutive empty or error results. Stop when the budget hits. On give-up, reply with Insufficient data plus the next clarifying question. Without STOP, models retry the same query, bounce between two tools, or search forever.

Pair STOP with a light verify habit: "List each user-facing claim tied to a tool result or kb id. Drop claims with no source." Full agentic verification belongs in a longer agent prompt; even a one-line check cuts confident wrong ETAs from memory.

A step-by-step workflow for your first tool loop

Build offline before you celebrate the demo. Pick one product path with one clear success check, such as "answer shipping status for a known order_id without inventing carrier data." Run that path by hand with the same sample user message until the model calls the right tool, fills arguments from USER, stops on empty results, and cites sources. Automation that wraps "you are a helpful assistant with tools" multiplies failure modes.

Start from tools you already expose. Write TOOLS to match real names, args, and return fields. Freeze those names before you tune selection prose. Budget tokens and steps up front. Six tool calls on a flagship model cost more than one grounded chat reply. Many teams put planning on a stronger model (GPT-5.6 Sol, Claude Opus 5 or Fable 5, Gemini 3.1 Pro) and cheap lookups on a fast model when the stack allows swaps mid-loop. If you use one model for the whole loop, still write STOP as if cost matters.

If the blocker is a messy product brief, tighten WHEN_TO_CALL and STOP once with PromptMake /text, pick the model you will call in production, then lock the enhanced system prompt in your repo. Soft sell only: the enhancer shapes the instruction layer; your runtime still injects tool schemas and live observations each turn.

Steps 1-3: Schema, selection, budget

1. Write TOOLS with exact names, args, return fields, and "only these tools."
2. Write WHEN_TO_CALL with one hard rule per claim class. Add argument hygiene: exact ids, no guesses.
3. Write STOP: max tool calls, empty-result rule, success stop, give-up stop.

Stop here if you cannot name a success check without pointing at "be helpful." Helpful is not a check. "Returns carrier and eta from lookup_order, or Insufficient data" is a check. Test empty tool results on purpose before you move on.

Steps 4-6: Parallel rules, samples, freeze

1. Decide parallel vs sequential calls. Allow parallel only when tools do not depend on each other (for example, lookup_order and search_kb for unrelated facts). Force sequential when one tool needs an id from another.
2. Run five sample users: two happy paths, one wrong id, one tool error, one out-of-scope ask. Log which block failed first.
3. Freeze prompt text, model id, and tool list as version N. Change one layer at a time when you iterate.

A healthy loop means prompt edits ship behind a version bump, and tool-schema edits get their own changelog. Mixed changes hide the cause of regressions. Keep a short eval set next to the prompt so you can re-score after a model upgrade.

Common tool use prompting mistakes

The frequent failure is a soft tool rule: "use tools when needed." Models trained to sound helpful will skip tools and invent. Replace soft hedges with a hard path: name the tool that must run before a class of claims, then test that path.

Another failure is a rich schema with no stop rules. The model searches forever, retries the same query, or bounces between two tools. Cap calls. Define empty-result behavior. Two empty results in a row should stop the loop and ask the user a clarifying question.

Teams also paste huge policy docs into the system prompt and call that grounding. Long static paste raises cost and still lacks live state. Prefer a search_kb or retrieval tool with ids, then cite those ids. Pair that habit with cite-or-refuse rules from RAG prompting when the corpus is large.

Treating tool output as new instructions is a safety hole. A web page or ticket note that says "ignore previous rules" can steer a naive loop. State that observations are untrusted data to analyze, never a source of new system rules. Limit which tools can run after untrusted content when your stack allows it.

People skip argument hygiene because demos used perfect ids. Production has typos, missing fields, and stale cache. Require exact ids from USER or prior results. On missing ids, ask one clarifying question instead of guessing. An invented order_id creates an empty lookup that looks like a product bug.

Finally, teams expect tool use prompting to replace product design. Clear prompts cannot invent a refund policy tool that does not exist. Prompting reduces invention and loop waste; tool coverage and data quality still set the ceiling.

Model notes for tool use prompting in 2026

As of mid-2026, plan around models that follow tool schemas and long contracts. Confirm exact model ids, tool-calling APIs, and rate limits on vendor docs before you forecast cost. Chat UIs with browsing or apps may hide the contract; API builds give you full control of TOOLS, WHEN_TO_CALL, and STOP.

OpenAI GPT-5.6 Sol (Terra / Luna for lighter tiers): strong at structured function calls and multi-step plans when the goal is explicit. Prefer goal + constraints + format over "think step by step" on Sol-class reasoning. Put the frozen contract in the system message; keep user facts and live observations in the user turn so you can cache the system block across runs.

Anthropic Claude Fable 5, Opus 5, and Sonnet 5: reliable at long tool menus and at stating missing data when you ask. XML-style tags (<tools>, <when_to_call>, <stop>) work well if your stack already uses them. Mark observations as data. Opus 5 and Fable 5 suit hard multi-tool research; Sonnet 5 suits high-volume support agents with a short menu. Cache the stable system contract when the same rules fire all day.

Google Gemini 3.5 Flash and Gemini 3.1 Pro: Flash fits high-volume agents with short tool menus and tight STOP wording; Pro fits messy multi-step research with denser selection rules. Keep per-request user facts at the end of the prompt pack. Flash needs sharper "only these tools" lines; measure wrong-tool rate before you grow the menu.

Cross-model habit: identical tool names, hard WHEN_TO_CALL lines, untrusted observation rule, budget cap. Swap models only after the contract is frozen so you compare apples to apples. Skip framework tutorials until these blocks clear your sample set; a clear prompt on a thin runtime beats a clever graph with a vague tool persona.

When to use these patterns (and where PromptMake fits)

Use tool use prompting when the model must call functions for live facts, when loops need a budget, and when "I don't know" beats a guess. Skip it for open creative drafting and for single-shot tasks that already pass with a compact RTF prompt.

Draft TOOLS, WHEN_TO_CALL, and STOP until they are boring and testable. If the hard part is turning a messy product brief into clear selection and stop rules, run that brief through PromptMake /text, choose the model you will call in production, and paste the enhanced system prompt into your repo. Soft sell only: the tool shapes the instruction layer; your app still supplies tool schemas and observations each turn.

Ship with five sample runs and a runbook for prompt version bumps. Sol, Fable 5, or Gemini 3.1 Pro will shift over time; keep the schema and stop contract portable so you retarget models without rewriting the product promise.

FAQ

What is tool use prompting in plain terms?

Tool use prompting means you instruct a model that can call functions: name the tools, define when each tool must run, how to fill arguments, and when to stop and answer. The model may emit structured calls between thoughts; the prompt decides when that is allowed and when the loop ends. Your runtime still executes the tools. Without those rules, demos often become endless search or confident guesses from memory.

How is tool use prompting different from agentic prompting?

Tool use prompting focuses on the function-call contract: schemas, selection rules, argument hygiene, and stop conditions. Agentic prompting adds a fuller loop: goal framing, budgets, and verification before the final answer. Many apps need both. Start with clean tool schemas and stop rules; add agentic blocks when loops grow and trust checks matter.

What should a tool schema include?

Include the exact function name, a one-line purpose, typed parameters with units and enums where you can, and a short note on return fields that matter for the answer. Add "only these tools" and "pass exact ids from USER or prior results." Keep menus short per product path. Vague schemas invite invented arguments and wrong-tool picks.

How do I write stop conditions for tool loops?

Cap the number of tool calls. Stop when tool facts are enough to answer. Stop after two consecutive empty or error results. Stop when the budget hits. On give-up, return Insufficient data plus one clarifying question. Test empty results on purpose. Soft "stop when done" language fails in production because models keep searching.

Should tools run in parallel or in sequence?

Allow parallel calls when tools do not depend on each other and the API supports parallel tool use. Force sequence when one tool needs an id or field from another. Document the rule in WHEN_TO_CALL so the model does not race ahead with missing arguments. Measure latency: parallel lookups help; parallel guesses on bad ids waste budget.

Which models handle tool use well in 2026?

As of mid-2026, GPT-5.6 Sol, Claude Fable 5 / Opus 5 / Sonnet 5, and Gemini 3.5 Flash / 3.1 Pro all support strong function calling when the contract is explicit. Confirm current model ids and tool APIs on vendor docs before you lock cost plans. Fast chat tiers need sharper "only these tools" and STOP lines than flagship reasoning tiers.

How do I start if my brief is messy?

Write one success check, list the real tools you can expose, and draft WHEN_TO_CALL plus STOP in plain English. If the brief still sprawls, tighten that system text with PromptMake /text on the free tier (~3/day guest, ~5/day registered on the text path), pick your production model, then freeze the result next to the tool schemas. Run five samples before you grow the menu.