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

Annotations indicate it's not read-only and not destructive. The description adds error handling details (connection failure) and success response format, providing context beyond annotations. However, it does not discuss idempotency or potential duplicate handling.

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?

Well-structured with sections for args, returns, examples, and error handling. Front-loaded with the main purpose. Slight redundancy in repeating parameter descriptions from the schema, but overall concise.

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?

Covers all aspects: input formats, all optional parameters, return format (both markdown and JSON), error handling, and examples. For a tool without output schema, it provides sufficient detail for the agent to understand 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 coverage is 100% with good descriptions. The description adds value through usage examples (e.g., 'params with URL and labels') and explains the torrent parameter types in more detail, going 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 verb 'Add' and resource 'new torrent to Transmission', and specifies the input formats (magnet URI, URL, base64). This differentiates it from siblings like transmission_remove_torrent or transmission_list_torrents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes explicit 'Use when' and 'Don't use when' examples, such as adding a magnet link versus searching for torrents. This provides clear context for when to invoke this tool vs 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 indicate this is a safe, read-only, idempotent operation. The description adds behavioral context: default download directory behavior and error handling for non-existent/inaccessible paths.

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 well-structured with sections (Args, Returns, Examples, Error Handling), concise without unnecessary words, and front-loaded with the main 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?

For a simple read-only tool with two parameters and no output schema, the description covers all essential aspects: purpose, parameters, examples, and error handling. Return value description could be more structured but suffices.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by including usage examples and clarifying the 'path' default, going 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 tool's purpose: checking free disk space at a given path. It uses a specific verb and resource, and distinguishes from sibling tools that handle torrent operations.

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 explicit usage examples ('Use when: ...'), making it clear when to invoke this tool. However, it does not mention when not to use it or suggest alternatives among siblings.

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, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe read operation. The description adds value by detailing the returned information (version, speed limits, etc.) and mentioning error handling ('Returns error if cannot connect'). This goes beyond annotations, though it does not discuss rate limits or auth requirements, which are less critical for a local daemon tool.

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 well-structured with clear sections (general, Args, Returns, Examples, Error Handling). Every sentence serves a purpose, and the most critical information (purpose) is front-loaded. There is no fluff or redundancy, making it highly efficient for an AI 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?

Given the tool's simplicity (one parameter, no output schema, comprehensive annotations), the description is complete. It covers functionality, parameters, return values, usage examples, and error handling. No significant gaps are present, and the agent can confidently invoke this tool based on the description alone.

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

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

Schema coverage is 100% with a clear enum and description for the only parameter (response_format). The description repeats essentially the same info ('Output format (default: 'markdown')') without adding new meaning or constraints. Thus, the description adds minimal value beyond the schema, warranting a baseline score of 3.

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 retrieves Transmission daemon configuration and settings. It uses specific verbs ('Get', 'retrieves') and explicitly lists the resource ('session configuration'). Among siblings (e.g., transmission_set_session, transmission_get_stats, transmission_get_torrent), this tool is uniquely positioned as a read-only session-wide config reader, which is evident from the title and description.

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 concrete usage examples (e.g., 'Show Transmission settings', 'What's my download directory?') that clarify common scenarios. However, it does not explicitly state when not to use this tool or point to alternatives (e.g., transmission_set_session for modifications). While the sibling context helps, the description could be more explicit about 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=true and destructiveHint=false, so the description's addition of error handling ('Returns error if cannot connect to Transmission daemon') provides useful behavioral context beyond annotations. No contradictions.

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 well-structured with clear sections: overview, args, returns, examples, error handling. Each sentence adds value with no wasted words. Front-loaded with the main 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?

Given the simplicity of the tool (1 optional parameter, no output schema), the description covers all necessary aspects: purpose, return structure, usage hints, and error handling. It is complete for effective 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 input schema has 100% coverage with a single parameter (response_format) fully described. The description restates the parameter in Args but adds no new semantics beyond the schema's enum, default, and description.

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

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

The description clearly states the tool retrieves Transmission session statistics, specifying current and cumulative data including download/upload totals, active torrents, and speeds. The verb 'get' and resource 'session statistics' are specific and distinct from sibling tools like transmission_get_session.

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 concrete usage examples ('Show me download statistics', 'How much have I downloaded total?', 'What's my current upload speed?'), giving clear context. However, it lacks explicit when-not-to-use guidance or alternative tool references.

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, idempotentHint, and destructiveHint. The description adds value by detailing return information, error messages, and connection failure scenarios, 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 structured with clear sections (Args, Returns, Examples, Error Handling) and is front-loaded with the purpose. Slightly wordy in examples but overall 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?

Given no output schema, the description provides a return summary covering all key fields. It explains parameters, error handling, and usage examples, leaving no critical gaps for a 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 coverage is 100%, baseline 3. The description adds examples and explains parameter types and default values, improving meaning beyond 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 states 'Get detailed information about specific torrent(s) by ID,' using a specific verb and resource. It distinguishes itself from sibling tools like transmission_list_torrents by focusing on detailed info for specific IDs rather than a 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?

The description provides concrete examples of when to use the tool (e.g., 'Show me details for torrent ID 5') and includes error handling. However, it does not explicitly state when not to use or compare with siblings, so it is slightly incomplete.

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

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. Description adds value by detailing return format, pagination with has_more indicator, and error handling ('No torrents found'). No 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?

Description is concise with clear sections (intro, Args, Returns, Examples, Error Handling) and front-loads the purpose, with 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?

Given no output schema, the description fully documents return formats for both JSON and Markdown, explains pagination, and mentions error handling, making it 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 has 100% coverage with descriptions for all 3 parameters. Description adds context through Args section and examples (e.g., limit=50, offset=50), slightly improving over baseline 3.

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 title and description clearly state the tool lists all torrents with status and statistics, distinguishing it from sibling tools like transmission_add_torrent (write) or transmission_get_torrent (single item).

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?

Description includes three use-case examples and implies pagination usage, but does not explicitly contrast with sibling tools like transmission_get_torrent for single torrent queries.

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 significant behavioral context beyond annotations: it explains the default behavior (physical move), the option to only update path, and error handling (non-existent path, permissions, time for large files). Annotations indicate readOnlyHint=false and destructiveHint=false, which are consistent and the description elaborates appropriately.

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 well-structured with sections (overview, args, returns, examples, error handling) and front-loaded with the core purpose. Every sentence adds value without 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?

Given the absence of an output schema, the description adequately states the return format (confirmation). It covers all four parameters, error cases, and provides usage examples. The tool is fully described for an agent to use 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 input schema has 100% coverage, providing baseline of 3. The description further clarifies the 'move' parameter with examples and default value explanation, adding value beyond the schema. It also lists 'ids' allowed types and 'location' path requirement.

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's purpose: 'Move torrent data files to a new location on disk.' The verb 'move' and the object 'torrent data files' are specific and distinct from sibling tools like transmission_add_torrent or transmission_remove_torrent.

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 usage context with examples ('Use when: ...') and explains the key parameter 'move' that controls behavior. However, it does not explicitly contrast with sibling tools or state when not to use this 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?

Discloses that pausing stops all activity, preserves progress for resumption, is idempotent, and returns errors for invalid IDs. These details complement annotations (idempotentHint=true, destructiveHint=false) without 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?

Well-organized with clear sections (Description, Args, Returns, Examples, Error Handling). Every sentence serves a purpose; 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?

Given 2 parameters, no output schema, and rich annotations, the description covers all essential aspects: purpose, usage, return values, error states, and differentiation from siblings. Fully adequate for 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?

Schema coverage is 100% so baseline is 3. The description reinforces parameter meaning via examples and error handling context, adding 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 it pauses active torrents to stop downloading/uploading. It uses a specific verb+resource and distinguishes from siblings like transmission_remove_torrent and transmission_resume_torrent.

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?

Provides explicit 'Use when' and 'Don't use when' examples, including an alternative tool. Also explains handling of single IDs, arrays, and 'all'. Agents get clear guidance on when to invoke.

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 claims 'Moving to top/bottom is idempotent', but annotations set idempotentHint: false, creating a direct contradiction. Additionally, it fails to disclose other behavioral traits like whether up/down moves are idempotent or any side effects beyond queue reordering.

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 well-structured with sections (main description, Args, Returns, Examples, Error Handling). It is front-loaded with the key purpose, though there is slight redundancy between the first two sentences.

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 3-parameter tool with no output schema and good annotations, the description covers input parameters thoroughly with examples and error handling. It lacks differentiation from the sibling tool transmission_move_torrent, which could cause confusion.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing examples for each parameter and clarifying that ids can be a single number, array, or 'all', which goes beyond the schema's enum and type 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 verb 'move' and the resource 'torrent(s) in the download queue', and explicitly says it reorders torrents to prioritize downloads. This 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 provides examples and a clear usage context ('Use this to prioritize certain downloads'), but does not explicitly exclude alternatives like transmission_move_torrent (which moves data files), nor state when not to use this 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 value beyond annotations by explaining that success does not guarantee tracker response and that it forces an immediate announcement versus the normal automatic interval. It also covers error handling for invalid torrent IDs. No contradictions 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 well-structured with sections for purpose, args, returns, examples, and error handling. It is front-loaded with the main action and uses bullet points for examples. While slightly longer than necessary, every sentence 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?

Given the tool's simplicity (2 params, no output schema, good annotations), the description covers all necessary aspects: purpose, usage scenarios, parameter details, error handling, and behavioral limitations. It is complete for an AI agent to correctly invoke the tool.

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

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

Schema coverage is 100%, so the description's parameter info (ids and response_format) is redundant but provides useful examples. It adds context for the ids parameter accepting various formats and response_format default. Baseline of 3 is appropriate as the schema already defines the parameters well.

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's action: 'Force torrent(s) to reannounce to their trackers.' It uses a specific verb (reannounce) and resource (torrents to trackers), distinguishing it from sibling tools like transmission_add_torrent or transmission_pause_torrent.

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 explicit use cases such as 'update peer lists', 'fix connection issues', and gives examples like 'Not getting any peers, force an announce'. It does not explicitly state when not to use, but the context is sufficient for an AI agent to understand appropriate scenarios.

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 destructiveHint=true, but description adds essential behavioral details: default behavior (keep files), deletion option, error handling, and confirmation messages. This adds significant 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?

Very well-structured: purpose statement, parameter details, examples, error handling. No fluff, every sentence adds value. Front-loaded with critical 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?

For a tool with 3 parameters and no output schema, the description fully covers usage semantics, parameter behavior, return format, and error cases. No gaps identified.

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 covers 100% of parameters, but description enhances understanding with usage examples, default values, and error conditions. The examples bridge the gap between schema and real-world application.

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 clearly states the action (remove torrents) and distinguishes from siblings by mentioning optional deletion of files. It also includes explicit examples that reinforce 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?

Provides concrete examples of when to use (e.g., 'Remove torrent 5 but keep the files') and explicitly warns against use for pausing torrents, pointing to the correct sibling 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?

Annotations provide idempotentHint=true and destructiveHint=false. The description adds that the tool succeeds even if torrents are already active (idempotent behavior) and explains error handling, providing value 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 well-structured with clear sections (Args, Returns, Examples, Error Handling). It is concise and front-loaded with the main purpose, using minimal but informative sentences.

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 tool with 2 parameters and no output schema, the description covers purpose, parameter details, return type, examples, and error cases. It is complete and leaves no 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?

Schema coverage is 100%. The description explains the ids parameter with examples and the response_format enum, but the schema already documents these thoroughly. The description adds practical usage 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 it resumes paused torrents to restart downloading/uploading, using specific verbs and resource. It distinguishes from siblings like pause_torrent and remove_torrent by focusing on the resume action.

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 includes explicit 'Use when' examples covering common scenarios like resuming a single torrent or all torrents. It lacks explicit when-not-to-use guidance, but the examples sufficiently cover typical 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 mutability (readOnlyHint false) and idempotency (idempotentHint true). The description adds that changes take effect immediately, returns confirmation, and handles errors, offering full behavioral transparency without contradicting 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 well-organized with sections for arguments, returns, examples, and error handling. It is slightly longer than necessary but each section contributes useful 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?

Given 11 optional parameters and no output schema, the description covers what the tool does, all parameters, example invocations, and error behavior. It is complete enough for an agent to use effectively.

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

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

Schema coverage is 100%, so the schema already describes all 11 parameters. The description repeats parameter details but adds value through example usage in the 'Examples' section, which help agents understand typical invocations.

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 it updates Transmission daemon configuration, listing specific settings like speed limits and download directory. It distinguishes itself from siblings such as transmission_get_session (read) and transmission_set_torrent (per-torrent), making the 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 includes 'Use when' examples for common scenarios (e.g., setting speed limits, changing download directory). However, it lacks explicit guidance on when not to use the tool or alternatives, though the sibling list provides context.

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 tool is idempotent, non-destructive, and not read-only. The description adds extra behavioral detail: error handling for non-existent IDs, validation of numeric ranges, and explanation of parameter meanings (e.g., seedRatioMode values, bandwidthPriority mapping). 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 well-structured with clear sections: summary, Args, Returns, Examples, Error Handling. It is concise yet comprehensive, front-loading the purpose and using efficient formatting.

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 10 parameters and no output schema, the description provides sufficient detail: all parameters explained, return value of confirmation stated, error handling documented, and examples given. An agent can correctly invoke the tool based solely on this description.

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

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

Schema coverage is 100%, so the schema already defines all parameters. The description's Args section mostly restates schema info but adds some extra context (e.g., mapping bandwidthPriority to low/normal/high, seedRatioMode meanings). Since schema covers basics, description adds marginal 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 tool updates settings for specific torrents including labels, speed limits, and seed ratios, using a specific verb and resource. It distinguishes itself from sibling tools like transmission_add_torrent or transmission_get_torrent.

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 includes concrete 'Use when:' examples (e.g., 'Set torrent 5 label to movies') that illustrate appropriate contexts. It does not explicitly exclude cases, but the examples provide clear guidance on typical usage scenarios.

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 key behaviors: verification runs in background, returns confirmation immediately, errors if IDs don't exist. Annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) are consistent with the description. No contradictions.

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 concise and well-structured with clear sections (usage, args, returns, examples, error handling). Every sentence adds value without 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?

Given the absence of an output schema, the description explains the return value ('Confirmation that verification has been started') and directs the agent to check torrent status for results. All necessary information is present.

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?

Input schema has 100% coverage, but the description adds meaningful context: explains 'ids' can be number, array, or 'all', and shows examples. Also explains the default for response_format. The description complements the schema well.

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's purpose: 'Verify the integrity of downloaded torrent data' and 'triggers a verification check of torrent files against their checksums'. It is distinct from sibling tools like transmission_get_torrent (which shows status) or transmission_resume_torrent.

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?

Explicit usage guidelines: 'Use this to ensure downloaded data is correct and complete, or to recheck files after moving them.' Examples are provided. However, it could explicitly state when not to use (e.g., for checking status) but that is implicit from context.

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