Skip to main content
Glama
rollecode

Sonarr MCP server

by rollecode

get_config_downloadclient_by_id

Read-onlyIdempotent

Fetch download client configuration by ID. Retrieve the exact settings for a specific client to verify or troubleshoot its setup.

Instructions

Read DownloadClientConfig.

GET /api/v3/config/downloadclient/{id}

Args: id: Path parameter.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.9/5.0
Behavior2/5

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's 'Read' adds no behavioral information beyond them. It does not mention response behavior, error cases, or any additional side effects, though annotations already cover the main safety profile.

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

Conciseness4/5

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

The description is short and front-loaded with the core action, then gives the endpoint and parameter. No filler is present. It is appropriately sized for such a simple tool, though it is sparse.

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

Completeness3/5

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

With one required parameter, a clear endpoint, an output schema, and safety annotations, the description is mostly sufficient to invoke the tool. However, it lacks clarification of what DownloadClientConfig is and how it differs from related download-client tools, leaving some contextual gap.

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

Parameters3/5

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

The schema has 0% description coverage, and the description only says 'id: Path parameter.' This adds the useful detail that id is a path parameter rather than query or body, but it does not explain what the id represents or any expected format beyond the schema's integer type.

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

Purpose4/5

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

States a specific verb and resource: 'Read DownloadClientConfig.' The endpoint path further clarifies the target. However, it does not explicitly distinguish this from the sibling get_downloadclient_by_id, leaving potential ambiguity about the difference between a download client and its config.

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?

Provides no guidance on when to use this tool versus alternatives such as list_config_downloadclient, get_downloadclient_by_id, or update_config_downloadclient_by_id. The agent must infer usage from the name and endpoint.

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

Deploy Server

Other Tools