Remove duplicate values from a list while preserving original order, using JSON serialization to handle mixed data types.
Remove duplicates from a list, preserving order.
Uses JSON serialization for dedup keys to handle mixed types.
Args: items: The list to deduplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it usefully discloses the dedup-key mechanism ('Uses JSON serialization for dedup keys to handle mixed types'), which tells the agent how equality is judged for unhashable/mixed inputs. It omits nothing critical for a pure side-effect-free transformation, though it doesn't state that the input list is not mutated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences followed by an Args block; the ordering guarantee, the most important behavioral fact, comes first. The Args line mildly restates the prose ('The list to deduplicate' after 'Remove duplicates from a list'), a small redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and with one required parameter the surface area is tiny. The description covers purpose, ordering, and dedup semantics adequately, leaving only minor gaps such as mutation behavior and empty-input handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter, so the description must compensate and it does: it names the argument and explains its role ('The list to deduplicate') and adds dedup-key semantics for mixed types. Detail is thin—nothing about element types or empty-list behavior—so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Remove duplicates from a list') plus the key qualifier 'preserving order', so the operation is unmistakable against siblings like collection_sort or collection_merge. It stops short of naming or distinguishing itself from those alternatives explicitly, so it does not reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative routing content. The sibling set contains several overlapping collection tools (sort, flatten, merge, filter_gt, group_by), yet the description offers no cue for choosing this one over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.