Mock Tool Response Generation Prompt Template

This prompt is for AI quality engineers and integration developers who need to build test harnesses for tool-bearing agents. The job is to produce a diverse, realistic set of mocked tool responses—including success, error, and edge-case variants—directly from a tool's contract schema. You use this when you have a defined tool interface (OpenAPI spec, function declaration, MCP server descriptor) but do not yet have a live backend, or when you need to test agent behavior against failure modes that are difficult to trigger in a real environment. The ideal user understands the tool's expected behavior and can provide a schema with field types, constraints, and error codes.

Do not use this prompt when you need to test against a live system's actual behavior, when the tool contract is unknown or purely conversational, or when the goal is to evaluate the agent's planning logic rather than its response handling. This prompt generates synthetic payloads, not behavioral assertions. It is a data-generation step that feeds into downstream test runners, eval harnesses, and contract compliance checks. The prompt assumes you already have a tool contract to provide as input—it does not help you design or validate that contract.

Before using this prompt, ensure you have a complete tool contract ready, including argument schemas, output schemas, and a catalog of known error codes. Pair the generated mock responses with an agent behavior verification prompt to create a full test loop. Avoid using these mocks as the sole validation step for production deployment; always supplement with live integration tests and human review for high-risk or irreversible tool actions.

This prompt template is the core of your mock generation harness. It takes a tool contract schema—typically an OpenAPI snippet, a JSON Schema definition, or a structured description of inputs and outputs—and produces a catalog of mocked responses. The template is designed to be invoked programmatically, with placeholders that your test runner populates before sending the request to the model. The output is structured JSON that downstream validators can parse and compare against the original contract.

textCopy
You are a test data generator for an AI agent's tool integration harness. Your job is to produce realistic mocked responses for a single tool, given its contract. You must generate responses that cover success, error, and edge-case scenarios. Every response must conform to the declared output schema.

## TOOL CONTRACT
[TOOL_CONTRACT]

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## GENERATION CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES (Optional)
[EXAMPLES]

## INSTRUCTIONS
1. Parse the TOOL CONTRACT to understand the tool's purpose, arguments, and expected output shape.
2. Generate a JSON array of mocked response objects. Each object must have the following structure:
   {
     "scenario_id": "string identifier for the test case",
     "scenario_type": "success | error | edge_case",
     "description": "human-readable description of what this mock simulates",
     "input_arguments": { /* arguments that would trigger this response */ },
     "response_payload": { /* the mocked tool response, strictly conforming to OUTPUT_SCHEMA */ },
     "expected_agent_behavior": "description of how the agent should handle this response"
   }
3. Generate at least [MIN_SCENARIOS] scenarios, distributed across scenario_types.
4. For error scenarios, use realistic HTTP-level or application-level error structures as defined in the contract.
5. For edge_case scenarios, include: empty results, maximum-length strings, boundary numeric values, null fields where optional, and unexpected but valid response shapes.
6. Ensure every response_payload validates against OUTPUT_SCHEMA. Do not invent fields.
7. If the contract defines pagination, include at least one multi-page scenario.
8. If the contract defines rate limiting or retry-after headers, include at least one rate-limit scenario.
9. Do not include destructive or state-mutating argument values unless explicitly allowed by [RISK_LEVEL].
10. Output ONLY the JSON array. No markdown fences, no commentary.

To adapt this template, start by populating [TOOL_CONTRACT] with the raw API specification or a structured summary of the tool's behavior. The [OUTPUT_SCHEMA] placeholder should contain the exact JSON Schema or type definition that the tool's response is expected to match—this is what your compliance checker will validate against. Use [CONSTRAINTS] to inject domain-specific rules, such as 'never generate PII in mock data' or 'all IDs must be valid UUIDs.' The [EXAMPLES] placeholder is optional but valuable: include one or two hand-crafted mock responses to set the tone and structure the model should follow. Set [MIN_SCENARIOS] based on your coverage requirements—start with 5 for a quick smoke test, 15–20 for a thorough integration suite. The [RISK_LEVEL] placeholder should be set to low, medium, or high to control whether destructive argument values (deletes, writes, privilege changes) are included in the generated mocks. For high-risk tools, always set this to high and add a human review step before the mocks are used in any test that touches real systems.

The mock tool response generation prompt is designed to be called programmatically as part of a CI/CD pipeline or pre-release test suite. You will typically invoke it once per tool contract, requesting a batch of responses that cover success, error, and edge-case variants. The prompt expects a structured tool contract as input—usually a JSON Schema or OpenAPI fragment—and returns a JSON array of response objects. Wire this into your test harness by first loading the tool contract from your API spec or tool registry, then constructing the prompt with the contract injected into the [TOOL_CONTRACT] placeholder and the desired variant count in [VARIANT_COUNT]. The model should be instructed to return only valid JSON matching the declared output schema, with no additional commentary.

After receiving the generated responses, run each one through a schema compliance validator that checks: (1) the response parses as valid JSON, (2) all required fields from the tool contract's output schema are present, (3) field types match the declared types, (4) enum fields contain only allowed values, and (5) no extra fields appear unless the schema permits additional properties. For error variants, validate that the error structure matches your standard error envelope (e.g., error.code, error.message, error.retryable). Log any schema violations and flag the generated response for manual review or regeneration. If more than 10% of generated responses fail validation, retry the prompt with a stricter [CONSTRAINTS] block that explicitly forbids schema deviations and provides a counterexample of a malformed response.

For production-grade harnesses, store each generated mock response alongside its expected agent behavior contract—the assertion that defines how the agent should react when it receives this response. This pairing enables automated end-to-end tests where the mock is injected into the agent's tool call layer and the agent's subsequent action is compared against the expected behavior. Use a model with strong JSON mode support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature between 0.7 and 0.9 to ensure response diversity across variants. For high-risk tool contracts (write operations, financial transactions, PII access), always include a human review step before mock responses are committed to the test suite. Finally, version-lock your generated mocks alongside the tool contract version they were generated from, and regenerate them whenever the contract's output schema changes—stale mocks are the most common source of false-positive agent behavior tests.