Tool Call Argument Deduplication Prompt Template

This prompt is designed for batch processing engineers and agent platform developers who need to clean up tool call arguments before execution. It targets a specific failure mode: a model generates a valid function call, but the arguments contain duplicate entries in arrays, redundant key-value pairs, or semantically equivalent values that will cause downstream API errors, wasted compute, or incorrect results. Use this prompt as a post-generation repair step in your agent loop, after JSON validation passes but before the tool call is executed.

The ideal user is an engineer building an agent harness or a batch processing pipeline where a model's tool calls are intercepted by a validation layer. If your system already parses the model's output into a structured object and validates it against a JSON schema, this prompt fits directly into the error-recovery path. It is not a general-purpose deduplication system for database records or user-generated content. It assumes you already have a parsed tool call object and the tool's JSON schema available. The prompt works best when the duplicates are obvious (e.g., the same string appearing twice in an array) or structurally detectable (e.g., two keys with identical values in a dictionary).

Do not use this prompt when the duplicates are semantic but not structural—for example, two array entries that mean the same thing but use different phrasing. This prompt is not a semantic deduplication engine. It also should not be used for removing legitimate repeated values that are valid in the target API (e.g., sending the same notification to multiple recipients). Always check the tool's schema to understand whether repetition is intentional before invoking this repair step. If the tool's contract allows duplicates, skip this prompt to avoid false-positive removals.

Before wiring this into production, define clear evaluation criteria: the repaired arguments must contain no duplicate entries, must preserve all unique values from the original, and must not alter the types or structure of the arguments. A common failure mode is over-aggressive deduplication that removes values that appear similar but are distinct in the target domain. Start by running this prompt against a golden dataset of known duplicate and non-duplicate cases to calibrate your confidence threshold before enabling automatic repair.

This template is designed to be pasted directly into your repair harness when a tool call has passed basic JSON validation but contains argument-level duplication that would cause redundant processing, conflicting instructions, or wasted compute. It targets two primary failure modes: repeated entries in array arguments (e.g., the same file path listed three times) and conflicting duplicate keys where a parameter is specified more than once with different values. The prompt instructs the model to act as a deduplication engine, returning a cleaned version of the arguments without altering the intended function or removing semantically distinct values.

textCopy
You are an argument deduplication engine. Your task is to analyze the arguments of a single tool call and remove duplicate or redundant values without changing the intended action.

**Tool Name:** [TOOL_NAME]
**Tool Description:** [TOOL_DESCRIPTION]
**Argument Schema:**
[TOOL_ARGUMENT_SCHEMA]

**Original Arguments:**
[ORIGINAL_ARGUMENTS_JSON]

**Deduplication Rules:**
1. **Array Deduplication:** For any array argument, remove exact duplicate values. Preserve the order of first occurrence.
2. **Conflicting Duplicate Keys:** If the same parameter key appears more than once with different values, resolve the conflict by selecting the value that appears most frequently. If there is a tie, select the last occurrence. Note the conflict and your resolution in the `deduplication_log`.
3. **Semantic Duplicate Detection:** For array arguments containing strings, identify and remove values that are semantic duplicates (e.g., "create a file" and "create the file"). Preserve the most explicit or complete version. If unsure, do not deduplicate.
4. **Do NOT remove:** Values that are distinct, even if they appear similar. When in doubt, preserve the value.

**Output Format:**
Return a valid JSON object with exactly two keys:
- `deduplicated_arguments`: The cleaned arguments object, conforming to the provided schema.
- `deduplication_log`: An array of strings describing each deduplication action taken (e.g., "Removed duplicate value 'X' from array 'Y'", "Resolved conflicting key 'Z': selected value 'A' over 'B'"). If no duplicates were found, this array should contain the single string "No duplicates found."

**Output Constraint:** Return ONLY the specified JSON object. Do not include any explanatory text outside the JSON.

To adapt this template, replace the square-bracket placeholders with your specific context. [TOOL_NAME] and [TOOL_DESCRIPTION] provide the model with the tool's purpose, which is critical for accurate semantic deduplication. [TOOL_ARGUMENT_SCHEMA] should be the JSON Schema for the tool's parameters, enabling the model to identify array fields and understand the expected structure. [ORIGINAL_ARGUMENTS_JSON] is the failing argument payload. Before wiring this into a production loop, you must implement a validation check on the output to ensure the deduplicated_arguments still conforms to the original [TOOL_ARGUMENT_SCHEMA]. A common failure mode is the model removing a value that was a legitimate, distinct entry, so your evaluation suite should include test cases with near-duplicate but semantically distinct values to measure the false-positive rate of the deduplication.

The deduplication prompt is designed to be called as a post-processing step within a tool execution pipeline, not as a standalone user-facing feature. After an agent generates a tool call but before the arguments are dispatched to the target API, insert this prompt as a repair gate. The harness should extract the tool call arguments, pass them alongside the tool's JSON schema and any deduplication rules to the prompt, and then validate the returned arguments against the original schema before forwarding them. This placement prevents duplicate work from reaching downstream systems and reduces the cost of redundant API calls.

Build the harness with a validate-repair-retry loop that respects a strict budget. First, validate the original tool call arguments against the expected schema. If validation passes, run the deduplication prompt and validate its output. If the deduplication prompt introduces new schema violations, feed the validation error back into a generic repair prompt for one correction attempt. If that fails, log the failure and fall back to the original, validated arguments with a warning flag. Set a maximum of 2 repair attempts total to avoid infinite loops. Log every step—original arguments, deduplication diff, validation result, and final dispatched payload—as structured JSON for observability. Use a model with strong JSON mode support (such as gpt-4o or claude-3-5-sonnet) and set temperature=0 to minimize non-deterministic changes to the argument set.

The primary production risk is false-positive deduplication, where the prompt removes semantically distinct arguments that appear textually similar. Mitigate this by implementing a post-deduplication semantic similarity check. For array arguments, compute pairwise embeddings of the remaining items; if any two items exceed a cosine similarity threshold (e.g., 0.92), flag the output for human review rather than silently dispatching. For key-value duplicate detection, require the prompt to output a deduplication_rationale field explaining why each removal was made. Store this rationale in your audit log and surface it in any review queue. Do not use this prompt on tool calls where argument order is semantically meaningful unless the prompt explicitly includes an ordering preservation constraint.