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

The readOnlyHint annotation already covers non-destructiveness. The description adds value by enumerating exactly what data is returned (Qt, libtorrent, Boost, OpenSSL, bitness), which is useful context beyond the annotation. No side effects are mentioned, but none are expected given the read-only nature.

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 that delivers all essential information with no waste. It is ideal for a simple informational 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?

Given the tool's simplicity (no parameters, read-only, output schema present), the description fully covers what the tool does and what it returns. The output schema handles return value details, so no further explanation is required.

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 has zero parameters, and the baseline for no parameters is 4. The description correctly avoids inventing parameters, and the empty schema provides complete coverage. No additional semantics are needed.

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 states the tool returns build information including Qt, libtorrent, Boost, OpenSSL versions, and app bitness. This distinctively separates it from sibling tools like qbittorrent_app_version and qbittorrent_app_webapi_version, which focus on application and WebAPI versions.

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 implies usage when build info is needed, but does not explicitly mention alternatives or exclusions relative to similar version-related tools. It lacks clear when-to-use vs. alternatives guidance, though the purpose is unambiguous.

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?

The annotations already provide readOnlyHint=true, so the safety profile is covered. The description adds useful context beyond that: it specifies that this is the default path for new torrents (not existing ones) and provides an example path format (Windows absolute path). This is valuable behavioral context that the annotation does not convey.

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 concise phrase that communicates the tool's purpose with an example. There is no redundant wording or filler. For a tool this simple, the extreme brevity is appropriate and effective.

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?

Given the zero-parameter scope, the read-only annotation, and the presence of an output schema, the description is fully complete. It covers what the tool returns (the default save path) and the relevant nuance (for new torrents). No additional context is necessary for an agent to use this tool correctly.

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 has zero parameters and the schema is empty, so the baseline is 4. The description correctly adds no parameter information, and none is needed. The description implies this is a simple getter with no inputs, which aligns with 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?

The description clearly identifies the tool as exposing the default save path for new torrents, with a concrete example. This is a specific resource (app default save path) and is distinct from sibling tools like app_get_preferences, which are more general. The meaning is immediately clear despite lacking an explicit verb.

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 guidance on when to use this tool versus alternatives. The usage is implied by the tool's specific scope and name; the agent can infer that this is the appropriate tool for retrieving the default save path. However, no exclusions or alternative recommendations are provided.

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?

The description discloses the structure of each cookie entry (name/domain/path/value/expirationDate), adding useful context beyond the readOnlyHint annotation. However, it doesn't elaborate on other behavioral aspects like whether all cookies are returned or any authentication requirements. No contradiction with annotations.

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 sentence, front-loaded with the resource and context. It provides the key detail about the structure without any fluff or redundancy.

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 getter with no parameters and an output schema present, the description is adequately complete. It explains what the cookies are and gives the field names. It could explicitly state that it retrieves the cookies, but the tool name covers that.

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?

There are no parameters, and the schema is empty. Per the baseline for 0 params, the description doesn't need to add parameter information. The structure of the return value is partially described, while the output schema presumably covers the full format.

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 identifies the resource (cookies) and context (.torrent downloads), but it lacks an explicit verb like 'get' or 'retrieve'. The tool name provides the action, and it is implicitly distinguished from sibling set_cookies, but the description itself doesn't state this.

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 guidance is provided on when to use this tool or alternatives. It doesn't mention that this complements qbittorrent_app_set_cookies or that it should be used to inspect current cookies. The usage is only implied by the tool name.

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?

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds the return format and categories of preferences, but does not disclose any further behavioral nuances like authentication requirements or rate limits. This is adequate but not exceptional.

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, front-loads the core functionality, and uses parenthetical examples plus a README pointer without unnecessary verbosity.

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 getter with an output schema and readOnly annotation, the description is sufficient: it states scope, return format, and where to find the full field list. However, reliance on an external README means the description alone is not fully self-contained.

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 has zero parameters, so the baseline is 4. The schema coverage is 100%, and there are no parameters to document, so the description need not add parameter-level detail.

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 uses the specific verb 'get' with the resource 'application preferences' and clearly states the output is a key/value object. It is distinct from sibling tools like qbittorrent_app_set_preferences and qbittorrent_app_default_save_path.

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 usage is implied: use this tool when you need all application preferences. However, it does not explicitly discuss when not to use it or point to alternatives, such as the more specific qbittorrent_app_default_save_path.

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?

Annotations already mark this as a mutation (readOnlyHint=false), and the description adds that it replaces cookies for torrent downloads, which gives operational scope. It does not detail all side effects, but the simple nature of the operation and existing annotations make this adequate.

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 concise sentences: the first states the action and purpose, the second defines the parameter format. No redundant information, and the most important information is front-loaded.

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?

Given the tool has one parameter and an output schema, the description covers the purpose, scope, and parameter structure adequately. It lacks only minor details like whether replacement is wholesale or additive, but this does not significantly impair understanding.

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 schema has 0% description coverage and only specifies 'array of objects' with additionalProperties true. The description compensates fully by specifying the exact object structure: {name, domain, path, value, expirationDate}. This adds essential meaning 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?

The description uses a specific verb and resource: 'Replace the cookies used when downloading .torrent files.' This clearly distinguishes the tool from the sibling qbittorrent_app_get_cookies and other setter tools.

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 clear context (when downloading .torrent files) and implies the action (replacing cookies), though it does not explicitly name alternatives or exclusion criteria. This fits the 'clear context, no exclusions' level.

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?

Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds value by explaining the partial update behavior and providing value type constraints (strings quoted, integers/booleans not), which goes beyond the annotations.

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 sentences with a clear action verb, concise usage rule, and a helpful example. Every part earns its place with no redundancy or 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 tool is a simple preference update with an output schema present, so the description need not explain return values. It covers the key aspects: what it does, how to specify changes, and value type handling. Minor gaps like error handling are not critical for this straightforward operation.

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 has a single 'json' object parameter with 0% description coverage, so the description is the sole source of semantic meaning. It effectively explains the format (the 'json' argument) and provides a concrete example, plus rules for quoting strings versus integers/booleans, fully compensating for the schema's lack of detail.

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 states 'Update application preferences' with a specific verb and resource. It distinguishes from sibling qbittorrent_app_get_preferences by using 'Update' vs implied 'Get', but does not explicitly name the alternative.

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 instruction 'Pass only the keys you want to change' gives a clear usage guideline for partial updates, and the example demonstrates how to call it. However, it does not explicitly state when to use this tool versus get_preferences or other preference-related tools, leaving the comparison 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?

Annotations already indicate destructive behavior, but the description adds critical context: it stops the entire daemon/WebUI and cannot be undone from this tool. This goes beyond the structured hints, making the operational impact and irreversibility explicit, which is especially valuable for a destructive action.

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 sentences: the first clearly states the action and scope, the second adds a crucial warning and irreversibility note. Every word earns its place, and the key details are front-loaded.

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 no-parameter destructive action, the description is complete. It covers what is shut down, the breadth (daemon/WebUI), and the consequence (cannot be undone), which complements the annotations and output schema. No additional information is needed for an agent to decide when and how to invoke it.

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 has zero parameters and schema coverage is 100%, so there are no parameter semantics to explain. The description correctly omits parameter details, and the baseline for 0-parameter tools is 4, as no further clarification is needed.

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 uses a specific verb ('Shut down') and a clear resource ('qBittorrent application'), further clarifying it stops the whole daemon/WebUI. It distinguishes itself from sibling tools by emphasizing the full application scope versus operations on individual torrents or the session (e.g., logout).

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 some usage guidance ('use sparingly, it cannot be undone from here') but does not explicitly compare to alternatives or state when not to use it. The warning implies caution, but there is no clear 'when to use vs. alternatives' guidance, such as contrasting with logout or torrent-specific actions.

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?

The annotation readOnlyHint=true already covers the tool's safety profile. The description adds the example version format ('v5.0.4'), which is useful context, but it does not disclose additional behavioral traits like response structure or error conditions. This meets the baseline with a slight bonus for the example.

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 concise sentence that states the purpose and gives an example. It is front-loaded, contains no filler, and every word adds value. This is an ideal level of conciseness for a simple getter 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?

Given the tool's simplicity—zero parameters, a read-only annotation, and an output schema—the description is complete. It accurately describes the return value and even provides a concrete example. There are no missing pieces that would confuse an 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?

The tool has zero parameters, so there is no parameter semantics to explain. The schema is empty and fully covered, and the description correctly avoids adding unnecessary parameter details. The baseline of 4 applies for tools with no parameters.

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 identifies the tool's purpose: returning the qBittorrent application version. It includes an example format, and the tool name 'qbittorrent_app_version' is distinct from siblings like 'qbittorrent_app_webapi_version' and 'qbittorrent_app_build_info', so differentiation is clear.

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 intended use is implied: to retrieve the application version. However, it does not explicitly mention when to choose this over alternatives or provide any exclusion criteria. Since it's a simple getter, this is adequate but leaves room for more explicit guidance.

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?

The readOnlyHint annotation already signals a safe read operation. The description adds modest context by clarifying that the version is 'implemented by this qBittorrent' and giving an example output format. However, it does not disclose any additional behavioral traits like potential errors, response structure, or rate limits.

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 concise sentence that directly states what the tool returns and provides an example. No filler or redundant information is present.

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?

Given the tool's simplicity (no parameters, output schema exists, read-only annotation), the description is largely sufficient. However, the lack of differentiation from qbittorrent_app_version is a small gap, and the description could have mentioned when to prefer this endpoint.

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 has zero parameters, and the schema coverage is 100% (empty schema). Per the rubric, a baseline of 4 is appropriate when there are no parameters. The description does not need to add parameter details.

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 states that the tool returns the WebAPI version implemented by this qBittorrent, with an example value (2.14.1). It uses a specific resource (WebAPI version) and distinguishes itself from sibling tools like qbittorrent_app_version.

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 guidance is provided on when to use this tool versus alternatives such as qbittorrent_app_version. The description does not mention any exclusions, prerequisites, or typical use cases, leaving the agent to infer usage from the name and description alone.

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?

The annotation readOnlyHint=true establishes safety, and the description adds behavioral detail: logs are returned as an array, filters default to include all classes, and last_known_id enables incremental fetching. This goes beyond the annotation without contradicting it.

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 concise sentences front-load the primary purpose and then clarify filtering and incremental fetch options. No redundant wording or filler content; 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?

With an output schema present, the description appropriately avoids explaining return values in depth. It covers the main behaviors and parameters effectively. Minor gaps remain regarding ordering or limits of the log array, but these are not critical for invoking the tool correctly.

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?

Despite 0% schema description coverage, the description adds full semantics for all five parameters: info, normal, warning, critical as boolean filters (default true), and last_known_id as an integer for fetching newer messages. This completely compensates for the missing schema descriptions.

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 states the tool returns the application log as a JSON array with a specific structure ({id, message, timestamp, type}). The verb 'fetch' is implied, and the resource is unambiguously the main application log, distinguishing it from sibling qbittorrent_log_peers.

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 clear context for when to use the tool: fetching application log entries with optional filtering by message class and incremental retrieval via last_known_id. It does not explicitly mention alternatives or exclusions, but the context is sufficient to distinguish from the peer log tool.

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?

The description adds behavioral context beyond annotations by clarifying that invalidating the session is the effect and by disclosing that with API-key auth, the endpoint returns an error that is surfaced as-is. This enriches the annotation hints (readOnlyHint=false, destructiveHint=false) without contradicting them.

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 sentences long, with the first stating the core purpose and the second adding an important caveat. Every sentence is meaningful and there is no redundant or extraneous 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?

With zero parameters and an existing output schema, the description only needs to cover the action and any notable constraints. It fully describes the session invalidation and the API-key auth limitation, making it complete for this simple 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 has zero parameters, so the schema is fully self-descriptive. There is no need for the description to add parameter semantics, and the baseline for zero parameters is 4.

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 action: 'Invalidate the current WebUI session.' This is a clear verb+resource pair with no ambiguity. It also distinguishes itself from siblings by being the only logout 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?

The description implies when to use the tool (when you need to end the current WebUI session) and provides an explicit exclusion: it is not reachable with API-key auth. This is clear context, though it doesn't explicitly contrast with alternative tools (none are relevant).

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?

The annotation readOnlyHint=true already signals a safe read operation. The description adds behavioral context by specifying the JSON array format with fields and explaining the incremental fetch behavior of last_known_id. This goes beyond the annotation without contradicting it.

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 only two sentences. The first sentence defines the tool's purpose and output shape, and the second explains the parameter. Both sentences earn their place with no fluff or redundancy.

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 (one optional parameter), and the output schema exists, so the description need not detail return values. It covers the response structure (JSON array with fields) and parameter behavior, making it complete for an agent to select and invoke correctly.

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 schema has zero description coverage (0%) for the only parameter, so the description carries the full burden. It fully explains last_known_id's purpose and effect, which is essential for correct invocation. This is exactly what the parameter semantics dimension requires.

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 explicitly states 'Peer-block log entries as a JSON array of {id, ip, timestamp, blocked, reason}', clearly identifying the resource (peer-block log) and the action (retrieval). It distinguishes this from sibling tools like qbittorrent_log_main (general log) and qbittorrent_sync_torrent_peers (live peers) by focusing specifically on peer-block log entries.

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 clear context for when to use the tool: when peer-block log entries are needed. It also gives concrete usage guidance for the parameter with 'Pass last_known_id to fetch only entries newer than a given id.' However, it does not explicitly name alternatives or exclusions, 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?

Annotations already declare it as a write operation that is not destructive. The description adds that the feed is added by URL and optionally into a folder path, but it does not disclose behaviors such as duplicate handling, path creation, or validation errors. Some behavioral context is present, but it is minimal.

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 concise sentence that front-loads the action and packs all essential information without unnecessary words. It is highly efficient and easily scannable.

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 two-parameter operation, the description gives the core functionality. Missing is an explanation of whether the 'path' must already exist and what happens with invalid feeds. Given the output schema and simple nature, it is minimally complete but has clear 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?

The schema has no parameter descriptions (0% coverage). The description references both parameters ('by URL' and 'into a folder path'), providing basic semantic context. However, it does not specify path format, existence requirements, or edge cases, so it only partially compensates for the schema gap.

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 uses the specific verb 'Add' and identifies the resource 'RSS feed by URL', clearly distinguishing it from sibling tools like adding folders or removing items. It clearly states the action and the resource type.

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 'Add an RSS feed' explicitly states the context for using this tool. It does not discuss alternatives or exclusions, but the use case is unambiguous, so an agent can easily choose this tool when needing to subscribe to a feed.

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?

Annotations already indicate this is a write operation (readOnlyHint false) and not destructive (destructiveHint false). The description adds no substantive behavioral detail beyond these annotations—no mention of error handling, idempotency, duplicate folder behavior, or whether parent folders are auto-created. The example path only addresses parameter format, not tool 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?

The description is a single sentence with a helpful example. Every word earns its place, and the front-loaded verb 'Create' immediately communicates the action. No unnecessary detail.

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 straightforward write tool with one parameter and an existing output schema, the description plus annotations cover the basics needed to invoke it. However, it lacks edge-case details like behavior on duplicate paths or whether the path is relative to a root, but the simplicity of the tool makes this 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?

Although the input schema provides zero description of the 'path' parameter (0% coverage), the description compensates with a concrete example ('The Pirate Bay\Top100') that illustrates the expected hierarchical path format. This gives an agent the key semantic insight that nested folder paths are supported, which the bare schema does not.

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 uses a specific verb ('Create') and resource ('RSS folder'), clearly distinguishing it from sibling tools like qbittorrent_rss_add_feed (which creates feeds) and qbittorrent_rss_remove_item (which removes items). The example path 'The Pirate Bay\Top100' further clarifies the hierarchical nature.

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 implies usage when an RSS folder needs to be created, but it doesn't explicitly state when to use this tool versus alternatives like qbittorrent_rss_add_feed or qbittorrent_rss_move_item. No exclusions or prerequisites are mentioned, though the simple action makes the context reasonably 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?

The readOnlyHint annotation already marks this as safe; the description adds the return structure (nested folder -> feed -> URL) and the option to include articles with with_data. It does not disclose potential performance implications or default behavior, but for a simple read operation this is adequate.

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 concise sentences: the first states the purpose and output structure, the second explains the parameter. No redundant content, and the key information is front-loaded.

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, has an output schema, and the readOnlyHint annotation covers safety. The description covers the main purpose, the parameter effect, and the structure. It could add a sentence about when to use versus other RSS tools, but overall 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 schema provides no description for with_data (only type and default null), so the description's statement that setting it includes current feed articles adds value. However, it doesn't clarify the effect of null versus false or the exact shape of the article data.

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 the tool returns all RSS items as a nested object of folder -> feed -> URL, clearly indicating a read operation. It distinguishes from siblings like qbittorrent_rss_rules or add_feed by focusing on the item tree, though it lacks an explicit verb like 'get'.

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 implies use for retrieving the RSS item hierarchy and explains the with_data parameter behavior. It does not explicitly compare with sibling tools or state exclusions, making the usage guidance somewhat implied rather than explicit.

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?

Annotations indicate readOnly=false and destructive=false, which is consistent with the description. The description adds the scope of the operation (feed or single article) but does not disclose other behavioral traits like reversibility or side effects.

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 sentence that is front-loaded and concise, with no redundant information. Every word adds value.

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 mutation tool, the description covers the core action and the optional scoping via article_id. An output schema exists, so return values need not be described. It lacks only minor context like prerequisites or error conditions.

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 explains article_id's purpose but does not explicitly define item_path as the feed path, though it is implied by 'Mark an RSS feed as read'. The parameter meanings are partially clarified.

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 states the verb 'Mark' and the resource 'an RSS feed', and distinguishes from siblings by noting the optional article_id for marking only one article. It is specific and 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 implies usage via the optional article_id parameter, but does not explicitly state when to choose this tool over alternatives like remove_item or move_item. It provides no exclusionary guidance.

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?

The readOnlyHint annotation already signals safe read behavior. The description adds the return format ({feed name: [article titles]}) which is useful, but it does not disclose edge cases such as behavior for nonexistent rule names or empty results. This matches the baseline for annotated read operations.

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 that states the purpose and output format. Every word contributes value with no filler or repetition of schema or annotation details.

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 single-parameter read-only tool with an output schema, the description provides the essential behavior and return structure. It is sufficient for an agent to infer the tool's role, though it lacks explicit mention of edge cases or parameter constraints.

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 input schema has 0% description coverage for the only parameter, rule_name. The description only references 'a rule' without clarifying the exact semantics (e.g., whether it must match an existing rule name, case sensitivity, or how rule names are defined). It does not compensate for the missing schema documentation.

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 states the tool returns all feed articles matching a rule, with a specific output format of {feed name: [article titles]}. This distinguishes it from sibling tools like qbittorrent_rss_items by scoping to rule matching and specifying the result structure.

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 purpose implies when to use this tool (to see articles matched by a rule), but it does not explicitly mention alternatives or exclusions. No guidance is given comparing it to rss_items or other RSS tools, so usage context 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, covering the mutation and non-destructive nature. The description adds the operation details but doesn't disclose potential side effects (e.g., whether renaming affects feeds or rules). With annotations present, a 3 is appropriate.

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 sentence, front-loaded with the verb, and contains zero wasted words. It clearly defines the action and parameters in an efficient manner.

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 move/rename operation with two string parameters, the description is largely complete. It could benefit from a note about path format (e.g., use forward slashes) but given the output schema exists and the operation is straightforward, it is adequate.

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 has 0% description coverage, and the description fully compensates by explaining item_path as the source and dest_path as the destination, using the 'from...to...' phrasing. This is critical for the agent to understand the parameter roles.

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 states the action (move or rename), the resource (RSS folder/feed), and the source/destination parameters. It distinguishes itself from sibling tools like add/remove/refresh by specifying the move/rename operation.

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 implies when to use this tool (to move or rename an RSS folder/feed) and provides clear context through the operation. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent would know when to select it.

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?

Annotations already indicate the operation is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the 'force' aspect, which implies bypassing normal refresh conditions, providing a bit of behavioral context. However, side effects, permissions, or rate limits are not disclosed, so credit is limited.

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, tightly written sentence ('Force-refresh an RSS folder or feed.') that is front-loaded with the action verb and resource. It contains no filler or redundant information, making it highly efficient.

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 tool with an output schema, the description sufficiently captures the essential purpose. It may not cover edge cases like error conditions or exact path format, but the provided annotations and output schema fill in some gaps. Overall, the description is adequate for selecting and invoking the tool correctly.

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 schema has one required parameter 'item_path' with no description (0% coverage). The description compensates by indicating that item_path identifies a folder or feed, giving semantic meaning to the parameter. While it doesn't detail formats or examples, it directly maps the parameter to the tool's domain.

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 states the action ('Force-refresh') and the resource ('an RSS folder or feed'). This distinguishes it from sibling tools like qbittorrent_rss_remove_item, qbittorrent_rss_move_item, and qbittorrent_rss_mark_as_read, which have different verbs and purposes.

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 implies the tool is used to refresh RSS folders or feeds but does not explicitly mention when to use it versus alternatives, nor does it provide exclusions or prerequisites. The clear purpose gives context, but alternatives are not addressed.

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?

The annotations already declare destructiveHint=true, so the description does not need to add basic safety information. It adds the useful detail that both folders and feeds are removable, plus an example path, but it does not disclose what happens to the contents of a removed folder (e.g., whether all child feeds are deleted). This is beyond the annotation yet still limited, so a 3 is appropriate.

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 sentence with no wasted words, front-loading the verb 'Remove' and the object. The example is concise and adds value by illustrating the required path format.

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?

Given the tool's simplicity (one required parameter, no nested objects), the description is complete. The destructive nature is already annotated, and the output schema is present so the return value does not need explanation. The example makes the parameter format clear, covering all essential operational context.

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 input schema has one parameter 'path' with no description, so schema description coverage is 0%. The description fully compensates by explaining that path refers to 'an RSS folder or feed' and provides a concrete example ("The Pirate Bay\Top100"), giving significant semantic meaning beyond the raw 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 uses a specific verb ('Remove') and clearly identifies the resource as 'an RSS folder or feed', which directly distinguishes it from sibling tools like qbittorrent_rss_add_folder, qbittorrent_rss_move_item, and qbittorrent_rss_refresh_item. The example 'The Pirate Bay\Top100' further clarifies the intended scope.

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 does not explicitly state when to use this tool vs alternatives, nor does it mention exclusions or alternatives. However, the purpose is clear enough that the agent can infer it is for deletion, distinct from other RSS operations. Usage is implied rather than stated, so it falls at 'implied usage'.

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?

Annotations already indicate destructiveHint=true, so the destructive nature is known. The description adds no extra behavioral context beyond what annotations provide, such as irreversibility or effects on active downloads, but it is consistent with the annotations.

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 that is front-loaded and free of unnecessary words. It efficiently conveys the core action without repetition or 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 tool is simple and the description plus annotations cover the basic action, but it lacks details about failure behavior, whether deletion is permanent, and guidance on alternatives. These gaps, though not critical for such a straightforward operation, prevent a higher completeness score.

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 schema's single parameter, rule_name, has no description coverage, and the tool description does not elaborate on it. While the name and tool purpose make it inferable that rule_name identifies the rule, no explicit format or identifier semantics (name vs ID) are given.

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 uses a specific verb 'Remove' and identifies the resource as 'auto-downloading rule', clearly distinguishing it from related RSS tools like qbittorrent_rss_set_rule or qbittorrent_rss_rename_rule. It unambiguously states the operation.

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 guidance is provided on when to use this tool versus alternatives. It does not mention that rules are created or modified via qbittorrent_rss_set_rule, nor does it explain any prerequisites like the rule existing before removal.

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?

The annotations (readOnlyHint=false) indicate a mutation, but the description adds no behavioral context beyond the basic rename operation. It does not disclose potential side effects (e.g., impact on active auto-downloading), error conditions, or permission 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?

The description is a single, six-word sentence that is maximally concise and immediately front-loaded with the action. Every word 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 simple two-parameter rename tool with an output schema, the description is minimally adequate. However, it lacks important context such as what happens if the original rule doesn't exist, whether the rename is reversible, or any constraints on the new name.

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 schema has no descriptions (0% coverage), and the tool description does not explain the parameters beyond their self-evident names (rule_name, new_rule_name). No details about uniqueness, case sensitivity, or formatting are provided.

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 states the action ('Rename') and the resource ('auto-downloading rule'), making it specific and distinguishable from sibling tools like qbittorrent_rss_set_rule and qbittorrent_rss_remove_rule.

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 usage is implied by the purpose statement, but there is no explicit guidance on when to use this tool versus alternatives (e.g., set_rule for modifying other rule properties, remove_rule for deletion). No exclusions or prerequisites are mentioned.

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?

The readOnlyHint annotation already indicates safety, and the description adds the return structure as a map of name to rule definition. However, it does not explicitly describe behavior like retrieval semantics or response format beyond the annotation and output 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?

The description is very concise, consisting of a single sentence fragment. It is front-loaded and contains no redundant information, though it could be a bit more explicit with a verb.

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?

Given the tool's simplicity, zero parameters, and existing output schema, the description is mostly complete. It conveys the core purpose and output structure, but a more explicit action word would make it fully self-contained.

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 has no parameters, so the description does not need to elaborate. The baseline for zero-parameter tools is 4, and the description is adequate.

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 identifies the resource (auto-downloading rules) and implies a retrieval operation, distinguishing it from sibling tools like qbittorrent_rss_set_rule or qbittorrent_rss_remove_rule. However, it lacks an explicit verb (e.g., 'get' or 'list'), making it slightly less direct.

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 guidance is provided on when to use this tool versus alternatives. It does not mention that it is read-only or suggest using it for inspecting rules, nor does it differentiate it from related RSS 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?

Annotations already indicate this is a mutating operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it is auto-downloading and lists rule_def keys, but does not disclose deeper behavioral details like what happens on replace or potential side effects beyond the annotations.

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 compact and starts with the primary purpose, followed by a key list and a concrete example. The structure is efficient, though the key list could be broken out for readability, it earns a high score for not over-explaining.

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?

Given the tool has an output schema (not shown) and annotations, the description does not need to explain return values. It covers the core purpose, input keys, and an example, but lacks detailed parameter semantics and usage alternatives, making it only moderately complete for a complex rule-definition 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 input schema provides no descriptions (0% coverage), so the description carries the burden. It lists all rule_def keys and provides an example showing types, which adds meaning beyond the bare schema. However, it does not explain the semantics of each key (e.g., smartFilter, ignoreDays), leaving ambiguity for less obvious parameters.

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 states the tool creates or replaces an auto-downloading RSS rule, using a specific verb and resource. This distinguishes it from siblings like qbittorrent_rss_rename_rule and qbittorrent_rss_remove_rule.

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 clearly indicates this tool is for creating or replacing rules, providing context for when to use it. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough to guide selection among related RSS rule 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?

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the side effect 'free its results', which clarifies the broader impact beyond just deleting the job. No contradictions with annotations are present.

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, compact sentence that directly states the action and its effect. It contains no filler or redundant information, ideal for quick agent comprehension.

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 one-parameter destructive operation with an output schema present, the description sufficiently covers the primary action and a key side effect. It does not address error conditions or idempotency, but these are not critical for the tool's basic use.

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 schema has 0% description coverage for the single integer 'id'. The description does not explicitly state that 'id' identifies the search job, though the tool name and sentence context make it inferable. This is partial compensation but not fully explicit.

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 uses a specific verb ('Delete') and identifies a clear resource ('a search job') with an explicit consequence ('free its results'). This clearly distinguishes it from sibling tools like 'stop' which likely halts but doesn't delete.

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 implies when to use the tool (when you want to delete a search job and free results), but it does not explicitly mention alternatives or when NOT to use it. It offers no direct comparison to related operations like 'search_stop' or 'search_results', so guidance is only implicit.

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?

Annotations already indicate this is a write operation (readOnlyHint=false) but not destructive (destructiveHint=false). The description adds no additional behavioral context, such as reversibility, effects on running searches, or permission requirements. It merely restates the basic action.

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 sentences, front-loaded with the main action, and contains no superfluous information. Every word is relevant and useful.

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 two-parameter tool, the description is adequate but lacks broader context. It does not mention prerequisites like requiring the plugin to be installed, or effects on other operations. The output schema covers return values, so the absence of output explanation is acceptable.

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 carries the burden. It clarifies that 'names' is one or more plugin names separated by a pipe, which is valuable. The 'enable' boolean is self-explanatory given the tool's purpose, so the description compensates well for the missing schema info.

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 uses a specific verb and resource: 'Enable or disable search plugins.' This clearly differentiates it from sibling tools like install/uninstall/update/list plugins, which have different actions. The second sentence adds key detail about the 'names' parameter.

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 guidance is provided on when to use this tool versus alternatives, nor are there prerequisites or exclusions mentioned. The usage is implied only by the verb, but the description doesn't explicitly state when enabling/disabling is appropriate or needed.

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?

Annotations already declare readOnly=false and destructive=false, so the agent knows this is a write operation. The description adds the pipe-separated multi-source format but does not disclose side effects such as whether existing plugins are overwritten or if the plugin list needs refreshing. With annotations covering the basic safety profile, this is adequate but not rich.

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 sentences: the first states the action, the second explains the parameter. It is front-loaded with the purpose and contains no redundant or filler words.

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?

This is a simple single-parameter install tool with output schema available, so the return value is presumably covered elsewhere. The description sufficiently covers the only parameter and the action. Minor missing details like overwrite behavior are non-essential for basic invocation.

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 input schema only specifies 'sources' as a string with no description. The description compensates by explaining that sources are 'one or more URLs or file paths separated by a pipe', providing essential format and multiplicity details. This adds significant meaning 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 uses a specific verb 'Install' with a clear resource 'search plugins', which unambiguously identifies the tool's function. It also distinguishes from sibling tools like uninstall, enable, and update through the action 'Install'.

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 implies when to use it (to add search plugins) but does not explicitly contrast with alternatives such as update_plugins or enable_plugin. No prerequisites, scenarios, or exclusions are mentioned, making the guidance implicit rather than explicit.

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?

The readOnlyHint annotation already signals a safe read operation. The description adds the specific fields returned, but does not disclose additional behavioral details such as response structure, ordering, or potential errors. It provides some value beyond the annotation but not extensive 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?

The description is a single, compact line that front-loads the resource name. It is efficiently short, though it is a fragment rather than a complete sentence, which slightly reduces clarity.

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?

Given the simplicity (0 params), the readOnlyHint annotation, and the presence of an output schema, the description is adequately complete for an AI agent to understand the tool's basic function. It could benefit from an explicit action word, but it does not leave major 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?

The input schema has zero parameters, so the baseline is 4. The description correctly lists return fields but adds no parameter semantics since there are no parameters to describe.

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 identifies the resource (installed search plugins) and lists their fields, but lacks an explicit verb like 'list' or 'get'. It is clear enough to infer a read operation, but does not articulate the action as specifically as examples with verbs.

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 guidance is provided about when to use this tool versus the many sibling search tools (e.g., install/uninstall/enable/update plugins). The intended use is implied by the name, but the description does not state context, alternatives, or exclusions.

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?

The readOnlyHint annotation already signals a safe read; the description adds pagination semantics (limit and offset behavior), which is useful. However, it does not disclose whether the search must be complete, what an invalid id produces, or how to interpret the returned status field. No contradiction with annotations.

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, no fluff; the first sentence defines the return shape, the second explains pagination. Every word 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?

The description covers the result shape and pagination, but it omits the essential prerequisite that id must be a valid search job id (created by qbittorrent_search_start) and does not explain the meaning of the returned status field. Given an output schema exists, return values are partially covered, but the missing context prevents full standalone comprehension.

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 schema provides no descriptions (0% coverage), so the description carries the burden. It explains limit (0/negative means no cap) and offset (negative counts from end), but the required id parameter is left undefined—presumably the search job id, but not stated. This partial coverage is helpful but incomplete.

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 identifies the tool as returning results of a search job and lists the exact fields in the result object. This distinguishes it from siblings like qbittorrent_search_status and qbittorrent_search_delete, but it lacks an explicit action verb like 'retrieve' or '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?

No guidance is given about when to call this tool versus qbittorrent_search_status or qbittorrent_search_start; there is no mention of prerequisites (e.g., starting a search first) or when to use alternatives. The only operational notes are about pagination parameters, not about tool selection.

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?

Annotations indicate the operation is not read-only and not destructive. The description adds that it starts a job and returns an id, but doesn't disclose additional behavioral traits like asynchronous execution, potential resource usage, or how to cancel via qbittorrent_search_stop. Given annotations already cover the safety profile, the description adds modest value.

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 sentences, quickly states purpose and then parameter meaning. It is efficient and front-loaded, with no redundant 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?

The tool has an output schema (so return value guidance isn't needed), and annotations cover safety. However, the description omits any explanation of the required 'pattern' parameter and doesn't mention the relationship to other search tools (e.g., that a started job can be queried with qbittorrent_search_status or results). For a 3-parameter tool with zero schema coverage, this leaves a 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?

Schema coverage is 0%. The description explains the 'plugins' parameter (pipe-separated names or 'all'/'enabled') and 'category' (limits search depending on plugin), but does not explain the required 'pattern' parameter, which is left ambiguous. This partially compensates for the schema's lack of descriptions.

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 identifies the tool's action ('Start a search job'), the resource (a search job), and the return value (its id). This distinguishes it from sibling tools like qbittorrent_search_stop, qbittorrent_search_status, and qbittorrent_search_results.

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 clear context on how to specify plugins and category, but doesn't explicitly mention alternatives or when-not-to-use. It gives enough clarity that an agent would know this is the starting point for a search, though it lacks explicit workflow guidance such as using search_results to retrieve results.

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?

The readOnlyHint annotation already indicates a safe read, and the description adds the behavior of querying one or all jobs and the returned status values (Running/Stopped, total). No contradiction with annotations.

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 that includes the key output structure. Every part adds value and there is no redundancy or 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?

For a simple read-only status tool with annotations, an output schema, and a single well-explained parameter, the description is complete. It provides enough information to select and invoke the tool correctly.

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 carries the full burden. It clearly explains the id parameter: a specific id targets one job, while null/omitted means all jobs. This fully compensates for the lack of schema descriptions.

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 states the tool provides status for one search job by id or all jobs, and includes the output shape. This distinguishes it from sibling search tools like start, stop, results, and delete.

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 clear context for use: pass an id for a single job or omit for all jobs. It does not explicitly name alternatives or when-not-to-use, but the scope is evident and consistent with sibling tool names.

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?

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds minimal context (the action is 'stop' on a 'running' job). No details about side effects, idempotency, or failure behavior are given, but the annotation coverage is sufficient for a basic state-change operation.

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 of eight words. It conveys the action, resource, and parameter without any wasted words.

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?

Given the tool's simplicity (one required parameter, no nested objects, output schema present), the description is nearly complete. It lacks explicit error semantics or what happens to the job's results after stopping, but this is a minor gap for a straightforward stop operation.

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 description adds 'by id' which clarifies the parameter is the search job's id, but the schema already defines an integer 'id'. With 0% schema description coverage, more detail would be helpful, but the single parameter is self-explanatory, so this is baseline-adequate.

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 states the specific action (stop) and resource (a running search job) with a unique identifier. It distinguishes from sibling tools like qbittorrent_search_start, qbittorrent_search_status, and qbittorrent_search_delete.

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 implies usage for active search jobs by saying 'running', but it does not explicitly mention when not to use it or alternatives like qbittorrent_search_delete for cleanup. No exclusions or pointers to sibling tools are provided.

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?

The description says 'Uninstall', which is a destructive/mutating action, but annotations declare destructiveHint=false. This is an annotation contradiction. The description also fails to disclose any consequences (e.g., permanent removal, effect on searches) beyond the contradiction.

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 that convey the action and parameter format without any wasted words. All information is necessary for basic use.

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 with one parameter and an output schema, but the description omits potential edge cases (e.g., nonexistent names, partial failures) and is undermined by the annotation contradiction. It is sufficient for the simplest invocation but not fully complete for an agent encountering errors or needing side-effect awareness.

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 input schema only defines 'names' as a string with no format. The description adds critical meaning by specifying that names are pipe-separated, which is essential for correct invocation. This compensates for the schema's 0% 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?

The description uses a specific verb 'Uninstall' with the resource 'search plugins', making the action unambiguous. It distinguishes from sibling tools like install_plugin, enable_plugin, and update_plugins by focusing on removal.

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 context is implied by the tool name and sibling operations, but the description offers no explicit guidance on when to uninstall versus disable or update plugins. It lacks any exclusions or references to alternatives.

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?

Annotations already convey that this is neither read-only nor destructive. The description adds minimal context about the update behavior (e.g., 'latest versions' implies network interaction), but does not elaborate on potential side effects or prerequisites. This is acceptable for a simple operation, but not rich beyond the annotations.

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 sentence that is entirely on-topic, front-loaded with the verb, and contains no redundant information. Every word 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 a clear action, the description is fully self-contained. The output schema can handle return values, so no further context is required. The tool's simplicity means there is no missing information.

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 the baseline of 4 applies. The description correctly implies that no user input is needed, and there are no parameter details to provide.

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 states the action ('update') and the resource ('all installed search plugins'), with a specific scope. It is easily distinguished from sibling tools like install, uninstall, and enable plugin.

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 tool's use case is clear from the description: to update all search plugins. While it doesn't explicitly mention alternatives, the sibling tool names make it obvious that install/uninstall/enable serve different purposes, so no exclusion is needed.

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?

Beyond the readOnlyHint annotation, the description discloses key behavioral details: differential updates via rid, the meaning of full_update=true, and the included data categories. This adds meaningful context without contradicting the annotation.

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 followed by usage essentials. Every word earns its place; there is no redundancy or 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?

Given the simple one-parameter schema, readOnly annotation, and presence of an output schema, the description sufficiently explains differential syncing, the rid round-trip, and response content. It fully equips an agent to call and interpret this tool correctly.

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 schema provides only a bare 'rid' integer with a default of 0 and no description. The description compensates by explaining that rid comes from the previous reply and that passing it yields only changes, which is essential and not inferable from the schema alone.

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 identifies the tool as a 'Differential state snapshot for UI sync' and specifies it includes 'torrents, categories, tags and server_state.' While it lacks an explicit action verb like 'get' or 'list', the resource and scope are clear and differentiate it from sibling sync tools like qbittorrent_sync_torrent_peers.

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 explains how to use the rid parameter and what full_update=true signifies, giving clear context for incremental use. It does not explicitly name alternatives or when not to use this tool, but the UI sync context and differential state behavior imply the appropriate usage scenario.

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?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds valuable behavioral context about differential updates controlled by rid, which is not captured elsewhere and helps the agent understand the polling pattern.

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 exceptionally concise: two short sentences with the primary purpose front-loaded and no filler. Every word earns its place, making it highly efficient for an agent to parse.

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 has an output schema, so return-value details are covered. However, the description does not clarify the default behavior when rid is omitted (default 0) or contrast it with qbittorrent_sync_maindata, leaving some contextual gaps that could affect correct invocation.

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 description explains the rid parameter's role in retrieving changes since the previous reply, but the required hash parameter is only implied as the torrent identifier. With 0% schema description coverage, the description should compensate more for both parameters; it covers rid but leaves hash implicit.

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 identifies the tool as providing differential peer data for a single torrent, which distinguishes it from other sync tools. However, it lacks an explicit verb like 'get' or 'fetch', making the action less direct than optimal.

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 implies that the tool is used for incremental updates by passing the rid from the previous reply, but it does not explicitly state when to use it over alternatives like qbittorrent_sync_maindata or provide any exclusion criteria.

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?

The annotations already declare readOnlyHint=true, so no additional read-only disclosure is needed. The description adds value by specifying output fields and the filtering behavior, but it does not discuss edge cases like empty results or error conditions. Given the annotation coverage, a score of 3 is appropriate.

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 compact sentences: the first lists the output fields and the second explains the optional filter. Every word earns its place, with no fluff or redundancy.

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 description covers the resource, all returned fields, the meaning of priority values, and the optional filtering behavior. An output schema exists, so detailed return-value documentation is not required. This is complete for a simple read-only 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%, but the description compensates partially by explaining the 'indexes' parameter (pipe-separated, fetch only those files) and decoding priority values. The 'hash' parameter is left implicit as the torrent identifier, which is understandable but not explicitly documented.

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 identifies the resource ('Files of one torrent') and enumerates the returned fields, making its purpose evident. It lacks an explicit verb like 'list' or 'get', but the meaning is unambiguous and distinguishable from sibling tools like torrent_properties or piece_states.

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 clearly sets the context: this is for fetching files belonging to a single torrent, with optional filtering via pipe-separated indexes. It does not explicitly mention alternatives or exclusions, but the usage scenario is straightforward and effectively communicated.

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?

The readOnlyHint annotation already signals a safe read operation. The description adds that hashes are SHA1, cover all pieces, and are ordered, which is useful context. However, it does not disclose error conditions, authentication needs, or any other behavioral traits, leaving the annotation to carry the safety burden.

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 concise sentence with no filler. It is front-loaded with the essential information (SHA1 hashes, all pieces, one torrent, in order) and every word contributes meaning.

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?

Given the simple read-only nature and existing output schema, the description is mostly adequate. However, it fails to specify the meaning of the 'hash' parameter and provides no context about behavior for invalid hashes or non-existent torrents, leaving some ambiguity.

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 'hash' has 0% schema description coverage, and the tool description does not explicitly state that it is the torrent hash. The phrase 'one torrent' implies it, but the description does not clarify the parameter's role, format, or that it must be the info hash of the torrent.

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 'SHA1 hashes of all pieces of one torrent, in order' clearly identifies the output resource and differentiates it from sibling tools like qbittorrent_torrent_piece_states by specifying 'hashes' rather than 'states'. However, it lacks an explicit verb such as 'retrieve' or 'list', so it reads as a noun phrase rather than a complete command.

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 guidance is provided about when to use this tool versus alternatives such as qbittorrent_torrent_piece_states or other torrent-related operations. The description solely states what it returns, with no mention of use cases, prerequisites, or exclusions.

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?

The readOnlyHint annotation already communicates that the tool is safe and read-only. The description adds value by explaining the integer encoding for piece states, but it does not disclose any additional behavioral traits such as the order of pieces, handling of invalid hashes, or return format details.

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 one concise sentence that front-loads the core purpose and includes the essential state mappings without any filler. It is perfectly sized for the simplicity of the 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?

For a simple read-only tool with an output schema, the description provides the key interpretation of the integer values, which is likely not covered by the schema. It is sufficient for the agent to understand what the tool returns, though it lacks minor context about ordering or error behavior.

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 for the lack of parameter documentation. It only implicitly references the 'hash' parameter by saying 'one torrent', but does not explicitly explain what the hash is, its format, or that it is required, leaving interpretation to the parameter name.

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 states that the tool returns piece states for one torrent, with an explicit mapping for integer values (0 not downloaded, 1 downloading, 2 downloaded). This distinguishes it from sibling tools like qbittorrent_torrent_piece_hashes, which would return hashes rather than states.

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 does not provide guidance on when to use this tool versus alternatives, nor does it mention any exclusions or specific contexts. It relies entirely on the tool name and description to hint at its use, leaving the agent to infer when it is appropriate.

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?

readOnlyHint already marks this safe, and the description adds the useful 404-if-hash-not-found behavior and a concrete list of returned properties. No annotations are contradicted.

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 sentences: the first states the purpose and enumerates example fields, the second states the error condition. It is front-loaded and contains 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?

For a simple one-parameter read-only lookup with an output schema, the description covers purpose, returned fields, and error behavior. It lacks usage context and parameter source guidance, but the 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?

The input schema only defines a required string 'hash' with no description. The tool description mentions 'the hash' only in the 404 clause, adding no explanation of valid values, format, or how to obtain the hash from sibling tools.

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 identifies the tool as returning generic properties of a single torrent and lists representative fields. It stops short of explicitly differentiating from sibling torrent_* tools, though 'one torrent' provides some scope.

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: use this when you need top-level metadata for one torrent. There is no explicit guidance about when to prefer qbittorrent_torrents_list or qbittorrent_torrent_contents, nor any exclusions.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a write operation without destructive side effects. The description adds useful input details (e.g., URL formats, base64 encoding) but does not disclose behavioral traits such as whether added torrents start downloading immediately, or any side effects. This is adequate but not rich, hence a mid-range score.

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 succinct and front-loaded with 'Add torrents'. It efficiently explains the two primary input methods and then lists optional parameters without redundant schema information. Every sentence contributes to understanding how to invoke the tool, with 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?

With 16 optional parameters and no schema descriptions, the description carries a heavy burden. It covers the core inputs and some parameter units, but lacks explanations for several potentially ambiguous options like root_folder, auto_tmm, and skip_checking. Since an output schema exists, return values are not needed, but the incomplete parameter semantics leave contextual 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 0%, so the description must compensate. It names all 16 parameters and provides meaningful details for urls (formats, newline-separated), torrent_b64 (base64), tags (comma-separated), up_limit/dl_limit (bytes/s), ratio_limit, and seeding_time_limit (minutes). However, it only lists many other parameters without explaining their semantics (e.g., root_folder, auto_tmm, skip_checking), leaving ambiguity. This is a partial compensation.

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 starts with 'Add torrents', which is a specific verb+resource pair. It clearly distinguishes this from sibling tools like qbittorrent_torrents_list, qbittorrent_torrents_pause, and qbittorrent_torrents_add_trackers, as it is the only tool focused on adding new torrents. The mention of URLs and .torrent files further clarifies its specific function.

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 clear context on how to use the tool by explaining the two main input methods (urls or torrent_b64) and the optional settings. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions, though the naming and description make the distinction from siblings straightforward.

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?

Annotations indicate readOnlyHint=false and destructiveHint=false, so the description's 'Add' is consistent (a non-destructive mutation). The description adds context about special values like 'all' for hashes, but does not disclose other behavioral aspects such as idempotency or error handling. No contradiction with annotations.

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 sentences, front-loaded with the main action, and contains no redundant information. It efficiently conveys all necessary parameter semantics.

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 two-parameter tool with an output schema, the description is nearly complete. It covers the purpose and parameter formats, but omits details about possible errors, idempotency, or the nature of the response. However, the output schema may cover return values, and the simplicity of the tool reduces the need for more.

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 schema provides no parameter descriptions (coverage 0%), so the description is the only source of meaning. It clearly explains that 'hashes' is pipe-separated or 'all' and that 'peers' is a pipe-separated list of host:port values, which is essential for correct usage.

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 states the action ('Add peers') and the target resource ('torrents'), using a specific verb. It distinguishes itself from sibling tools like qbittorrent_transfer_ban_peers, which serves a different purpose.

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 implies usage by explaining what the tool does and the parameter formats, but it provides no explicit guidance on when to use this tool over alternatives nor any exclusions. For example, it doesn't mention that this is appropriate over transfer_ban_peers for adding rather than banning peers.

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?

Annotations already indicate this is not read-only and not destructive. The description adds useful behavioral details such as comma-separated tags and pipe-separated hashes or 'all', but doesn't disclose edge-case behavior like duplicate tags or invalid hashes. This is adequate but not rich.

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, efficient sentence that front-loads the operation and immediately provides format constraints. Zero wasteful words.

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 two-parameter mutation, the description gives enough detail to invoke the tool correctly (parameter formats and special 'all' value). The presence of an output schema covers return-value documentation, so no further explanation is needed. Minor gap: no error-case or precondition information.

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 fully compensates by explaining both parameters: 'tags' as comma-separated and 'hashes' as pipe-separated or 'all'. This adds essential meaning beyond the bare schema types.

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 states the action: 'Add tags' to 'torrents', with specific resource and scope. It distinguishes itself from sibling tools like qbittorrent_torrents_remove_tags and qbittorrent_torrents_create_tags by explicitly targeting existing 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?

The description provides clear context for when to use the tool (adding tags to torrents) and specifies input formats. It doesn't explicitly mention alternatives or when not to use it, but the context is unambiguous given the verb and resource.

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?

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds little beyond the operation itself. It mentions the URL format (newline-separated), but does not disclose whether existing trackers are preserved, duplicates are handled, or what side effects occur.

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 concise sentences with no filler. The purpose is front-loaded, and the additional sentence about URL formatting is necessary and immediately useful.

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 with two parameters and an output schema exists, so return details are not needed. The description covers the core usage and the critical URL parameter format, but could note that the operation appends to existing trackers for full clarity.

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 description explicitly defines the 'urls' parameter format ('separated by newlines'), which is critical since the schema has no descriptions. The 'hash' parameter is not explained but is self-evident from the context of adding trackers to a torrent.

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 exactly what the tool does: 'Add trackers to a torrent.' This is a specific verb and resource, and it clearly distinguishes from sibling tools like 'edit_tracker' and 'remove_trackers' by the verb '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?

No guidance is provided on when to use this tool vs alternatives (e.g., edit_tracker or remove_trackers). It doesn't mention prerequisites, such as the torrent existing or that this appends to existing trackers rather than replacing them.

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?

The annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is known to be non-read-only and non-destructive. The description adds the specific behavioral effect of moving torrents to the bottom of the queue, which goes beyond the annotations. However, it does not disclose details like reversibility, impact on priority order, or conditions under which the operation might fail.

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 sentence that leads with the action and then mentions the parameter format. It is concise, front-loaded, and contains no unnecessary words or filler. Every word serves a purpose.

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 with one parameter and an output schema, so the description does not need to explain return values. The description covers the core action and parameter syntax. However, it lacks context about queue ordering mechanics, such as when this operation is applicable (e.g., whether queueing must be enabled) or how 'all' interacts with the queue. For a basic operation, this is adequate but with clear 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?

The input schema only provides the parameter type (string) with no description, and schema coverage is 0%. The description compensates by clearly explaining the parameter format: 'hashes is pipe-separated or "all".' This gives the agent the necessary information to construct valid inputs, though it does not provide examples or additional formatting details.

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 states the action: 'Move torrents to the bottom of the queue.' This uses a specific verb and resource, and directly distinguishes from sibling tools like top_priority, increase_priority, and decrease_priority. It is unambiguous and easy to understand.

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 implies when to use this tool: when you want to move torrents to the bottom of the queue. However, it does not explicitly mention alternatives or provide exclusions. For example, it does not clarify when to use bottom_priority versus decrease_priority, but the action itself is clear enough to infer proper usage.

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?

The readOnlyHint annotation already covers the safety profile, and the description adds the return shape, which is useful. However, no additional behavioral context (e.g., pagination, error conditions, or whether savePath can be null) is provided. It does not contradict the annotation.

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, compact sentence that directly states the output shape without any fluff. It is front-loaded and every word 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?

Given the tool's simplicity (no parameters, read-only, output schema exists), the description is complete enough. It explicitly states the return structure, which aligns with the output schema and reduces ambiguity.

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 has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema is empty, leaving no ambiguity.

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 indicates the tool returns all categories, with a specific data shape. It uses 'All categories' which implies listing/retrieval, and the shape distinguishes it from category mutation siblings. However, the verb is implicit rather than explicit (e.g., 'list' or 'get').

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 guidance is provided on when to use this tool versus alternatives like create_category or edit_category. The description does not mention exclusions or context, leaving the agent to infer from the name alone.

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?

The annotations already indicate this is a non-read-only (readOnlyHint false) and non-destructive (destructiveHint false) operation, and the description adds no behavioral context beyond that. It does not disclose potential errors (e.g., duplicate category), permissions needed, or any side effects. No credit is earned for additional transparency.

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 redundancy. It conveys the core operation and the key optional parameter in a compact, easily parseable form.

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 create operation, this is minimally viable: the description states the action and optional parameter. However, it lacks any contextual details such as prerequisites, error conditions, or relationship to sibling tools (like edit_category). Given the output schema exists, return values are not needed, but the description is still sparse for a mutation 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 schema has 0% description coverage, so the description must compensate. It mentions that save_path is optional, but this is already evident from schema (default: ''). It does not explain what 'category' means (e.g., the name of the new category) or what save_path is used for (e.g., the directory for torrents). The description adds minimal value 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?

The description clearly states the action: 'Create a category with an optional save_path.' The verb 'create' and resource 'category' are specific, and it distinguishes itself from sibling tools like edit_category or remove_categories by focusing on creation. The mention of save_path further clarifies scope.

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 guidance is provided on when to use this tool versus alternatives. It does not mention that edit_category should be used for existing categories or that remove_categories is for deletion. The description simply states the operation, leaving usage decisions 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?

Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds no extra behavioral context such as side effects, idempotency, error behavior, or permission requirements. It simply restates the action implied by the name.

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 very concise at two short sentences, front-loading the core purpose. However, it is so minimal that it misses peripheral but useful information like usage distinction, making it efficient but slightly under-specified.

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 create operation with one parameter, an output schema, and basic annotations, the description is adequate but not complete. It lacks any distinction from sibling tools and does not clarify whether tags already exist or how the operation behaves if a tag is duplicated. The output schema likely covers return details, so that is not a 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 input schema provides a single 'tags' string parameter with no description. The description adds essential meaning by specifying 'one or more names separated by commas,' which is crucial for correct usage. This compensates for the 0% schema description 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?

The description states a clear verb and resource: 'Create tags.' This is specific, but it does not distinguish between this tool and the sibling 'add_tags' which also relates to tags. The name helps, but the description alone does not clarify whether this creates tag definitions versus adding tags to 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?

No guidance is provided about when to use this tool versus alternatives. For example, it does not mention that this creates global tag definitions whereas 'add_tags' applies tags to specific torrents. There is no context about prerequisites or exclusions.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds no extra behavioral context beyond the core action, such as reversibility or handling of invalid hashes. The mention of 'all' is more about parameter semantics than behavioral disclosure.

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 extremely concise: two sentences with no filler. The first sentence states the purpose, and the second explains the parameter format. Every word earns its place, and the most important information is front-loaded.

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?

Given the tool's simplicity—one parameter, no nested objects, and an output schema present—the description is sufficient. It covers what the tool does and how to specify target torrents. Minor omissions like edge-case behavior when torrents are already at minimum priority are not critical for this simple operation.

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 input schema provides no description for the 'hashes' parameter (0% coverage), so the description must compensate. It explains that hashes can be pipe-separated or the literal 'all', which is essential for correct invocation. While it does not define what a torrent hash is or address case sensitivity, it adds significant meaning 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?

Description explicitly states the action 'Decrease queue priority' and the resource 'torrents', making the purpose unmistakable. This clearly distinguishes it from sibling tools like increase_priority, top_priority, and bottom_priority. The verb+resource combination is specific and 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 implies usage by stating the action, but offers no explicit guidance on when to use this tool versus alternatives. It does not mention that bottom_priority is for moving torrents to the very bottom, nor does it warn about behavior when torrents are already at the lowest priority. The sibling names provide some context, but the description itself lacks explicit when-to-use guidance.

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?

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds crucial context: that delete_files=true irreversibly deletes downloaded data. This goes beyond the annotation by clarifying the exact destructive behavior and warning about irreversibility.

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 concise sentences that are front-loaded with the core action. Every sentence provides value: the first states the verb and resource, the second explains key parameter nuances and a critical warning. No wasted words.

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 destructive tool, the description is complete: it covers the action, parameter format, special 'all' value, and the irreversible consequence. An output schema exists for return values, so no additional explanation is needed. The description matches the tool's complexity.

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%, but the description compensates by explaining both parameters: 'hashes is pipe-separated or all' for the hashes parameter, and the delete_files effect with its irreversibility. This fully covers the parameter semantics.

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 states 'Delete torrents' with a specific verb and resource. It distinguishes from sibling tools that manipulate torrents (e.g., pause, resume) by focusing uniquely on deletion. It also adds clarity on special inputs ('all') and the delete_files flag.

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 clear context on how to use the tool (pipe-separated hashes or 'all', delete_files behavior) but does not explicitly mention when to use it over alternative tools or provide exclusions. This is minor given the self-explanatory name.

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?

Annotations declare destructiveHint=false, but the description adds crucial behavioral context: torrents keep their data but lose the deleted tags. This reassures the agent that the operation is not destructive to torrent data, and clarifies the side-effect on torrents. This goes beyond the annotations and is valuable for safe invocation.

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 concise sentences, front-loaded with the action. Every word earns its place: the first sentence states the action, the second explains the parameter format and the effect on torrents. No fluff.

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 one-parameter tool, the description fully specifies the operation, parameter format, and side effects. With an output schema present (as per context signals), there is no need to detail return values. It is complete and self-contained.

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 parameter 'tags' in the schema has no description, so the tool description carries the full burden. It explicitly states the format: 'one or more names separated by commas.' This is critical for correct invocation and is not evident from the schema's plain string type.

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 starts with the direct imperative 'Delete tags', clearly identifying the action and resource. It distinguishes from sibling tools like remove_tags by specifying the global effect: 'Torrents keep their data but lose the deleted tags.' This makes the tool's purpose 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 implies when to use this tool: when you want to delete tag definitions globally, not just detach them from torrents. It clearly explains the contextual effect on torrents, but it does not explicitly mention alternatives or exclusion scenarios, such as 'use remove_tags to only remove tags from torrents.'

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?

The annotation readOnlyHint=true already covers safety. The description adds useful context about the input format (pipe-separated hashes or 'all') and units (bytes/s), which goes beyond the schema and annotations. This is meaningful behavioral disclosure.

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 sentence that conveys all essential information without fluff. It front-loads the core purpose and includes parameter details efficiently.

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 this simple read-only getter with an output schema, the description provides the necessary context: input format, unit, and keying. It does not need to explain return values because the output schema exists. It is complete for the tool's complexity.

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%, but the description fully explains the 'hashes' parameter: pipe-separated or 'all'. This directly compensates for the lack of schema documentation and is essential for correct usage.

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 identifies the resource and scope: per-torrent download speed limits in bytes/s, keyed by hash. It distinguishes from global transfer limits and setters, but lacks an explicit verb like 'get' or 'list', which slightly reduces clarity.

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 guidance is provided on when to use this tool versus alternatives. The description does not mention that global limits are handled by qbittorrent_transfer_download_limit or that setting limits uses qbittorrent_torrents_set_download_limit. It only states what the tool returns.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's 'Change' adds little on safety. It does add the constraint that the category must already exist, but it does not disclose potential side effects (e.g., whether existing torrents in that category are moved) or any path format requirements. Minimal extra transparency beyond annotations.

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 concise sentence that front-loads the action and target. It contains no empty phrases, redundancy, or irrelevant detail, making it highly efficient.

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 with only two parameters and an output schema, so a one-sentence description may suffice. However, it omits information about side effects, path requirements, and error conditions, which leaves some gaps for an agent. It is minimally viable but not fully 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 description coverage is 0%, so the description must compensate for the undocumented parameters. It only mentions 'save_path' and provides no details about 'category' or the expected format/constraints of either parameter. The parameter names are self-explanatory, but the description adds almost no semantics 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?

The description uses a specific verb ('Change') and resource ('an existing category') with a clear attribute ('save_path'), distinguishing it from create/remove category tools and from tools that set a torrent's category. It explains exactly what the tool does.

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 'existing category' implies the tool is for modifying a category that already exists, which gives some context for when to use it. However, it does not explicitly mention alternatives (e.g., create_category) or state when not to use it, 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?

Annotations indicate a mutation (readOnlyHint=false) without destructive intent. The description's 'Replace' is consistent with these annotations and adds no extra behavioral details (e.g., prerequisites or error behavior), but the bar is lower due to existing annotations.

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 sentence, front-loaded, and free of unnecessary words. It earns its place with direct, actionable language.

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 mutation tool, the description is minimally adequate. It covers the core action and mentions new_url, but lacks explicit detail about required parameters and potential side effects. The presence of an output schema reduces the need to describe return values, but overall completeness is only average.

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 description only explicitly explains new_url, while hash and url are implied but not clearly defined. It provides some context (url is the old tracker, hash identifies the torrent) but insufficiently compensates for the absent schema descriptions.

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 states the action ('Replace a tracker URL on a torrent') and the target resource. It distinguishes itself from sibling tools like add/remove trackers by specifying replacement with new_url.

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 usage is implied by the description: use this tool when you need to replace an existing tracker URL. However, it does not explicitly mention alternatives or when not to use it, providing only implied guidance.

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?

Annotations already indicate it's not read-only and not destructive. The description adds context about ID format and priority levels but doesn't detail side effects like immediate application or reversibility. This is acceptable given the simple setter nature.

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 concise sentences, front-loaded with the action, then clarifying parameters and values. No wasted words.

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 priority setter with an output schema, the description covers the essentials: action, ID source, and priority meanings. Missing explicit description of 'hash' could be a minor gap, but it's a common parameter across sibling tools.

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 compensates by explaining 'id' as pipe-separated file IDs and defining priority numeric values. 'hash' is not described, but its purpose is likely inferable from the torrent context.

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 states 'Set file priority for a torrent' with a specific verb and resource. It distinguishes from siblings like increase/decrease priority by describing absolute priority values, and references the file contents tool for IDs.

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 explicitly instructs that file IDs come from qbittorrent_torrent_contents and explains valid priority values. Though it doesn't name alternatives, this context guides correct usage and disambiguates from related 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows it is a non-destructive mutation. The description adds the special 'all' and pipe-separated format, but does not disclose side effects like behavior at max priority or whether priority changes are reversible. This is partial additional context beyond annotations.

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 conveys the purpose and parameter format efficiently.

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