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

With no annotations, the description must disclose behavior. It mentions the default parent location and the folder-vs-bookmark distinction, but does not describe return values, error conditions, or side effects. Since it is a creation tool, an agent would benefit from knowing what the response contains or whether creation is idempotent.

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

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

The description is three short sentences, front-loaded with the core action. Every sentence adds functional information, with no filler 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 lack of an output schema and annotations, the description omits return value and error handling details. It also does not mention the index parameter's behavior beyond the schema. While adequate for basic usage, an agent might need to infer response structure or error handling from other sources.

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 already covers all parameters with descriptions, so the description adds limited new meaning. It does clarify the default for parentId (Other bookmarks) and reinforces the url omission rule, but the latter is already in the schema. Overall, the 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 creates a bookmark or a folder, with a specific condition for each (omit url for folder). It is unambiguous and distinct from sibling tools like update, remove, or search, which handle other 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 practical usage details such as omitting url to create a folder and the default parent when parentId is omitted. However, it does not explicitly compare against alternative tools like update or move, leaving the when-to-use decision to the agent's inference from the tool name.

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

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

Annotations declare readOnlyHint=true, which the description is consistent with (it says 'Return'). The description adds no additional behavioral details such as error handling, invalid id behavior, or output structure. With annotations covering the read-only nature, the description adds minimal value beyond what is already declared.

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

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

The description is a single, front-loaded sentence with no filler. It states the action immediately and uses precise language. This is appropriately concise with zero waste.

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

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

For a simple two-parameter read tool with no output schema, the description is adequate. It clarifies that it returns nodes by id, which is the core requirement. It does not mention the format parameter or potential error conditions, but the schema covers format, and the annotations cover safety. The description is sufficient for an agent to call the tool correctly, though it could note that it returns multiple nodes or that format affects output.

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

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

Schema coverage is 100%, so all parameters are described in the schema. The description 'Return the nodes with the given ids' essentially restates the ids parameter without adding syntax, default behavior, or output format details beyond what the schema already provides. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description states a clear verb ('Return') and resource ('nodes with the given ids'), unambiguously identifying it as a fetch-by-id operation. It distinguishes from siblings like get_tree (whole tree) and get_children (children) because it specifically mentions 'given ids'. However, it doesn't explicitly name alternatives, so it falls short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives like bookmarks_get_tree or bookmarks_get_children. It merely states the action without any context about use cases, prerequisites, or exclusions.

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

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

Annotations declare readOnlyHint=true and the description is consistent. The description adds useful behavioral context beyond that: children are returned directly, limited to immediate contents, and ordered by display order. This helps an agent predict actual behavior.

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

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

A single, front-loaded sentence with no filler. Every part adds meaning: 'direct', 'folders and bookmarks', and 'display order'.

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 low-complexity, read-only tool with a complete parameter schemachers, the description is sufficient. It states what is returned. The format parameter's enum descriptions in the schema cover output representation, and readOnlyHint covers safety.

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

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

Schema description coverage is 100%, so the schema already documents both id and format. The description does not add additional parameter details, but the baseline of 3 is appropriate because the structured schema carries the meaning.

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

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

The description clearly states the operation ('Return'), the resource ('direct children ... of a folder'), and the scope ('direct children' not nested, 'folders and bookmarks'). It distinguishes itself from siblings like bookmarks_get_tree by emphasizing direct children only.

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

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

The phrase 'direct children' implicitly tells an agent to use this when immediate descendants are needed, not the whole tree. However, it does not explicitly mention situations where bookmarks_get_tree or bookmarks_get should be preferred.

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, so safety is covered. The description adds the behavioral detail of newest-first ordering and the 'recently added' filter, which is useful context beyond the schema. 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?

A single sentence of eight words, perfectly front-loaded with the core action and resource, followed by the ordering detail. Zero waste.

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 read-only list tool with two parameters and no output schema, the description is adequate but minimal. It doesn't mention that the result is limited (default 20) or that format affects structure, though these are in the schema. It could hint at when the json format is useful.

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 50% (format has a description, count does not). The description adds nothing about parameters; it doesn't explain count limits, default behavior, or how format affects output. With half the parameters undocumented, the description should compensate but doesn't.

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

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

States a clear verb ('Return'), a specific resource ('recently added bookmarks'), and an ordering ('newest first'). It distinguishes itself from siblings like bookmarks_get_tree or bookmarks_search by focusing on recency, though it doesn't explicitly name alternatives.

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

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

No guidance on when to use this tool versus siblings. It doesn't mention alternatives like bookmarks_search for finding specific bookmarks or bookmarks_get_tree for hierarchy, nor any conditions that would make this tool the preferred choice.

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 readOnlyHint=true already covering safety, the description adds valuable behavioral context: it returns the whole tree or a subtree, and it warns that top-level folder ids vary across Chrome profiles. This goes beyond the annotation without contradicting it.

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

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

Two tight sentences, with the core purpose front-loaded and the usage note immediately following. Every sentence earns its place.

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

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

For a simple read-only tree retrieval tool with zero required parameters and fully documented schema, the description covers what the tool does, how to use it, and how it relates to a sibling. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces the meaning of id by referencing 'subtree under id', but it does not add much beyond what the schema provides.

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

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

States a specific verb ('Return') and resource ('the whole bookmark tree or the subtree under id'), making its function immediately clear. It also distinguishes itself from the sibling bookmarks_get_children by describing the tree-level scope and its role in finding folder ids.

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

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

Explicitly says when to use this tool: to find folder ids. It also names the alternative bookmarks_get_children and explains the specific profile-dependent caveat that requires calling it with id 0 to resolve top-level folder ids.

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 are not provided, so the description must carry the burden of behavioral disclosure. The description states the action (move/reorder) but does not provide details on side effects, such as whether the move is reversible, whether existing child order is affected, or whether permissions are required. It also doesn't mention what happens if parentId is omitted or if the index is out of bounds. This is a moderate disclosure, but not comprehensive for a mutation 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 a single, concise sentence that efficiently states the tool's dual purpose. It is front-loaded with the action and the two scenarios. No redundant words or filler. It earns its place by being informative without unnecessary elaboration.

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, 1 required, and no output schema, the description provides the core purpose but leaves gaps: it doesn't explain the behavior when index or parentId are omitted (though schema hints 'omit to append/stay'), nor does it describe return values or error scenarios. Given the moderate parameter count and lack of annotations, the description is adequate but not fully complete; an agent might need to experiment or rely on schema details for edge 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?

Schema description coverage is 67%: the schema documents 'index' and 'parentId' with descriptions, but the 'id' parameter has no description. The description adds context by explaining the overall purpose (moving to another folder or reordering), which helps interpret the parameters. However, it does not add detailed semantics beyond the schema, such as what 'index' exactly means in relation to the destination folder's children. Since schema covers most parameters, a baseline of 3 is appropriate.

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

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

The description clearly states the action: 'Move a node to another folder, or reorder it within the same folder.' It specifies the resource (node) and the two primary use cases (cross-folder move and reordering). It is specific enough to distinguish from siblings like bookmarks_create or bookmarks_remove, though it doesn't explicitly differentiate from bookmarks_update, which could also modify a node's location. Overall, the purpose is clear and action-oriented.

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

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

The description implies when to use the tool (for moving or reordering bookmarks) but does not explicitly state when not to use it or mention alternatives. For instance, it doesn't indicate that bookmarks_update might be used for other attribute changes, or that bookmarks_remove is for deletion. However, the context is sufficient for an agent to infer the primary use case, though explicit exclusions would improve the guidance.

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

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

The destructiveHint annotation already flags mutation, but the description adds that the operation cannot be undone and instructs the agent to confirm with the user. It also clarifies that only bookmarks or empty folders are valid targets, which is useful behavioral context beyond the annotation.

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

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

Two tight sentences front-load the action and scope, then give the alternative and warning. Every sentence earns its place with no filler.

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

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

For a single-parameter destructive removal, the description covers purpose, scope, the sibling alternative, and the need for user confirmation. Return-value details are not essential for this operation and are not required by any output schema.

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

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

Schema coverage is 0%, so the description must carry the parameter meaning. It implies the required id is the target bookmark or empty folder to remove, but it never explicitly maps id to 'the bookmark/folder identifier' or describes its format. For a single obvious id parameter this is mildly sufficient but not fully compensating.

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

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

The description uses the specific verb 'Remove' and names the exact resource scope: one bookmark or an empty folder. It also distinguishes itself from bookmarks_remove_tree, so an agent can tell them apart without inspecting schemas.

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 states a clear condition for using this tool ('one bookmark or an empty folder') and explicitly redirects non-empty folders to bookmarks_remove_tree. It also adds a usage prerequisite: confirm the target with the user before calling.

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 flag destructiveHint=true, and the description adds meaningful context beyond that: the operation is irreversible ('cannot be undone') and removes everything inside the folder. It also advises a safe inspection step, giving the agent a clear behavioral model without relying solely on the annotation.

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

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

Two sentences with no filler: the first states the action and scope, the second warns of irreversibility and instructs the precondition. Every word earns its place, and the critical warning 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?

For a simple one-parameter destructive tool with an existing destructiveHint annotation and no output schema, the description fully covers what an agent needs: the operation, its scope, its irreversibility, and the safe invocation procedure. There are no missing details that would cause incorrect 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?

With 0% schema description coverage, the description must compensate for the single 'id' parameter. It does not explicitly state that 'id' is the folder ID, but the wording 'Remove a folder' strongly implies it. This adds enough meaning beyond the raw schema (which only defines a string) to guide correct invocation, though an explicit mapping would be clearer.

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

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

The description states a specific verb (Remove) and resource ('a folder and everything inside it'), clearly distinguishing it from sibling bookmarks_remove (single bookmark removal). It unambiguously conveys the recursive scope of the operation.

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

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

The description explicitly tells the agent when to call (remove a folder recursively) and provides a precondition: inspect the subtree with bookmarks_get_tree and get user approval first. This is direct, actionable guidance with no ambiguity.

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 matching behavior: query is Chrome's built-in word match, not substring or fuzzy matching, while title and URL are exact. This is useful context beyond the annotation, though it doesn't mention result limits or ordering.

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

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

Two compact sentences that are front-loaded and free of fluff. Every clause conveys either the tool's purpose or a meaningful matching distinction.

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 optional parameters, fully documented schema fields, a format enum, and a read-only annotation, little is missing for a simple search tool. The absence of an output schema makes a note about return shape desirable, but the format parameter covers the main text-vs-JSON distinction.

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

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

Schema coverage is 100%, so the baseline is 3. The description genuinely adds meaning for the query parameter by explaining it as a word match against title and URL, but it mostly restates the exact-match semantics already present in the schema for title and url.

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

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

States a specific verb and resource ('Search bookmarks') and precisely distinguishes query matching ('word match against title and URL') from exact-match parameters. This clearly differentiates it from retrieval siblings like bookmarks_get and bookmarks_get_recent.

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

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

The description implies when to use it (keyword search or exact title/URL lookup), but it never names alternatives or exclusion conditions. An agent must infer the boundary with siblings like bookmarks_get_recent or bookmarks_get_tree, so usage guidance is only implicit.

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

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

The readOnlyHint annotation already declares that this is a safe read operationwed, and the description does not contradict it. The description adds a workflow hint but does not disclose behavior such as possible return values, failure modes, or the exact connection status shape; annotations carry the safety burden, so a mid score is appropriate.

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

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

The description is two short sentences with no wasted words. The purpose is front-loaded and the usage guidance is placed second, making the most important information immediately accessible.

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

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

For a zero-parameter, read-only status tool, the description gives the agent enough to know why and when to call it. The only minor gap is that no output schema exists and the description does not specify the exact shape or values of the returned status, but the core purpose is still fully actionable.

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

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

The tool has zero parameters and 100% schema description coverage, so there is no parameter semantic burden on the description. The baseline of 4 applies because nothing needs to be clarified or compensated for in this dimension.

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

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

The description states a specific action ('Return the connection status with the Chrome extension') and clearly identifies the resource. It is immediately distinguishable from the sibling bookmark CRUD tools, which all operate on bookmarks rather than the extension connection.

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 says when to use the tool: 'Check this first when a bookmark operation fails.' This gives the agent a clear trigger and precedence rule, and no alternative tool competes for this diagnostic role.

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, and it only states that fields are changed partially. It does not mention required identity lookup, error conditions, folder restrictions for URL (though the schema hints at that), or any side effects of the mutation.

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

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

A single, focused sentence with no filler. The key behavioral point ('only the fields given') is included, and the description is appropriately small for a simple update 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?

For a basic 3-parameter update with no output schema and no annotations, the description is minimally viable but leaves gaps: it does not state that 'id' is required, does not clarify folder restrictions, and does not describe what happens after a successful update. These are important for reliable invocation.

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

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

Schema description coverage is only 33%, and the description adds little beyond the schema property names. It does convey that only provided fields are updated, but it does not explain the role of 'id' as the bookmark identifier, the relationship between 'url' and folders, or any constraints on 'title'.

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

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

The description uses a clear verb ('Change') and specifies the resource ('bookmarks') and the exact scope ('title and/or URL'), which distinguishes it from the sibling create/move/remove tools. It is less explicit about which sibling it is not, but the update semantics are clear.

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

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

The phrase 'only the fields given' implies partial-update usage, so an agent can infer this is for modifying specific fields rather than replacing or deleting. However, there is no explicit guidance on when to prefer this over create/move/remove, nor any conditions or prerequisites like requiring an existing bookmark id.

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