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

With no annotations provided, the description carries the full burden. It reveals important behaviors like force_save bypasses validation, force_test skips cached-test check, bulk update applies tags to all, and app profiles were added in Prowlarr 1.19+. Destructive operations are named as 'delete' but reversibility or permissions are not explicitly stated, which prevents a 5.

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 bullet list with each operation on one line, front-loaded with an overall usage instruction. Every sentence provides value—no filler or repetition. The length is appropriate for the number of operations covered.

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 design and the presence of an output schema, the description covers all necessary aspects: what each operation does, what arguments it takes, and important nuances (schema fetches, force flags, version availability). It is complete for an AI agent to select and invoke the correct 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 only shows operation (enum) and a generic arguments object (0% coverage). The description compensates fully by listing each operation's exact parameters and expected types (e.g., 'body is an ApplicationResource', 'id' for delete). It even directs users to fetch schemas for provider fields, which is essential for correct invocation.

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 is for Prowlarr applications operations and enumerates 17 specific operations with verbs (create, delete, list, test, update, etc.). This distinguishes it from sibling tools like prowlarr_indexers or prowlarr_download_clients by resource domain and operation 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 gives a clear general usage instruction ('Pass operation and an arguments dict') and explains each sub-operation with its purpose (e.g., 'Read this before creating/updating an application'). It doesn't explicitly mention when not to use this tool vs alternatives, but the sibling tools are clearly different resources, so the context is sufficient.

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

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

With no annotations, the description carries full transparency responsibility. It does reveal mutation vs. read operations via verbs (create/update/delete vs. get/list) and describes some parameter shapes. However, it omits side effects, permission requirements, error behavior, or irreversibility details—important for operations that alter Prowlarr configuration.

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 bullet list with a brief introductory instruction. Each line is informative and necessary, covering all operations without redundancy. It is front-loaded with the invocation pattern and then enumerates operations concisely.

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 complexity (13 operations), an output schema exists, but the description still needs to clarify how to pass arguments for each operation. It does so for custom filters, but leaves some operations underspecified (e.g., update_download_client_config body). This creates ambiguity for correct invocation of some 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?

Schema description coverage is 0%, so the description must compensate. It gives detailed parameter info for custom filter operations (e.g., 'body is a CustomFilterResource with a name, label, type...'), but for update operations like update_development_config and update_download_client_config, it only names the body parameter without describing its fields, leaving gaps.

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 domain as 'prowlarr config operations' and enumerates 13 specific sub-operations with clear verbs (get, list, create, update, delete). This distinguishes it from sibling tools like prowlarr_indexers or prowlarr_system by 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?

It provides explicit invocation guidance: 'Pass operation and an arguments dict matching that operation's parameters.' The operation list effectively tells an agent which operation to use for a given config task. However, it doesn't explicitly state when to prefer this tool over sibling tools, though the domain naming makes this clear.

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

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

With no annotations, the description carries the full burden. It discloses each operation's action (delete, create, list, test) and adds behavioral details such as 'force_save bypasses validation' and 'Read this before creating or updating a download client'. It stops short of covering permissions, error handling, or reversibility, but the per-operation behavior is well conveyed.

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 uses a scannable list format with each operation on its own line, providing the signature and a one-line effect. Every entry adds value, and the opening lines establish the overall usage pattern 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?

All 11 operations are documented with their parameters and prerequisites, and an output schema exists to cover return formats. The description does not delve into argument object internals, but the references to DownloadClientResource and schemas cover the essentials, making it sufficiently complete for a dispatcher tool.

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

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

Schema coverage is 0% and the input schema only has generic operation/arguments fields. The description compensates by listing each operation's signature with parameter names and types (body, id, force_save), and refers to prowlarr_list_download_client_schemas for body structure. This gives the agent meaningful guidance beyond the schema.

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

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

The description explicitly states this tool handles 'download clients operations on Prowlarr' and then lists every operation with a specific verb and resource (e.g., 'Bulk-delete download clients', 'Create a download client'). This fully differentiates it from sibling tools focused on indexers, applications, system, etc.

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 line explains how to invoke the tool (pass an operation and arguments dict), and there are helpful hints like reading schemas before creating/updating and force_save bypassing validation. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, so the guidance is 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 declare readOnlyHint=true, and the description adds useful behavioral context by describing the nature of the operations (history queries) and specific parameter quirks (e.g., lists of ints, event_type enums). It does not contradict the read-only hint and avoids any misleading side-effect language.

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 efficiently structured as a list of operations, with each line containing complete, non-redundant parameter information. Every sentence earns its place; there is no fluff, and the most critical instruction (pass operation and arguments) 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 that this tool dispatches multiple operations, the description covers all three operations with sufficient parameter detail for correct invocation. The presence of an output schema means return values need not be described. The description 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?

The input schema is generic (operation + free-form arguments) with 0% schema description coverage. The description compensates fully by listing each operation's exact parameter names, types, defaults, and example enum values (e.g., event_type='indexerQuery'). This is essential for correctly constructing the arguments dict and goes far 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 explicitly names 'history operations on Prowlarr' and lists three concrete operations (prowlarr_list_history, prowlarr_list_history_indexer, prowlarr_list_history_since), clearly distinguishing this tool from sibling admin tools like prowlarr_search or prowlarr_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?

It provides clear usage guidance by requiring an `operation` and an `arguments` dict, and details each operation's parameters. It doesn't explicitly contrast with sibling tools, but the domain is so distinct that the when-to-use is implied. Specific conditions for choosing among the three history operations are conveyed through their parameter lists.

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. It discloses some behavioral traits: 'force_save bypasses validation', test operations run 'without saving', and actions can 'toggle status'. However, it omits side effects like whether delete is irreversible, any permission requirements, or rate limits, leaving partial 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 bullet list with each operation on its own line, making it easy to scan. It is longer than a single-sentence description, but the length is justified by the need to document nine distinct operations and their parameters. No superfluous 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 complexity (9 operations) and minimal input schema, the description does a solid job covering all operations, their parameters, and ordering hints like fetching schemas first. It does not provide example argument dictionaries, but the operation signatures are sufficient for a competent agent. The presence of an output schema reduces the need to describe 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 input schema only defines 'operation' and a free-form 'arguments' object, so parameter semantics are entirely reliant on the description. The description provides detailed signatures for each operation, including required parameters (e.g., 'body is an IndexerProxyResource'), optional parameters (force_save=None), and cross-references to schema-fetching operations, adding meaningful guidance beyond the schema.

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

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

The description opens with 'prowlarr indexer proxies operations on Prowlarr' and then enumerates all supported operations with specific verbs (create, delete, get, list, test, update). This makes the tool's purpose clear and distinguishes it from sibling indexer tools, though the opening phrase is generic rather than a concise 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?

The description clearly states this tool is for indexer proxy operations and even provides operational guidance, such as 'Read this before creating or updating a proxy' and noting that test operations do not save. It does not explicitly contrast with sibling tools, but the context is clear enough that an agent can infer when to use 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?

With no annotations provided, the description carries the full burden. It discloses each operation's behavior, side effects (delete, test, update), and special semantics (force_save bypasses validation). It could add more detail on error handling or auth requirements, but it covers the main behavioral aspects well.

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 perfectly structured as a bulleted list of operations with syntax signatures and per-operation notes. Every line adds unique value; there is no fluff or redundancy. The front-loading explains the required dispatcher pattern immediately.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 14 operations, minimal schema (only operation + arguments), and no annotations, this description is exceptionally complete. It names every operation, its expected arguments, and provides prerequisite guidance ('Read this before creating an indexer'). An output schema exists, so return-value details are not 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?

Input schema coverage is 0%, so the description fully compensates. It defines the enum values via operation names and explains the contents of the 'arguments' dict for each operation (e.g., 'start_date/end_date are ISO dates; indexers/protocols/tags are comma-separated filters'). This converts an opaque 'object' into actionable parameter knowledge.

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 'prowlarr indexers operations' and enumerates all 14 available sub-operations with specific verbs (bulk-delete, create, delete, list, test, update). This distinguishes it from sibling tools covering other Prowlarr domains (search, system, config, etc.).

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 the dispatcher pattern ('Pass operation and an arguments dict') and gives practical usage hints per operation (e.g., 'Read this before creating an indexer' for schemas, force_save bypasses validation). It does not explicitly mention when to avoid this tool in favor of a sibling, but the scope is clear from the 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does well by noting that force_save 'bypasses validation', that test_notification sends a test 'without saving it', and that test_all_notifications sends through 'every configured notification'. It does not mention side effects like permanence of delete or auth requirements, but given the range of operations, the provided details add meaningful behavioral context 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 description is long due to the number of operations, but every line is informative and there is no fluff. The structure is consistent with a clear formatting pattern, and the initial summary makes the tool's purpose immediately clear. It could be slightly more compact, but the density of useful information justifies the length.

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 multi-operation dispatcher nature, the description covers the main function of each operation and key parameter variations. It references an output schema and points to related operations (e.g., schemas for creation). It doesn't detail error handling or return structures, but the presence of an output schema mitigates that gap. Overall, it is adequately 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?

The schema has generic 'arguments' with 0% coverage, but the description compensates significantly by listing each operation's signature and parameter purposes, e.g., 'body is a NotificationResource (fetch prowlarr_list_notification_schemas for providers)' and 'force_save bypasses validation'. While it doesn't define the exact structure of the body dictionary, it directs to a schema, which is sufficient for an agent to proceed.

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 'prowlarr notifications operations' and enumerates nine specific operations with precise verbs (create, delete, get, list, test, update). It distinguishes from sibling tools by focusing exclusively on notifications, and the operation list leaves no ambiguity about the tool's 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 provides clear context for using the tool and even intra-tool guidance, such as 'Read this before creating or updating a notification' for prowlarr_list_notification_schemas. It doesn't explicitly contrast with sibling tools, but the name and scope make the appropriate use case obvious. It could explicitly state when not to use this tool, but the context is strong.

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 discloses important behavioral details: return types (base64 string, XML string, status JSON), side effects (sending to download clients), and prerequisites (e.g., 'get one from a prowlarr_search_releases result'). It does not cover auth or rate limits, but provides solid operational 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 long but highly structured with a bullet list, each line containing the operation signature and a concise explanation. There is no filler; every sentence adds value. The opening instructions on how to pass `operation` and `arguments` are front-loaded and clear.

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 six operations listed in the enum, their parameters, and their return values. It also clarifies how to construct the arguments dict. Given the complexity and lack of schema detail, this is fully complete for an agent 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 description coverage is 0%, but the description compensates fully by giving a complete signature for every operation and explaining key parameters (e.g., 'id is the indexer id', 'query is the search term', 'repeat the param for each'). This is far beyond baseline and makes invocation reliable.

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 Prowlarr search operations and enumerates all six sub-operations with specific verbs (e.g., 'Search every indexer', 'Download a release', 'Send a release'). It distinguishes from sibling tools by focusing on search and related release operations, making its 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 sub-operation descriptions provide clear context for when to use each (e.g., 'Query a single indexer' vs 'Search every indexer'), and the tool name implies its role relative to sibling categories. However, it does not explicitly discuss alternatives or exclusions, so it earns a 4 rather than 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?

The description explicitly marks `system_restart` and `system_shutdown` as 'Destructive -- the server goes offline' and notes that `restore_backup` triggers on next restart. It also explains side effects like `run_command` requiring a `CommandResource` name. Since annotations are absent, the description carries the burden and does so well, though not every operation gets deep behavioral detail.

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 compact bullet list with each operation on one line, front-loaded with the invocation pattern. It's long of necessity (27 sub-operations) but avoids filler; only minor redundancy is the repeated 'prowlarr_' prefix in every bullet.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and a generic schema, the description covers all 27 operations with signatures, defaults, and edge cases (e.g., empty path lists root; level filter values). It also marks destructive operations and gives body examples. For a high-complexity dispatcher, this is a thorough and self-contained reference.

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 defines a generic `arguments` dict, but the description lists exact signatures for each operation, e.g., `prowlarr_list_filesystem(path='', include_files=None, ...)` with path semantics, and `prowlarr_list_logs` with `level` filter values. For `restore_backup_upload`, it gives the exact body structure. This fully 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 opens with 'prowlarr system operations on Prowlarr' and then enumerates 27 specific system operations (backups, logs, tasks, filesystem, status, routes), each with a verb-object form. This clearly distinguishes it from sibling tools like prowlarr_indexers or prowlarr_applications, which focus on specific resource domains.

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 list of operations covers system administration (backups, logs, tasks, server restart/shutdown), and several entries include guidance such as get_api_info 'useful for confirming connectivity and version' and list_filesystem path semantics. It doesn't explicitly exclude other tools, but the operation scope makes the intended domain clear.

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

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

With no annotations, the description carries the behavioral burden. It discloses that delete fails if the tag is still in use, that get_tag_details returns usage counts, and that list_tag_details counts usages across specific entity types. These are meaningful behavioral details beyond the raw operation names, though it does not cover auth/rate limits or full side-effect 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 a tight bulleted list with a one-line introductory instruction. Every line is necessary and directly maps an operation to its purpose. 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?

Given the tool's broad dispatcher nature and the existence of an output schema, the description covers every operation variant and includes practical caveats (delete failure when in use, usage-count details). It is sufficiently complete for an agent to select and invoke the correct tag operation, though it could additionally describe return shapes or update semantics.

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 a generic 'arguments' object with 0% coverage, so the description must add semantic meaning. It does so by listing each operation with its parameter signature, e.g., 'prowlarr_create_tag(body) — Create a tag. body is a TagResource with a `label`', including a concrete example. It does not exhaustively document all TagResource fields, but it compensates well for the generic schema.

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

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

The description opens with 'prowlarr tags operations on Prowlarr' and enumerates seven specific operations (create, delete, get, get details, list details, list, update). It clearly identifies the resource (tags) and the verbs, and the sibling tools show these are distinct from other Prowlarr resource categories.

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 to pass an 'operation' and an 'arguments' dict matching that operation's parameters, which is clear usage guidance for this dispatcher-style tool. It does not explicitly state when not to use this tool, but the sibling list makes it evident that tags are a distinct resource.

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