radarr_test_notification

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

The description adds 'WRITE: this modifies your Radarr instance' which is useful behavioral context beyond the annotations (readOnlyHint=false already implies write, but explicit statement adds clarity). However, it does not disclose what exactly is modified, whether the test sends a real notification, or the side effects. The 'Returns validation results' is mentioned, but little else is revealed.

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 extremely short but not effectively structured. The first sentence 'Test test' is confusing and wastes space. The subsequent fragments about force_test, validation results, and write warning are not organized into a coherent flow. While brevity is good, this is under-specification rather than clarity.

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 the tool has two parameters including a free-form 'body' and an output schema, the description is highly incomplete. It does not explain what the test does, what parameters control, or what the validation results mean. The presence of an output schema helps but does not replace the need for context about inputs and purpose.

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 coverage is 0%, and the description only mentions 'optionally force_test' without explaining what forcing does. The 'body' parameter is completely undocumented, even though it is a free-form object with additionalProperties. The description fails to compensate for the lack of schema descriptions, providing minimal meaning beyond parameter names.

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 starts with 'Test test' which is essentially a tautology—it just repeats the verb from the tool name without specifying what 'test' refers to. It does not explicitly state that this tests notifications, and neither does it name the resource. The phrase 'Returns validation results' hints at function but remains ambiguous. This fails to clearly differentiate from sibling tools like radarr_test_downloadclient or radarr_test_indexer.

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 versus alternatives. The description only warns that it modifies the instance, which is a caution, not a usage guideline. No mention of when this is appropriate or how it relates to other test actions (e.g., radarr_test_all_notification).

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