Dynamic Tool List Adaptation Few-Shot Prompt Template

This prompt template is designed for agent developers building multi-tenant or session-scoped systems where the set of available tools varies per request. Instead of hardcoding tool selection rules or retraining models for each tool configuration, this few-shot prompt teaches the model to inspect the provided tool list and select only from currently available tools. Use this when your agent serves different customers with different API subscriptions, when tools are feature-flagged per user, or when you deploy the same agent across environments with different capability sets. The prompt works by presenting contrasting examples: some where the tool list is full, some where it is reduced, and some where deprecated tools appear in conversation history but are absent from the current list. The model learns to ground every tool selection decision in the provided [AVAILABLE_TOOLS] block rather than relying on memorized tool names from training data.

You should not use this prompt when the tool list is static and known at development time. In that case, a standard system prompt with explicit tool descriptions is more efficient and less error-prone. Similarly, do not use this approach if your model has been fine-tuned for a specific tool set; the few-shot examples may conflict with the model's trained behavior, causing unpredictable selection patterns. This prompt is also inappropriate for single-tool agents where selection is trivial. The primary risk this prompt addresses is tool hallucination—the model calling a tool that is not in the current list. A secondary risk is capability assumption, where the model refuses to attempt a task because it assumes a tool is missing, even when a new or alternative tool in the list could accomplish it. The examples must explicitly teach the model to trust the provided list over its internal knowledge.

Before implementing this prompt, audit your tool delivery pipeline to ensure the [AVAILABLE_TOOLS] block is always a complete and accurate reflection of the current session's capabilities. A mismatch between the declared tools and the actual API gateway permissions will lead to runtime failures that the prompt cannot prevent. After deploying, monitor for tool_not_found errors and instances where the model selects a deprecated tool mentioned in the conversation history. These are the leading indicators that the few-shot examples need to be strengthened or that the tool list injection is failing. Proceed to the next section to copy the prompt template and begin adapting it to your specific tool schemas.

This template uses a small set of worked examples to demonstrate the core behavior: selecting the right tool from a dynamic list, ignoring tools that are no longer available, and correctly adopting new tools that appear in the list. The examples are designed to be compact but high-signal, showing the model how to reason about tool availability rather than memorizing a fixed set. Copy the template below and replace every square-bracket placeholder with your actual values before wiring it into your agent harness.

textCopy
SYSTEM: You are an agent that selects the most appropriate tool from a provided list to fulfill a user's request. The list of available tools will change between requests. You must only select tools that are present in the current [TOOLS] list. Do not hallucinate tools that are not listed. If no tool is appropriate, respond with [NO_TOOL_RESPONSE].

[EXAMPLES]

USER: [USER_INPUT_1]
TOOLS: [TOOLS_LIST_1]
ASSISTANT: [CORRECT_TOOL_SELECTION_1]

USER: [USER_INPUT_2]
TOOLS: [TOOLS_LIST_2]
ASSISTANT: [CORRECT_TOOL_SELECTION_2]

USER: [USER_INPUT_3]
TOOLS: [TOOLS_LIST_3]
ASSISTANT: [CORRECT_TOOL_SELECTION_3]

---

USER: [USER_INPUT]
TOOLS: [TOOLS]
ASSISTANT:

To adapt this template, start by defining your [TOOLS] placeholder as a structured list of tool names and brief descriptions. Your [EXAMPLES] should cover at least three scenarios: a full tool list where the correct choice is obvious, a reduced list where the previously correct tool is absent and a different one must be chosen, and a list containing a new tool that was not present in prior examples. The [NO_TOOL_RESPONSE] placeholder should be a clear, safe default like {"tool": null, "reason": "No appropriate tool available."}. After copying, validate that the model's output schema is consistent across all examples—mixing JSON and plain text in few-shot demonstrations is a common source of production drift. For high-stakes environments, add a validation step that checks the selected tool name against the provided [TOOLS] list before execution.

The core challenge of dynamic tool adaptation is that the prompt template must be assembled at runtime with a variable set of tool definitions. The application layer is responsible for injecting the correct [TOOLS] block before every request. This block should be a serialized representation of the currently available tools—typically a JSON array of function definitions following the target model's native tool-use schema. The prompt's few-shot examples must be dynamically filtered or regenerated to match the active tool set, ensuring that demonstrations never reference unavailable tools. A common failure mode is leaving stale examples that teach the model to call a deprecated tool, which the harness must prevent by validating that every tool name in the [EXAMPLES] block exists in the current [TOOLS] list before assembly.

After the model returns a tool selection, the harness must validate the response before execution. First, confirm the selected tool name exists in the active tool list—reject hallucinated or deprecated tool names immediately. Second, validate that all required arguments are present and that argument types match the tool's schema. If validation fails, the harness should enter a structured retry loop: append the validation error to the conversation, re-inject the same [TOOLS] block, and request a corrected selection. Limit retries to a maximum of two attempts before escalating to a fallback path—either a human review queue or a safe default action. Log every validation failure, retry, and escalation for observability. For high-stakes actions, insert a confirmation gate after successful validation but before tool execution, presenting the proposed action to a human operator.

Model choice matters here. Smaller or older models struggle more with tool list changes and are more likely to hallucinate deprecated tools or ignore newly added ones. Prefer models with strong instruction-following and tool-use benchmarks for this workflow. If you must use a smaller model, reduce the number of tools in the active list per request and increase the number of few-shot examples showing adaptation behavior. The eval harness should include regression tests that simulate tool list changes—removing a commonly used tool, adding a new tool, and reducing the list to a single option—and verify that the model adapts correctly without hallucination. Monitor production traces for tool selection accuracy, argument validity, and retry frequency. A sudden increase in validation failures often signals that the tool list has changed in a way the examples no longer cover.