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

With no annotations the description carries the full behavioral burden, and it discloses almost nothing: no indication that the add starts the torrent by default, that duplicates may be rejected, whether the operation requires elevated permissions, or how failures surface. The phrase 'or several at once' hints at batch behavior but doesn't say what happens per-URL on partial failure.

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 no filler, which suits a simple add operation. It is arguably too terse for a five-parameter mutation tool, so not a perfect score.

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, and all five parameters are documented in the schema. What's missing is the behavioral context a mutation tool needs: whether the add is destructive/irreversible, default start behavior, and duplicate handling.

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 100%, so baselines apply; the schema itself documents stopped, auto_tmm, category, and save_path in detail. The description only adds that urls accepts magnet or http(s) links and may be multiple, which slightly reinforces the schema without adding new 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?

Specific verb (Add) plus resource (torrent) and accepted input forms (magnet or URL), so the agent knows exactly what the call does. It does not, however, distinguish itself from siblings like control_torrents or delete_torrents beyond the verb itself.

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?

No statement of when to use this versus alternatives, no prerequisites, no note about duplicate torrents or auth requirements. The only implied usage is that you have a magnet/URL to submit.

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 load. It names 'remove' as an action, which implies a destructive operation, but gives no detail about permissions, reversibility, confirmation requirements, or side effects. The schema's 'confirm required for remove' is not reflected in the description.

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 a single, front-loaded sentence with no wasted words. It is concise and structurally clear, though its brevity contributes to other completeness gaps rather than being a structural flaw.

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 a fully described schema and an output schema present, the description need not explain return values. However, for a multi-action CRUD tool, it does not clarify which parameters apply to which action or highlight the confirmation requirement for removal, leaving some inference to the agent.

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 100%, so all four parameters are already documented in the schema. The description adds no parameter-specific meaning beyond the action list, which is already captured by the 'action' parameter 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 specific actions (list, create, edit, remove) on a specific resource (categories), making the tool's purpose immediately clear. It does not distinguish itself from similar sibling tools such as 'tags', but the verb-resource pairing 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?

The description provides no when-to-use guidance, no conditions for choosing among list/create/edit/remove, and no references to alternatives. It simply lists possible actions without helping an agent decide which action or tool applies.

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 must carry the behavioral burden. It usefully discloses that force_start ignores share limits and can bypass stop-on-complete, but it omits permissions, side effects, idempotency, and error behavior.

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 sentences, front-loaded with the core purpose and followed by a high-value caveat. There is no redundant or wasted 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?

The tool is simple, the schema fully documents parameters, and an output schema exists. The description covers the core actions and the key force_start caveat, though it does not mention unforce_start explicitly or broader mutation side effects.

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 100%, so the schema already documents both parameters. The description adds a useful caveat for force_start but does not add meaning for hashes beyond what the schema provides.

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 and action set: start, stop, recheck, or reannounce torrents. It is clearly a torrent-control tool, though it does not explicitly differentiate itself from siblings like delete_torrents or move_torrents.

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 implied by the listed torrent actions and the force_start caveat, but there is no explicit guidance on when to use this versus delete_torrents, move_torrents, or other siblings. Prerequisites or exclusions are not stated.

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 behavioral burden and does well: it discloses that deletion is irreversible, that confirmation is required, and that downloaded data remains unless delete_files is set. It could say more about effects on active torrents, but the core destructive behavior is clearly communicated.

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 sentences, front-loaded with the core action and immediately followed by the most important safety details. Every sentence 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 destructive tool with no annotations, the description covers the critical safety behavior: irreversibility, explicit confirmation, and non-implicit file deletion. Output schema presence means return values need not be explained, and remaining gaps are minor.

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 100%, so the baseline is 3. The description still adds meaningful semantics by emphasizing that delete_files is never implicitly applied and that data remains on disk without it, which clarifies the practical consequence of the default.

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: 'Remove torrents.' It clearly identifies the tool's operation, though it does not explicitly contrast it with siblings such as control_torrents or move_torrents.

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 provides important usage constraints: delete_files is not implied and confirm=True is required. However, it does not state when to choose this tool over alternatives like control_torrents, so usage guidance is only implied.

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. The verb 'List' and the phrase 'with its shape' imply a side-effect-free introspection call whose result includes endpoint schemas, but the description never affirms read-only safety, required auth, or how scope/mutating_only filtering changes the result.

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 with the action and target front-loaded; nothing is wasted and nothing is buried.

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 the return payload need not be described, and both parameters are documented in the schema. The description communicates the tool's purpose and its linkage to qbt_call adequately, though for an unannotated tool it could say more about it being a safe, read-only discovery call.

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 100%: the schema already documents 'scope' (filter to one scope) and 'mutating_only' (only endpoints that change state). The description adds nothing about either parameter, so the baseline of 3 applies.

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 (every endpoint qbt_call can reach), and explicitly ties itself to the sibling tool qbt_call, which no other sibling does. It does not distinguish itself from read-oriented siblings like server_info, but the reference to qbt_call makes its discovery role identifiable.

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 mention of qbt_call implies this is the discovery step before invoking that tool, but there is no explicit when-to-use, when-not, or named alternative. Usage is only inferable from the phrasing.

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, yet it discloses almost nothing: it doesn't say the operation is read-only, how results are paginated or ordered, or what happens with large result sets. Only the vague 'fields that usually matter' hints at return shaping.

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?

It is a single front-loaded sentence with no waste. Its brevity leans toward under-specification rather than genuine conciseness, keeping it short of a 5.

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 and the input schema is fully annotated, so return values and parameters are covered elsewhere. But with no annotations and no usage guidance, the definition leaves behavioral expectations (read-only nature, ordering defaults) to inference.

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 100%, so all six parameters (tag, full, sort, limit, status, category) are already documented in the schema. The description adds no syntax or semantic detail beyond what the schema provides, so the baseline 3 applies.

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 torrents') and hints at a curated field subset, distinguishing it implicitly from torrent_detail. However, 'the fields that usually matter' is vague and doesn't sharpen the differentiation from its 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?

There is no guidance on when to use this versus torrent_detail, search, or list_endpoints, and no statement of exclusions or prerequisites. The agent must infer the usage context 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 behavioral burden and discloses important traits: qBittorrent performs the move asynchronously, the call returns before completion, and the torrent remains valid. It does not cover permissions, destination conflicts, failure behavior, or whether existing data at the destination is overwritten, leaving some mutation-related 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?

The description is three tight sentences with the core action front-loaded. Each sentence adds useful information about behavior or the optional recheck, with 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?

The presence of an output schema reduces the need to explain return values, and the description covers the key async behavior and torrent validity. It still omits some operational details relevant to a mutation tool with no annotations, such as destination requirements and conflict handling.

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 100%, so the parameters are already documented clearly. The description reinforces that recheck is optional and rehashes data, but it does not add substantial meaning beyond the schema beyond that rationale.

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: moving a torrent's data to a new location. It clearly distinguishes this action from sibling tools like add_torrent, delete_torrents, and control_torrents, which do not move existing data.

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 some usage guidance by saying a recheck afterwards is optional and why, but it does not explicitly say when to use move_torrents versus alternatives or describe prerequisites. The intended use is implied by the clear purpose rather than stated with explicit comparisons.

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 it does disclose a genuinely important behavioral trait: security-sensitive keys (WebUI port, password, host-header validation) are refused with no override. It does not cover auth requirements, whether writes persist or need a restart, or side effects, but the refusal disclosure is substantive non-obvious context.

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 tight sentences with the core action front-loaded and the safety constraint second. Nothing is wasted and the structure leads with what the tool does.

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 all three params are documented in the schema. The description adds the critical refusal behavior, leaving only auth/persistence details as minor gaps.

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 100%, so the schema already documents keys, action, and values. The description only loosely echoes 'subset'/'read/write' without adding format or syntax detail beyond the schema, so the baseline 3 applies.

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 dual-mode verb (read/write) on a specific resource (preferences) and clarifies that writes apply only to a subset. This clearly sets it apart from the torrent-management siblings, though it never names an alternative tool explicitly.

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 implied by 'read preferences, or write a subset,' and the refusal rule hints at when writes will fail, but there is no explicit guidance on when to choose this tool over qbt_call or other siblings, nor any stated 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?

With no annotations, the description carries the full burden and does so well: it discloses that params are validated against the endpoint spec, that destructive endpoints require 'confirm', and that read-only mode refuses state-mutating calls. It does not describe error behavior or pagination, but the safety-gate disclosure is substantive and non-obvious.

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 tight sentences with no filler. The fallback purpose is front-loaded in the first clause and the safety behavior follows, so an agent gets the key facts immediately.

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, and the description covers purpose, routing, validation, and safety gates. What remains thin is guidance on malformed paths or how endpoint-specific params are shaped, but nothing essential to invoking 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 100%, so path, params, and confirm are already documented in the schema; baseline is 3. The description only reinforces the 'scope/name' path format and the confirm-for-destructive rule, adding little beyond what structured fields already state.

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 qBittorrent endpoint directly as scope/name') and explicitly positions itself as the fallback: 'for anything the tools above do not cover.' An agent can distinguish it from the specific siblings like list_torrents or add_torrent without opening any 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?

The phrase 'for anything the tools above do not cover' clearly conditions when to reach for this generic tool instead of the purpose-built siblings, which is exactly the routing decision an agent faces. It stops short of naming a specific sibling or listing explicit exclusions, so it is clear context rather than a full when/when-not statement.

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 disclose the important behavior: this is an asynchronous start-and-poll operation rather than a single blocking lookup. It still omits failure behavior when plugins are missing, whether an unfinished search can be re-polled later, and any result persistence.

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 with no waste; the operation and its prerequisite are front-loaded and nothing is repeated from 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?

An output schema exists, so return values need no explanation, and the async polling behavior plus plugin prerequisite are covered. The description is adequate for a 5-parameter tool; only edge-case behavior (plugin absent, polling timeout with no settle) is left 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 coverage is 100%, so all five parameters are already documented in the schema and the baseline is 3. The phrase 'poll until it settles' hints at how wait_seconds bounds polling, but the description adds no format or selection guidance beyond the 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?

Specific verb+resource ('Run a plugin search') plus a clear lifecycle summary (start, poll, return results). It implicitly distinguishes itself from the torrent-listing siblings by saying 'plugin search', but never names an alternative tool, so an agent still has to infer that this is not a torrent lookup.

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?

States a precondition ('Requires qBittorrent to have search plugins installed'), which is genuinely useful context for deciding whether the call will work. However, it gives no when-to-use guidance relative to siblings such as qbt_call or list_torrents, and no when-not-to-use condition.

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 full burden, and it does not explicitly state that this is a side-effect-free read or that no authentication beyond the configured mode is needed. It does disclose the categories of information returned (version, auth mode, endpoint availability), which is behavioral value beyond the schema's empty property list, but permissions and safety profile remain unstated.

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 compact fragment with no filler, and the key content categories are front-loaded. It is appropriately sized for a trivial no-argument tool, though the telegraphic style stops just short of a fully self-contained statement.

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, the description need not enumerate return values, and with zero parameters there is no input surface to document. What remains missing is the safety/auth framing that would normally come from annotations, but for a low-risk read-only info call the current text is close to sufficient.

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 the baseline of 4 applies. Schema coverage is reported at 100% and there is nothing parameter-wise for the description to compensate for.

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 names the three things the tool reports (server version, auth mode, endpoint availability), which is enough for an agent to recognize it as a server-level diagnostics tool and to distinguish it from siblings like transfer_status and list_endpoints. It is a noun phrase rather than a verb+resource, but for a zero-parameter info tool that still communicates purpose effectively.

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 when-to-use or when-not-to-use guidance and no sibling is named as an alternative. The context is only implied by the tool's content, so an agent must infer on its own whether to reach for server_info versus transfer_status or list_endpoints.

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 well: it defines what availability means (reachable complete copies), the availability-vs-progress failure condition, why queued torrents are filtered out (reported 0 from disconnection), and what partial_selection indicates. It is a read-oriented diagnostic, so the lack of mutation/auth notes is minor.

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 dense sentences, front-loaded with the core question, followed by the definitions an agent needs to interpret availability and progress. No filler, though the partial_selection sentence is packed tightly.

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-format explanation is unnecessary, and the single parameter is fully documented in the schema. The description supplies the domain semantics (availability vs progress, exclusions) needed to read results, leaving little an agent would need to guess.

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 single parameter include_complete has 100% schema description coverage, so the baseline is 3. The description doesn't explicitly address the parameter, though its framing around 100%/partial_selection torrents implicitly relates to why complete torrents are normally hidden.

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?

Opens with a specific diagnostic goal — 'Judge whether each torrent can actually finish' — which is clearly distinct from listing tools like list_torrents or torrent_detail. It never names a sibling to route against, but the verb+resource (swarm completion feasibility per torrent) 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?

Usage is implied rather than stated: it explains that queued torrents are excluded and why, and that availability<=progress means it can never finish, which tells the agent when the tool is meaningful. However, there is no explicit 'use this rather than X' guidance against the many sibling torrent 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 mutation by listing create/delete/add/remove but never states that delete is destructive or irreversible, that 'confirm' is mandatory for deletion, or whether any permission is needed.

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, front-loaded with the resource and all supported actions, with zero filler. It is efficient, though the terseness borders on under-specification for a five-action tool.

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 four optional parameters, no annotations, and an output schema that covers return values, the description is minimally adequate. It omits the action-to-argument mapping and the destructive/confirm behavior, which a multi-action mutation tool should surface.

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 100%, so all four parameters are documented in the schema itself (names, action, hashes 'for add and remove', confirm 'required for delete'). The description contributes nothing about argument semantics, which is acceptable at baseline when the schema is complete but earns no credit.

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 names the resource (tags) and enumerates five operations, so the agent knows it is a tag-CRUD multiplexer. However, it is a bare verb list with no indication of what each action targets, and it does nothing to distinguish itself from the sibling 'categories' tool, which is a near-identical concept.

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 guidance on when to choose this tool over 'categories', nor on which arguments each action requires. The verb list mirrors the 'action' enum in the schema, so it adds no routing information.

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 of behavioral disclosure, and it says nothing about read-only safety, authentication needs, or whether the hash must reference an existing torrent. It discloses the returned data categories but no operational behavior.

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 compact sentence with no filler, front-loading the returned content. It is efficient, though the fragment style omits the action verb that would make it fully self-contained.

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, and the one parameter is fully documented in the schema. However, with zero annotation coverage the description should say more about the read-only nature and the requirement that the hash identify an existing torrent.

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 100% with a single 'hash' parameter documented in the schema, so the baseline is 3. The description adds no format, source, or validity detail beyond what the schema already provides.

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 names the resource (a torrent) and enumerates the specific data returned (properties, trackers, files), so an agent knows exactly what this tool produces. It lacks an explicit verb and does not name a sibling, but 'for one torrent' does distinguish it from list_torrents.

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: the singular 'one torrent' suggests this is the detail view versus the list view in list_torrents, but the description never states when to choose this tool or what precondition (a known hash) is required. No alternatives or exclusions are named.

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, yet it only lists the returned data categories. It never states that this is a read-only, side-effect-free call, nor mentions any auth or rate-limit considerations, leaving the agent to infer the 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.

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

A single front-loaded sentence fragment with zero filler. Everything present contributes to identifying the tool's data scope, and nothing is wasted.

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 no parameters and an output schema that already documents the return structure, the description only needs to identify the data scope, which it does. It could still note the read-only nature, but that gap is minor given the simplicity of the 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify about inputs beyond what the empty schema already conveys.

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 clearly enumerates what the tool surfaces: global transfer rates, limits, and connection status. It is a noun phrase rather than a verb+resource construction and offers no differentiation from potentially overlapping siblings like server_info or swarm_health, so it falls 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?

There is no indication of when to call this tool versus alternatives such as server_info, list_endpoints, or swarm_health, nor any prerequisites. The agent must infer usage from the generic name and the data categories alone.

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