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 does so: it discloses that API roots are injected per service, that Plex /accounts is blocked, that Plex responses are forced to JSON, that Tdarr read modes via /cruddb run immediately while other modes need confirmation, and that changes are staged until confirm=true. The confirm_phrase format and example, plus 'never guess a body: read with GET first', are exactly the behavioral context an agent needs.

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?

Purpose is front-loaded in the opening line and the rest is dense per-parameter and per-service reference material with almost no filler. It reads as fragmented schema-style fragments rather than prose, and the confirm rules are split across two paragraphs, but nothing is genuinely wasteful.

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 complex, unannotated 8-parameter passthrough this is close to sufficient: service routing, auth-adjacent safety, and service quirks are all covered, and an output schema exists so return values need not be explained. Gaps remain around max_chars truncation behavior and what happens on API errors or partial failures.

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, and it does for seven of eight parameters: service values, path format and query-string prohibition, allowed methods, params semantics (including qBittorrent form fields), body usage limits, confirm, and confirm_phrase. The exception is max_chars, which is never mentioned despite controlling output truncation.

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 enumerates the exact service set plus example paths, so an agent knows this is a raw API passthrough. It does not, however, contrast itself with the many purpose-built siblings (arr_search, arr_add, arr_queue, plex_libraries), which an agent may pick first.

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 conditional context: GET runs immediately, mutations require confirm=true and user approval, and destructive operations additionally require a formatted confirm_phrase with a worked example. It stops short of saying when to prefer a dedicated sibling tool over this escape hatch, so the alternative-selection guidance is incomplete.

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, but the wording 'Show' implies a read-only operation. The description does not explicitly state permissions, side effects, or rate limits; the output schema covers return shape, which reduces the disclosure burden, but behavioral details remain thin.

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 definition is front-loaded with the purpose, followed by the filter values and the approval alternative. Every sentence is relevant, and there is no redundant or filler text.

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 simple read/list tool with an output schema, the description covers the main purpose, valid filters, and the out-of-scope approval flow. The only notable gap is the unexplained 'take' parameter, but an agent can still invoke the tool via defaults.

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 usefully lists all filter values for the 'filter' parameter, but it never explains the 'take' parameter, leaving one of two parameters undocumented in both schema and description.

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: 'Show Seerr requests.' It also enumerates request filters and explicitly distinguishes approval/decline actions as belonging to arr_call, so an agent can tell this is a read/list tool rather than a decision tool.

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 clearly routes approval or decline actions to arr_call with the relevant POST endpoints and adds the important condition 'after the user says yes.' It does not explicitly contrast this tool with other siblings such as arr_search or arr_downloads, but the intended usage is clear.

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 full burden; it does disclose the key safety fact that nothing is created ('Nothing is added') and that an 'in_library' flag is returned. It omits matching behavior, multi-result handling, and any auth/rate-limit context for the three backing 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 terse lines: purpose first, then parameter mapping, then return hints. Every line carries information, though the telegraphic style ('Nothing is added.' as a standalone sentence) is slightly fragmented.

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 explained, and the description covers purpose, service mapping, and the follow-up call. It still leaves open whether multiple matches can come back and what the term matching rules are, which matters for a search 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 description coverage is 0%, so the description must compensate. It does so well for 'service', spelling out sonarr=shows, radarr=movies, seerr=both — information the schema lacks entirely. 'term' is only implied by 'by name', with no note on partial/fuzzy matching.

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 ('Look up a show or movie by name') and immediately clarifies 'Nothing is added,' which separates it from the write sibling arr_add. It does not name every adjacent sibling (arr_requests, arr_services), but the read-only lookup intent is unambiguous.

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?

'Shows the id to use with arr_add' implies the workflow (search first, then add), which is useful context. However, there is no explicit when-to-use vs. when-not, and no guidance on choosing arr_requests or arr_services for other lookups.

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 does add one genuinely useful disclosure: 'Shows addresses only, never keys,' which reassures about secret exposure. However, it doesn't explicitly state the operation is read-only (only implied by 'List') or note any auth requirements.

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, zero waste, with the core purpose front-loaded and the security caveat appended where it matters.

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?

A zero-param read tool with an output schema, so return-value detail is unnecessary; the description covers scope and the key safety caveat. Only the read-only/auth framing is left implicit.

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?

Zero parameters, so there are no semantics to document; baseline applies. The description correctly implies a no-argument call.

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 ('List') and resource ('services set up') and enumerates the covered service types, so an agent knows exactly what comes back. It doesn't explicitly differentiate against siblings like arr_status or arr_calendar, which keeps it 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?

Usage is only implied: an agent can infer this is a discovery/configuration-enumeration call preceding arr_add or arr_call, but the description never says when to use it versus arr_status or what a prerequisite relationship is.

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.

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

No annotations are supplied, so the description carries the burden, and it does disclose the payload contents (folders plus per-library item counts), which implies a read-only inventory. It never states that it is non-destructive, requires Plex server credentials, or whether item counts are cached/slow to compute — gaps for a tool with zero annotation coverage.

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 the verb first and the return contents second; nothing is redundant or padded.

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 only needs to convey purpose and scope, which it does in one line. Only the missing auth/cost context for a Plex server call keeps it from a 5.

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 no parameter semantics to explain and the baseline of 4 applies. The description correctly adds no invented parameter guidance.

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 ('List') applied to a specific resource ('Plex libraries') and even names the returned fields (folders, item counts), so the agent knows exactly what it gets. It does not explicitly contrast itself with the sibling plex_now_playing, which is why 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?

Usage is only implied: an agent can infer this is the discovery/inventory call to run before anything else Plex-related. There is no explicit 'use this when...' or pointer to plex_now_playing for active-session questions.

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 non-destructive read and the text previews the returned fields (viewer and device), but it says nothing about behavior when no one is streaming, session/auth requirements, or server scoping. The presence of an output schema offsets some of this.

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?

One short sentence, front-loaded with the core action and the returned content. Nothing superfluous.

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 no-argument, read-only status check with an output schema, the description covers what the tool does and what an agent gets back. Only the empty-session / error behavior is unaddressed, which is a minor gap.

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 are no parameter semantics to explain; baseline 4 applies. The description correctly implies the call needs no arguments.

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 who is watching on Plex right now, and on which device.' It is clearly a live-session read, distinguishable from plex_libraries (library contents) and from jellyfin_now_playing (different service). It does not explicitly name those siblings, so a 4 rather than 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?

'right now' implies this is for current live activity rather than historical or library queries, but the description never states when to use this over plex_libraries or jellyfin_now_playing. Usage is inferable rather than spelled out.

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. It discloses the contents of the payload (nodes, workers, state counts), which tells the agent this is a read-only observation call. It does not state whether the call is expensive/slow, whether it hits a live server, or how the aggregate is scoped.

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 lines, front-loaded with the outcome and then the one parameter, with zero filler. Nothing could be trimmed without losing information.

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-value explanation is unnecessary, and the single optional parameter is documented. For a simple read-only summary tool the description is nearly complete; only a note on read-only nature or cost would add value.

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, and it does: 'show_failed' is explained as a count of failed file names to list, plus a hard range of 0 to 50. The only gap is that the schema's default of 10 is not restated.

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') plus an enumerated payload: nodes, workers, and per-state file counts. An agent immediately knows this is a Tdarr status snapshot. It does not explicitly name or contrast with any sibling tool, which keeps it out of the top band.

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?

Usage is only implied by the verb 'Show' — the description never states when to reach for this versus other tools, nor any prerequisites. Because no other Tdarr tool appears among the siblings, there is little ambiguity to resolve, but the guidance is still inferential rather than stated.

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