radarr_create_remotepathmapping

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's 'WRITE: this modifies your Radarr instance' adds a small amount of context by explicitly stating the modification side effect. However, it does not disclose other behavioral traits such as required permissions, idempotency, or error behavior, which are not covered by annotations. This is adequate but not rich.

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 concise and front-loaded with the primary purpose. Every word earns its place; the 'WRITE: this modifies your Radarr instance' is a meaningful behavioral note while remaining succinct. No redundancy or unnecessary detail.

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?

Despite the tool having an output schema, the description is incomplete for a create operation with a generic body parameter. It does not explain what a remote path mapping is, what fields the body should contain, how to obtain valid values, or any prerequisites. Given the low schema coverage and the write nature of the tool, the description provides insufficient context for correct invocation.

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 defines a single 'body' object with additionalProperties:true and no property descriptions (0% schema coverage). The description does not mention any parameter details, field requirements, or structure expectations. The agent is left completely in the dark about what constitutes a valid remote path mapping, so the description fails to compensate for the schema's lack of information.

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 'Create remote path mappings' clearly states the specific verb ('Create') and resource ('remote path mappings'), which immediately distinguishes it from sibling tools like update_remotepathmapping, delete_remotepathmapping, and list_remotepathmapping. The additional 'WRITE: this modifies your Radarr instance' reinforces the operation type without confusion.

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?

The description provides no explicit guidance on when to use this tool versus alternatives, but the verb and resource make the intended usage clear (i.e., use this to create a new remote path mapping, not to update or delete one). This is implied rather than stated, meriting a score of 3 rather than 4.

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