radarr_test_all_downloadclient

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

The explicit 'WRITE: this modifies your Radarr instance' warning adds useful plain-language disclosure beyond the annotations' readOnlyHint: false, which makes the side effect unambiguous. However, it doesn't detail what modification occurs (e.g., test commands sent to all clients) or failure behavior, so the transparency is shallow. No contradiction with annotations.

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 short and front-loaded with the WRITE warning, which earns points for brevity. However, the phrasing 'Test testall' is awkward, jargon-heavy, and sacrifices clarity — it reads like API-endpoint residue rather than a well-structured description.

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?

For a zero-parameter tool with an output schema and annotations present, the description covers the essentials: the testing action, return of validation results, and a write warning. But the ambiguous 'testall' terminology and the dangling force_test reference create enough confusion that the description is only minimally viable.

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 input schema is empty with additionalProperties: false (0 parameters), yet the description mentions 'optionally force_test,' implying a parameter that cannot actually be passed to this tool. This is actively misleading rather than adding semantic value, fully forfeiting the 0-parameter baseline of 4.

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 says 'Test testall (optionally force_test)' — a cryptic phrase that essentially restates the tool's name ('test_all_downloadclient' becomes 'testall') rather than clearly stating it tests all download clients. The only clear purpose signal is the tool name itself, and the mention of force_test implies a parameter the schema does not accept, muddying the purpose further.

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?

No guidance is given on when to use this tool versus the sibling radarr_test_downloadclient (single-client test) or other 'test_all' siblings like radarr_test_all_indexer. There are no stated use cases, exclusions, or alternative recommendations, so an agent gets no help choosing between this and the single-client variant.

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