Skip to main content
Glama

radarr_action_downloadclient

Run a defined action on a Radarr download client by name, sending a write request to modify your Radarr instance.

Instructions

Run an action on a action (name selects the action). WRITE: this modifies your Radarr instance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNo
nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior2/5

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

The 'WRITE' warning merely restates the annotation readOnlyHint=false and adds no detail about what modifications occur, whether the operation is reversible, or whether it can cause side effects. Not enough behavioral context is disclosed beyond the structured annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief but under-specified. The awkward phrase 'action on a action' wastes the few words used, and the 'WRITE' sentence is the only useful part. It reads more like an incomplete stub than a concise explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, return values may be self-documenting, but the description still fails to clarify what 'action' means, what the 'body' should contain, or how the download client is selected. The tool is too ambiguous to use confidently without external documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It only clarifies that 'name' selects an action, while the 'body' object is completely unexplained. The freeform body parameter likely carries important action-specific data, but users receive no guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description reads 'Run an action on a action', which is tautological and confusing—it doesn't explain what the action does or that it applies to download clients beyond the tool name. It fails to clearly distinguish this from sibling action tools like radarr_action_indexer or radarr_action_notification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 alternatives. The only hint is that 'name selects the action', but there is no explanation of what actions are available, what context they apply to, or any prerequisites/exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SavageCore/radarr-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server