qui_check_duplicate_torrents

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior, but it does not. It merely gives endpoint invocation details (path variables, query params, body) and implies a POST request, but never states what the tool does, its side effects, or the nature of the operation. This is a generic boilerplate description for any qui API tool.

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?

The description is a single sentence with no redundant wording, making it concise and free of fluff. However, it is under-specified and lacks front-loaded purposeful content, but the dimension focuses on structure and economy of language, which is acceptable here.

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?

Given that the tool performs a specific duplicate-check operation and has a large sibling set, the description is severely incomplete. It fails to convey the tool's purpose, making it impossible to know when to use it. Even though an output schema exists, the missing definition of what the tool does means the description is not contextually complete.

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?

The schema has only an 'arguments' object with no meaningful properties, and schema coverage is 0%. The description offers a generic pattern: 'Pass path variables directly in arguments, query values in arguments.params, and a JSON request body in arguments.body.' This hints at how to structure arguments but does not specify which path variables, query parameters, or body fields are required for this particular endpoint. It does not compensate for the missing schema details.

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?

The description only repeats the endpoint path and tool name, saying to call the POST /instances/{instanceID}/torrents/check-duplicates endpoint. It never explicitly states that the tool checks for duplicate torrents or what its actual function is, making it a near-tautology. No verb-resource description or differentiation from siblings is provided.

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 guidance on when to use this tool or how it differs from sibling tools like qui_list_torrents or qui_cross_seed_apply. The description solely focuses on how to call the endpoint without any contextual or exceptive information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.