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

With no annotations available, the description carries the disclosure burden. It clearly labels create, toggle, and update as WRITE (modifies the instance) and delete as DESTRUCTIVE (deletes data). This is valuable, though it does not mention permissions, idempotency, 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 clean bulleted list, each operation on its own line with a terse explanation. The opening line explains the dispatch pattern. Every sentence earns its place with no 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 multi-operation dispatcher, it covers all five operations and flags write/destructive behavior. It would be more complete with detailed parameter requirements for create/update, but the presence of an output schema likely covers return values. Adequately complete given the 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?

Since the input schema provides only generic `operation` and `arguments` fields, the description adds essential meaning by showing operation-specific parameters like `action_id` and `body={}`. For toggle, it even specifies the body format (`{"enabled": bool}`), but does not fully document body schemas for create/update.

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 this tool handles 'autobrr actions operations' and enumerates all five specific operations (create, delete, list, toggle, update). This distinguishes it from sibling tools like autobrr_filters or autobrr_indexers, as it's explicitly scoped to actions.

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 listing operations and instructing to pass an `operation` and `arguments`, but it never explicitly states when to use this tool versus alternatives. No exclusions or comparisons with 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly labels create as WRITE and delete as DESTRUCTIVE, and notes that the token appears only once, which is critical state-changing information. It doesn't mention read-only nature of list, but that's implied.

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 a one-sentence summary followed by a clear bullet list of operations. Each bullet has a function signature and safety annotation where relevant, with no redundant or verbose text. It 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 dispatcher pattern and three operations, the description covers operation selection, side effects, and token visibility. However, the create_api_key operation's body parameter is left entirely undocumented, which is a significant gap for invoking the tool correctly. Output schema exists, so return format is not needed.

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), so the description must compensate. It does list the parameters for each operation (body, apikey) in the function signatures, but lacks details on what the body should contain or what format apikey uses. The description adds some meaning beyond the raw enum, but not enough for full clarity.

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 handles 'autobrr api keys operations' and enumerates the three specific operations: create, delete, and list. This distinguishes it from sibling tools like autobrr_filters or autobrr_notifications, making the tool's purpose obvious.

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 this tool: whenever performing API key operations. It also explains the dispatcher pattern (pass operation + arguments) and lists each operation with its parameters. It doesn't explicitly state when not to use it, but the narrowing to API keys implies 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?

With no annotations, the description carries the burden. It clearly flags update_config as a WRITE that modifies the instance, and enumerates supported fields. It does not cover potential side effects like requiring restarts, but the main behavior is transparent.

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 short, well-structured with bullet points, and every sentence adds value. It front-loads the key instruction to pass operation+arguments, then details each operation 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?

The description covers both operations completely, including return info for get and supported fields for update. An output schema exists (not shown) but the description still provides sufficient context for a two-operation config 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 only provides 'operation' and a generic 'arguments' dict, but the description explains each operation's parameters, including which fields update supports and what get returns. This fully compensates for the 0% schema 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 clearly states it handles autobrr config operations, listing two specific sub-operations (get and update) with detailed return/update fields. It is distinct from sibling tools like autobrr_filters or autobrr_release, which handle other parts of the system.

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 this tool is appropriate (config management) and explains the operation+arguments pattern. It does not explicitly state alternatives or exclusions, but the scope is obvious from the tool name and operation list.

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?

Without annotations, the description takes on the burden of disclosing side effects. It explicitly marks create, test, and update as WRITE operations and delete as DESTRUCTIVE, which is valuable. It also adds contextual detail like the *arr-specific tags 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 concise bullet list with each operation's signature and a short description, front-loaded with usage instructions. Every line provides necessary information for selecting an operation.

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 dispatcher pattern with seven sub-operations, the description covers all operations and flags dangerous ones, but it lacks a concrete usage example and detail on how arguments map to each operation. The presence of an output schema reduces the need to explain return values.

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 only offers generic `operation` and `arguments` fields, with 0% coverage. The description compensates by listing each operation's signature (e.g., client_id, body={}), giving agents a template for constructing the arguments dict. However, it does not explain the structure or required fields of the body dict itself.

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 handling download client operations for autobrr, listing all seven sub-operations with one-line summaries. This distinguishes it from sibling tools that handle other autobrr resources.

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 naming each operation and its parameters, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. No exclusions or alternative tool references 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?

Even though no annotations are provided, the description explicitly labels every modifying operation with WRITE and every deleting operation with DESTRUCTIVE, adding clear side-effect disclosures beyond the schema. This gives the agent crucial safety information that the input schema 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 well-organized bulleted list with a front-loaded instruction. Each operation occupies one line with a concise summary, and side-effect markers (WRITE, DESTRUCTIVE) are used consistently. This is scannable and appropriately sized for a 12-operation dispatcher.

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 complexity of a multi-operation dispatcher, the description covers the operation inventory and side-effect behavior sufficiently. It leverages the existence of an output schema to avoid explaining return values, but omits authentication/rate-limit details and deeper parameter specifics. Overall, it is complete enough for an agent to select and invoke operations correctly in most cases.

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 is a generic dispatcher with `operation` and a free-form `arguments` dict, so the description is the only source of parameter meaning. It provides per-operation signatures (e.g., `autobrr_delete_feed(feed_id)`, `autobrr_toggle_feed_enabled(feed_id, body={...})`) and some inline explanations (e.g., 'body is a partial Feed with a url'), though not every operation's body parameters are fully detailed.

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 this tool handles feed operations on autobrr and enumerates all supported operations, distinguishing it from sibling tools focused on other resource types (actions, filters, indexers). However, the phrasing 'autobrr feeds operations on autobrr' is slightly awkward and the purpose is conveyed more by the operation list than a crisp verb+resource statement.

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

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

Usage is implied by the tool name and the context that these are feed operations for autobrr. The description instructs to pass an `operation` and `arguments` dict, and lists the available operations, but does not explicitly state when to use this tool versus sibling tools or provide when-not-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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It labels every mutating operation as WRITE, marks delete as DESTRUCTIVE, notes that duplicate creates and returns a new filter, and explains partial update semantics. It also includes the required body shape for toggle, which goes well beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The opening sentence states the invocation pattern, and each bullet is a tight, information-dense entry with operation name, arguments, and side-effect label. There is no fluff or redundancy despite the length required for 10 operations.

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 all operations, mutation/destructive behavior, and list query parameters, and an output schema exists for return-value details. However, it does not document the available fields inside complex create/update bodies, which is a minor gap for a filter API.

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 exposes a generic `operation` and `arguments` object, but the description documents each operation's specific parameters, defaults, and query params (e.g., `filter_id`, `body={}`, `sort`, `indexer`). With 0% schema description coverage, this fully compensates.

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 immediately identifies this as the tool for autobrr filter operations and then enumerates 10 concrete operations with specific verbs (Create, Delete, Duplicate, Fetch, List, Update). This clearly differentiates it from sibling tools for other autobrr resources.

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 explicitly instructs the agent to pass an `operation` and an `arguments` dict matching the operation's parameters, and the bullet list gives each operation's signature. It does not explicitly state when not to use the tool or name sibling alternatives, but the context is clear.

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

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

No annotations are provided, so the description carries the burden of disclosing side effects. It explicitly labels WRITE for create, test, toggle, and update, and labels delete as DESTRUCTIVE. It also gives a sample return for test_indexer_api. However, it does not discuss authentication, rate limits, or error behavior, so it is not fully comprehensive.

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 well-structured list with a one-line intro. Each operation is on its own line with a concise description and safety flag. There is no redundancy or filler, and the most important instruction (how to invoke) 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 complexity of nine sub-operations, the description covers each operation's purpose and flags mutating operations. It includes a sample return for the test operation and the body shape for toggle. However, it omits detailed body schemas for create/update and does not mention error handling or pagination/list behavior, though an output schema exists to cover return formats.

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 operation and an arguments dict with no property details. The description compensates by giving each operation's expected arguments (e.g., 'autobrr_delete_indexer(indexer_id)' and 'autobrr_toggle_indexer_enabled(indexer_id, body={"enabled": bool})'). It partially clarifies the shape of body but leaves create/update/test body content unspecified. Thus it adds value beyond the schema but not complete 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 begins with 'autobrr indexers operations on autobrr' and then enumerates nine specific sub-operations (create, delete, get, list, test, toggle, update). Each sub-operation has a clear verb and resource (e.g., 'List configured indexers'), making the tool's purpose unambiguous and distinguishing it from sibling tools like autobrr_filters or autobrr_actions.

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 instructs users to 'Pass operation and an arguments dict matching that operation's parameters', which clarifies the invocation pattern. It also lists all available operations, making it clear that indexer-related tasks belong here. However, it does not explicitly mention when not to use this tool or direct users to alternative sibling tools, so it stops short of full usage 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?

With no annotations provided, the description carries the full burden and does well by labeling each operation as WRITE or DESTRUCTIVE, such as 'WRITE: this modifies your autobrr instance' and 'DESTRUCTIVE: this deletes data.' It also adds useful specifics like 'channel is the channel name without the leading #.' It stops short of detailing authentication or error behavior, but the output schema mitigates return-value concerns.

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 well-organized bulleted list with a one-line overview. Each entry is necessary given the dispatcher design, and there is no redundant filler. The formatting makes scanning for operations easy.

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 all ten operations in the enum, maps their parameters, and flags write/destructive behavior. It misses some context like authentication prerequisites or error semantics, but given the complexity and the presence of an output schema, it is sufficiently complete for an agent to select the right operation and invoke it 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 description coverage is 0%, so the description must compensate. It does by listing the required parameters for each operation in function signatures, e.g., 'autobrr_get_irc_message_history(network_id, channel)'. It also clarifies that `body` is a dict and explains the channel format. It does not specify types or requiredness for every parameter, but it provides essential 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 clearly identifies the tool as handling 'autobrr irc operations' and then enumerates every specific operation with a verb and resource (e.g., 'autobrr_create_irc_channel', 'autobrr_delete_irc_network'). This distinguishes it from sibling tools that handle other autobrr domains like actions, filters, or indexers.

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 opening instruction—'Pass `operation` and an `arguments` dict matching that operation's parameters'—provides clear usage guidance for the dispatcher pattern. While it doesn't explicitly state when to prefer this tool over siblings, the scope ('irc operations') and the per-operation list make the context clear, and there are no misleading 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?

With no annotations provided, the description carries the full burden and does a good job by tagging each operation with WRITE or DESTRUCTIVE labels, e.g., 'DESTRUCTIVE: this deletes data.' This discloses the mutation risk. However, it does not mention other behavior like idempotency, response format, or whether operations require the autobrr instance to be online, leaving some transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is concise: one intro sentence and a structured bullet list. Each bullet names the operation and a one-line effect. There is no filler; every sentence adds value. The format is easily scannable for an agent deciding which operation to call.

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 dispatcher with six operations, the description covers all operations and their mutation/destructive nature. An output schema exists (per context signals), so return values need not be described. However, it lacks broader context like prerequisites (e.g., autobrr instance connection), error conditions, or ordering dependencies between operations, which would round out completeness.

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 two parameters: operation (enum) and arguments (freeform dict). The description provides no explicit explanation of the 'arguments' parameter, but the bullet signatures (e.g., 'autobrr_create_list(body={})', 'autobrr_delete_list(list_id)') hint at the expected keys. With 0% schema description coverage, this is helpful but incomplete—full parameter semantics for each operation are not defined.

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 this as a dispatch tool for autobrr list operations, listing specific verbs (create, delete, list, refresh, update) against 'import list' resources. This distinguishes it from sibling tools like autobrr_filters or autobrr_indexers. However, the opening line 'autobrr lists operations on autobrr' is ambiguous (could read as 'lists' the noun or 'lists' the verb), and the resource is only fully clear from the bullet examples.

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 bullet list implies when to use the tool: 'if you need to create, delete, list, refresh, or update import lists, use this operation.' There is no explicit statement of when NOT to use it or alternatives (e.g., 'for filters, use autobrr_filters'). The guidance is implicit via operation names, not explicit comparative 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?

No annotations are provided, so the description carries the transparency burden. It explicitly tags mutating operations as WRITE and the delete operation as DESTRUCTIVE, which is valuable safety information. However, it doesn't describe side effects for read operations or error/return behavior, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured as a bullet list, each line containing an operation signature and a note where relevant. No wasted words; it front-loads the invocation pattern and then enumerates operations 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 a multi-operation dispatcher with 7 sub-commands, the description covers all operations, their parameter signatures, and safety flags. An output schema exists, so return-value documentation is not required. Some gaps remain in detailed argument semantics, but overall it is sufficiently complete for an agent to select and invoke operations.

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

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

With 0% schema description coverage, the description must compensate. It lists parameter names and defaults (e.g., body={}, notification_id, token='') and gives one specific explanation (token is a Pushover application token). However, it fails to explain the structure or required fields of the 'body' parameter used by create/update/test, which is a significant omission.

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 this as a tool for autobrr notification operations and lists seven specific sub-operations with descriptive names (create, delete, get, list, test, update). This distinguishes it from sibling tools that handle other autobrr resources.

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 instructions on how to invoke the tool ('Pass operation and an arguments dict') and enumerates each operation with its parameter signature. While it doesn't explicitly mention when to prefer this tool over siblings, the scope is unambiguous. It lacks explicit exclusions or alternative tool recommendations.

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

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

With no annotations provided, the description takes full responsibility for disclosing side effects. It explicitly labels write operations (create, test, update) and destructive operations (delete) with warnings like 'this modifies your autobrr instance' and 'this deletes data', providing valuable safety context beyond what any annotation could.

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 a brief instruction up front followed by a clear bulleted list. Each bullet conveys operation name, parameter signature, and side-effect status without redundancy. It is appropriately sized for the complexity and front-loads the critical dispatch mechanism.

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 dispatcher with a generic schema, this description is remarkably complete. It covers all operations, parameter formats, and side effects, while the presence of an output schema removes the need to document return values. The scope is well-defined, leaving no significant gaps for the agent to infer.

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 description coverage is 0%, leaving the `arguments` object completely open-ended. The description compensates by detailing each operation's parameter pattern (e.g., body={}, proxy_id), giving the agent concrete guidance on how to structure the arguments dict for each operation. This adds essential 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 enumerates all six operations with specific verbs (Create, Delete, Fetch, List, Test, Update) and clearly indicates the resource (proxy). This distinguishes it from sibling tools that handle other autobrr modules, making the tool's purpose explicit 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 explains how to use the dispatcher (pass operation and arguments) and lists each operation's signature, making it clear which operation to invoke. However, it does not explicitly compare with sibling tools or state when to prefer this over alternatives, though the scope is implicitly obvious from the 'proxy operations' phrasing.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly labels write operations as 'WRITE: this modifies your autobrr instance' and destructive ones as 'DESTRUCTIVE: this deletes data', which is meaningful and safety-relevant. It does not cover auth, rate limits, or reversibility, but the mutation/destruction flags add real transparency beyond the bare operation names.

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 long but necessarily so for 22 operations. It is structured as a clear bulleted list with each operation on one concise line, and the repeated WRITE/DESTRUCTIVE tags provide consistent safety cues without bloating each line. The length is justified by the number of sub-operations, and the list format makes it easy to scan.

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 complexity of a 22-operation dispatcher, the description covers each operation's purpose and key parameters, and an output schema exists to handle return values. The main gaps are that `arguments` construction for body-bearing operations lacks field-level detail and there are no explicit error or authentication notes, but overall it is reasonably complete for its scope.

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 exposes `operation` and an opaque `arguments` object, so the description is the only source of parameter meaning. It includes parameter names, defaults, and enum values for many sub-operations (e.g., older_than=0, days=30, push_status=PUSH_APPROVED|...), which is critical for constructing valid arguments. However, body dicts are only hinted via `body={}` without detailed field definitions.

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 this as a dispatcher for autobrr release operations and enumerates 22 concrete sub-operations with one-line explanations, making the tool's scope specific. The release domain distinguishes it from sibling tools like autobrr_filters and autobrr_actions, though it does not explicitly contrast them.

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 the invocation pattern ('Pass operation and an arguments dict') and lists the available operations, so it is easy to understand how to use the tool. However, it never explicitly states when to choose this tool over sibling tools or provides exclusions, leaving usage timing to be inferred from the name and operation list.

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 declares readOnlyHint=true, but the description explicitly labels autobrr_check_updates as a WRITE operation that modifies the autobrr instance. This is a direct contradiction, triggering a score of 1 regardless of 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 well-structured bulleted list of operations, each with a concise, informative one-liner. It front-loads the general invocation pattern and avoids redundant or filler content.

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 purpose and basic behavior of each operation, including return values for health checks. However, it omits per-operation argument specifications and lacks explicit usage guidelines or exclusions, and the annotation contradiction undermines completeness. The presence of an output schema reduces the need to explain return formats, but the parameter gap remains.

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 gives generic guidance to pass an 'arguments' dict matching the operation's parameters but does not detail what arguments each operation accepts. With schema description coverage at 0%, the description fails to compensate and leaves the agent without necessary 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 the tool performs 'autobrr system operations' and enumerates five specific operations, each with a verb and resource. It differentiates from sibling resource-specific tools by focusing on system-level actions like health checks and update checks.

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 conveys the tool is for system operations, which implies a scope distinct from sibling tools that manage specific resources. However, it does not explicitly state when not to use this tool or mention alternatives, though the operation list provides clear context.

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