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

With no annotations provided, the description carries the full burden and does well by disclosing the dry-run/confirm safety pattern and the implicit side effect of search_now starting downloads. It omits permission/auth requirements, what happens if the item already exists, and error behavior, leaving some behavioral gaps.

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?

Front-loaded with the action, followed by a compact per-parameter list and the confirm workflow. Every line earns its place and there is no filler or repetition.

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 six-parameter mutation tool with no annotations, the description covers purpose, parameter meaning, and the critical confirm workflow; the presence of an output schema removes the need to describe return values. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 0%, so the description must compensate, and it does: it defines service, explains external_id's dual meaning (TVDB for shows, TMDB for movies) and where to get it, clarifies the empty-string default semantics for quality_profile and root_folder, and describes search_now and confirm. All six parameters get meaningful interpretation beyond the bare schema.

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 opens with a specific verb+resource pair ('Add a show to Sonarr or a movie to Radarr') and names both target services, so the agent immediately knows the effect and scope. It is clearly distinguishable from siblings like arr_search (lookup) or arr_queue (monitoring).

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?

It gives explicit procedural guidance for the two-phase confirm flow ('First call without confirm... then call again with confirm=true') and points to arr_search as the source of the external_id. It does not state when *not* to use the tool (e.g. for existing items already in the library), so it stops just short of the top band.

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

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

With no annotations provided, the description carries the full behavioral burden. It confirms the tool reads upcoming items, but says nothing about whether results are read-only, whether it requires configured services, how many entries are returned, or any rate/refresh constraints. For a no-annotation tool this is a significant gap.

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?

A single, front-loaded sentence with zero filler. The service-to-content mapping is delivered before anything else, and nothing is repeated from the title or schema.

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?

An output schema exists, so return values need not be explained. The description adequately covers the two optional parameters at a high level but omits any behavioral or prerequisite context, leaving it minimally viable rather than complete.

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 schema declares no enums, so the description is doing real work by revealing that 'service' accepts sonarr or radarr. However, it leaves the 'days' parameter undescribed (only echoed as 'next days'), so half the parameters remain semantically thin.

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 states a specific resource (upcoming episodes or movie releases) and ties each to its backing service (sonarr/radarr), so an agent can tell it apart from siblings like arr_queue or arr_status. It is clear but stops short of explicitly positioning itself relative to those siblings.

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 phrase 'for the next days' implies a forward-looking calendar lookup, but there is no explicit when-to-use guidance, no when-not condition, and no mention of any alternative tool such as arr_search or arr_queue. The agent must infer the use case entirely.

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

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

With no annotations, the description carries the full burden and delivers: it discloses the confirm gate, the exact confirm_phrase format for destructive classes of calls (delete, restart, backup restore, host/security settings, password changes), the no-query-string constraint on path, and the per-service body rules. This is exactly the behavioral context an agent cannot get from the schema.

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?

Front-loads the one-line purpose, then a labeled block per parameter, then the safety workflow. Length is justified by 8 parameters and a non-obvious confirmation protocol; every sentence is functional and none restates the schema.

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 high-complexity, unannotated, multi-service mutation tool the description covers the safety-critical behavior thoroughly, and the existing output schema removes any need to explain return values. Remaining gaps are secondary: no auth/permission notes, no rate-limit or pagination guidance, and max_chars is unaddressed.

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 description coverage is 0%, so the description must supply all meaning and it nearly does: service (with valid values), path (format, examples, and the 'no query string' rule), method (enum), params (query options vs. qBittorrent form fields), body (JSON for POST/PUT, unused by qBittorrent), and confirm/confirm_phrase (trigger conditions and exact format). Only max_chars is left unexplained, a minor omission against otherwise complete coverage.

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?

States a specific verb and resource ('Call any API path on a service') and immediately enumerates the services and path forms, making the low-level escape-hatch scope unambiguous next to the specialized siblings like arr_search and arr_status. An agent can tell this is the generic call-through tool without opening the schema.

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?

Gives clear when-to-use rules for the write path: GET runs at once, any change waits on confirm=true, and the user must be told and give a clear yes first. It also prescribes the read-before-write workflow ('Never guess a body: read an existing item with GET first'). It never routes the agent to a specialized sibling when one exists, which is the one missing piece.

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

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

No annotations are provided, so the description carries the full burden. 'Show' implies a read-only listing and the filter states hint at stateful results, but there is no mention of pagination behavior, sort order, or how limit interacts with the filter. Because an output schema exists, return format need not be explained, which keeps this at a middling score rather than lower.

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?

Extremely terse and front-loaded: the purpose is in the first line and the filter vocabulary follows immediately. Nothing is padded, though the dangling enum list is slightly raw rather than integrated into a sentence.

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?

With an output schema present, return values need not be described, and the filter vocabulary is covered. What is missing for an agent to call this correctly is the semantics of limit and any hint of how this tool relates to arr_queue or arr_status.

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 description coverage is 0%, so the description must compensate, and it does document the full set of filter values (all, downloading, seeding, completed, paused, active, stalled, errored) beyond what the bare string schema provides. However, the limit parameter (default 30) is entirely undocumented, leaving half the parameters without meaning.

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?

States a specific verb and resource ('Show qBittorrent torrents'), and naming qBittorrent narrows it versus a generic download queue. It does not, however, explicitly distinguish itself from close siblings such as arr_queue or arr_status, so an agent must infer the boundary.

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 explicit when-to-use or when-not-to-use statement and no named alternative among the nine siblings. Usage is only implied by the list of filter states, which suggests checking torrent status, but nothing routes the agent between this and arr_queue.

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

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

No annotations, so the description carries the full behavioral burden. It states nothing about read-only nature, auth requirements, pagination, or freshness of the queue data. For a no-annotation tool, this is a significant gap.

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?

Two short sentences, purpose first, then the parameter legend. No filler.

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?

Output schema exists so return values needn't be explained. But with zero annotations and zero schema coverage, the description leaves auth, read/write semantics, and result freshness unstated – a notable gap for a queue-inspection tool.

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%, so the description must compensate. It lists the valid values ('sonarr, radarr, or empty for both') and explains the empty default, which is valuable. However, it omits format/quoting details and doesn't clarify that empty is the default when omitted.

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?

Specific verb ('Show') and resource ('what Sonarr and Radarr are downloading right now'), explicitly scoped to two apps. No ambiguity vs. siblings like arr_status or arr_downloads.

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?

Implies usage (check current downloads), but gives no when/when-not guidance or directs to alternatives such as arr_downloads. Adequate minimum without explicit routing.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Show' implies read-only and it discloses the filter vocabulary and the approve/decline handoff, but it says nothing about authentication needs, result ordering, rate limits, or pagination behavior (the take parameter is left unexplained).

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?

Front-loaded purpose sentence followed by the filter vocabulary and the sibling handoff; no filler. The stray blank line and terse fragmented formatting cost it marginally.

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?

An output schema exists, so return values need not be described. For a simple filtered-list tool the description covers what it does, the filter values, and where to go for approval actions. The only real gap is the undocumented 'take' paging parameter.

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?

With 0% schema description coverage, the description must compensate. It does document the valid filter values, which is genuinely useful since no enum is attached in the schema, but it never names 'take' or explains the default/paging semantics. Partial compensation only.

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?

States a specific verb and resource ('Show Overseerr requests') and enumerates the filter states, which lets an agent tell it apart from sibling read tools like arr_queue or arr_search. It is a clear read/list tool, though 'Show' is slightly less precise than 'list'.

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?

Explicitly routes mutation of requests to a sibling ('To approve or decline, use arr_call with POST /request/<id>/approve'), which is exactly the kind of when-to-use-else guidance that matters. It does not state when a caller should prefer this over arr_search or arr_queue, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that nothing is added and that 'in_library' indicates pre-existence, but omits auth requirements, rate limits, and error behavior for a lookup against external services.

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?

Short, front-loaded, and every line carries information; the only minor cost is the choppy fragment style that separates the routing note from the main sentence.

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?

An output schema exists, so return values needn't be spelled out, yet the description still adds value by explaining the id and in_library fields. It covers both parameters adequately for a simple two-param lookup.

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 description coverage is 0%, so the description must compensate. It explains the service parameter's meaningful values, but leaves 'term' undocumented beyond the implicit 'by name' phrasing and doesn't clarify matching behavior.

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?

States a specific verb+resource ('Look up a show or movie by name') and clarifies the non-mutating nature with 'Nothing is added.' It also distinguishes itself from arr_add by explaining the returned id feeds into it, though it doesn't differentiate from arr_call or arr_requests.

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?

Gives the service routing values (sonarr/radarr/overseerr) and implies the search-then-add workflow by pointing to arr_add, but never states when to use this versus arr_call or arr_requests, nor any prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the output shows addresses only and never keys, which is meaningful privacy behavior, but it does not explicitly state read-only semantics, permission requirements, or other operational constraints.

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 two short sentences with no waste. The purpose is front-loaded, the service examples add useful specificity, and the privacy note earns its place.

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, the description covers the essential purpose and output privacy. It does not need to explain return values because the output schema exists, though it could be slightly more complete by clarifying read-only behavior or usage context relative to siblings.

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 tool takes zero parameters, so there is no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description does not need to add anything further here.

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 states a specific verb and resource: list which services are set up. It enumerates the exact services covered and makes clear this is a configuration-inventory tool, distinguishing it from siblings such as arr_status, arr_queue, arr_search, and arr_add.

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 explicit when-to-use guidance, no when-not-to-use guidance, and no mention of alternatives such as arr_status or arr_call. The purpose implies the tool can be used to discover configured services, but the description does not route the agent between this and sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only diagnostic (checking, reporting version and warnings) and an output schema exists to cover return values, but there is no disclosure of auth needs, rate limits, or failure behavior for unreachable services.

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?

Three short lines, front-loaded with the core purpose before the parameter note. Every sentence carries information, though the clipped phrasing ("Check that services answer") reads slightly telegraphic rather than polished.

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?

An output schema exists, so return values need no explanation, and the single parameter is documented in the description. For a one-param, zero-annotation health-check tool this covers what an agent needs, with only permissions and error semantics left unstated.

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 description coverage is 0%, so the description must compensate, and it does: it explains that service takes one name or empty for all configured services, which clarifies the otherwise opaque default of "". It could add naming format or valid service identifiers to reach a 5.

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?

States a specific action (check that services answer) and the data returned (version and health warnings), which is a distinct purpose from siblings like arr_services or arr_queue. It does not explicitly name a sibling it differs from, so it stops short of a 5.

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 gives one concrete usage rule – leave service empty to check every configured service – which tells the agent how to invoke it broadly. It offers no when-not guidance and never contrasts with sibling tools such as arr_services, leaving selection to inference.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that this is a live point-in-time snapshot ("right now") covering active sessions and their devices, but says nothing about authentication needs against the Jellyfin server, whether inactive/paused sessions are included, or any rate considerations.

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?

A single short sentence that front-loads the subject (who is watching) and appends the returned attribute (device). No filler, no restatement of the tool name.

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?

With zero parameters and an output schema present, the description does not need to explain return values, and it correctly stays brief. The remaining gap is environmental context (which Jellyfin instance/connection it queries), which is minor for a simple status read.

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 tool takes no parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies for a zero-argument tool.

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?

States a concrete verb ("Show") and a concrete resource ("who is watching on Jellyfin right now"), plus the returned detail (device). The only sibling tools are arr_* integrations, so there is no competing Jellyfin tool to distinguish from, but the description also doesn't scope itself against any other session/status query.

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 explicit when-to-use or when-not-to-use guidance and no named alternative. For a zero-parameter, read-only snapshot tool the invocation context is largely self-evident from the name and description, which lands it at implied usage rather than explicit routing.

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