What this prompt does
This prompt designs a complete tool-use system for an AI assistant using function calling — the tool schemas, system prompt, and orchestration logic that let a model take actions rather than just talk. For each tool you list, it produces a JSON Schema definition with typed parameters and required fields, usage examples showing when to use versus not use it, and error-handling behavior for failed calls. It covers multi-tool orchestration where one tool depends on another's output, parallel calling, user confirmation for destructive operations, and tests across many scenarios.
The variables fit the system to your assistant. [purpose] defines what the assistant does, such as managing a project board, and [tools] lists the specific functions to define — create, update, search, assign, and so on. [model_provider] sets the function-calling convention, since providers differ in how tools are declared and invoked. [test_count] determines how many scenarios the integration tests cover to verify the model selects the right tool. The design treats token-efficient, unambiguous tool descriptions as the key to correct tool selection.
When to use it
- You are building an agent that must take real actions through
[tools], not just generate text. - The model keeps picking the wrong tool and you need clearer, more unambiguous tool descriptions.
- Tools depend on each other and you need orchestration where tool B uses tool A's output.
- Destructive operations need a user-confirmation flow before they execute.
- You want integration tests verifying correct tool selection across
[test_count]scenarios. - Defining typed JSON schemas with required fields so the model calls tools correctly.
Example output
Expect the complete tools array — one JSON Schema per function in [tools] with typed parameters, descriptions, and required fields — plus a system prompt with usage examples clarifying when each tool applies. It includes error-handling behavior for failed calls, multi-tool orchestration and parallel-calling guidance, a confirmation flow for destructive actions, a fallback for when no tool fits, and a plan for integration tests across [test_count] scenarios to verify tool selection.
Pro tips
- Write tool descriptions to be token-efficient but unambiguous; clear descriptions are usually what fixes a model picking the wrong tool, not more instructions elsewhere.
- Mark required fields explicitly in each schema so the model does not call a tool with missing parameters and trigger avoidable errors.
- Add a user-confirmation step for any destructive operation in
[tools], since an assistant that deletes or overwrites without asking is a liability. - Design the error-handling behavior deliberately — what the model does after a failed call determines whether it recovers or loops.
- Use the
[test_count]scenarios to probe selection across similar tools; tools with overlapping purposes are where wrong-tool errors cluster. - Specify
[model_provider]accurately, because function-calling formats and parallel-call support differ between providers and the schemas must match.
