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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses important side effects: the cart is cleared when items come from a different restaurant, the full cart is sent to foodpanda for price validation, and updated totals are returned. It does not mention failure modes, authentication, or quantity merging, but the core behavior is well covered.

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 tightly written sentences with no filler. The action is front-loaded, followed by the key behavioral caveat and the outcome, making every word purposeful.

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

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

The tool has no output schema and no annotations, yet the description covers the primary return ('updated totals') and the critical cross-restaurant behavior. It is sufficiently complete for an add-to-cart operation, though it could mention potential validation failures or item unavailability.

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 baseline is 3. The description adds meaningful parameter-related context by linking restaurant_id to the cart-clearing behavior and indicating that the items parameter supports multiple entries. This goes slightly beyond the schema's field-level descriptions.

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

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

The description clearly states the action ('Add') on a specific resource ('cart'), supports 'one or more items', and highlights a distinguishing behavior (clearing the cart when the restaurant changes). It is easily differentiated from siblings like get_cart, remove_from_cart, and place_order.

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 items need to be added to the cart. It also explains the specific scenario of switching restaurants and the resulting cart-clearing behavior. It does not explicitly list when-not-to-use or alternatives, but the context is unambiguous given the sibling names.

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

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

No annotations are provided, so the description carries the full burden. It discloses the empty-cart return behavior ('Cart is empty.') and lists the exact contents. It does not mention side effects, but as a read operation none are expected. This is sufficient for a simple getter.

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 waste. The purpose and content are front-loaded, and the empty-case behavior is added as a separate, clear note. Every word earns its place.

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

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

For a parameterless, no-output-schema tool, this description fully covers what an agent needs to know: what it returns and the special empty case. The sibling set is sufficiently distinct that no additional routing guidance is necessary.

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

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

There are zero parameters, so the schema provides no semantics. The description compensates by explaining what the tool returns, which is the only relevant information. Given 0 parameters, this is appropriately handled.

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

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

The description clearly states the verb 'View' and the resource 'current in-memory cart contents', enumerating the included fields (items, quantities, prices, delivery fee, service fee, totals). This distinguishes it from sibling tools like add_to_cart or place_order, which imply mutation.

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 clearly implies this is the read-only cart inspection tool, contrasting with siblings that modify or finalize orders. While it doesn't explicitly state 'use this instead of preview_order', the context is strong enough that an agent would know when to call 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?

No annotations are provided, so the description must carry the behavioral burden. It states it 'gets' details, implying a read-only operation, but never explicitly confirms no side effects or mutation. It also doesn't mention potential rate limits, error conditions, or data volume. The description stays at the purpose level and does not add behavioral context beyond that.

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

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

Two concise sentences. The first states purpose and scope; the second provides usage context. No redundant phrases or unnecessary details. Information is front-loaded, making 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?

For a simple read-only tool with two fully documented parameters and no output schema, the description covers the essential usage scenario. It tells the agent when to call it and what to expect (toppings and customization options). It lacks mention of return format, but that's not required without an output schema. The guidance is sufficient for correct invocation.

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

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

Schema coverage is 100% with both parameters described (item_code as product code, restaurant_id as vendor code). The description does not add any parameter-specific meaning beyond the schema, which is the baseline for high coverage. No extra syntax or format details are given, so a 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 states a specific verb 'Get' and resource 'full details for a menu item', and explicitly lists what's included (topping groups, customization options). This distinguishes it from siblings like get_menu (which likely lists items) and get_restaurant_details (restaurant-level info).

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 when-to-use scenario: 'before adding to cart' when you need to know available toppings/variations. It implies it's not needed otherwise, though it doesn't explicitly name alternatives like get_menu for basic menu browsing. The guidance is sufficient for an agent to decide.

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 states that the tool returns a compact list, organized by category, and includes sold-out status. This conveys the read-only nature implicitly via 'Get' and describes the output structure. However, it does not explicitly mention that no modifications occur or any authentication/rate-limit requirements, but for a simple get operation this is sufficient. It adds useful behavioral context about the return format and status flags.

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

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

The description is two sentences with zero filler. The primary action and output are front-loaded, and the alternative tool is mentioned concisely. Every sentence contributes to the agent's understanding.

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 get-menu tool with one parameter and no output schema, the description is complete. It tells the agent what to expect in the response (code, name, price, sold-out status), how to use the result (item code for cart), and when to use an alternative. There is no missing information an agent would need to correctly invoke this tool.

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

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

Schema coverage is 100% for the single parameter, restaurant_id, which is described as 'The vendor code (e.g. 'p7nl')'. The description does not add additional meaning to the parameter beyond what the schema already provides. Baseline of 3 is appropriate when the schema fully documents the parameter.

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

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

The description clearly states the verb ('Get'), the resource ('the menu for a restaurant'), and the organization ('by category'). It also specifies the return contents (item code, name, price, sold-out status) and differentiates from get_item_details by indicating that tool is for toppings/customizations. This makes the tool's purpose unambiguous and distinct from siblings.

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 use this tool ('Get the menu') and when to use an alternative ('Use get_item_details if you need topping/customization options'). It also provides a follow-up action ('Use the item code when adding to cart'), guiding the agent toward the correct workflow. This is explicit 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully lists the kinds of data returned (address, hours, minimum order, delivery info), which compensates for the missing output schema. However, it does not explicitly state that the operation is read-only or describe error behavior, so behavioral transparency is only partially fulfilled.

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

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

The description is one concise sentence with no wasted words. It front-loads the main action and packs the key details into a compact list, making it easy for an agent to parse quickly.

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

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

For a simple one-parameter read operation with no output schema, the description adequately conveys what information will be returned. It could mention how to obtain the restaurant_id or what happens on lookup failure, but those are minor gaps given the tool's simplicity.

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 fully documents the single required parameter, including that restaurant_id is 'the vendor code from search results (e.g. 'p7nl')'. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline score 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 states a clear verb ('Get') and resource ('restaurant details') and enumerates specific fields (address, opening hours, minimum order, delivery info), which distinguishes it from sibling tools like get_menu or search_restaurants. It does not explicitly name alternatives, but the resource scope is precise enough to make the purpose unambiguous.

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

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

The phrase 'specific restaurant' implies the tool is used when you already have a restaurant identifier, but no explicit when-to-use or when-not-to-use guidance is given. It does not mention hunting for alternatives or mention that restaurant_id should come from search_restaurants, leaving usage largely inferred.

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 it delivers: it discloses the provenance precondition for the input, states that all outlets are returned, and enumerates the returned fields (vendor codes, names, delivery fees, distances). It implies a read-only operation via 'List' and 'Returns,' providing solid behavioral context without a safety annotation to lean on.

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 zero redundancy: the first states the operation, the second packs in input provenance, availability condition, return fields, and user purpose. Every clause earns its place and the core verb comes first.

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 one-parameter tool with no output schema, the description is nearly complete: it covers input source, availability condition, return contents, and end-user purpose. Minor gaps remain—no error behavior for an invalid chain_code and no explicit routing when total_outlets == 1—but nothing blocks a correct first call.

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% (chain_code has type and a Jollibee example), so the baseline is 3. The description adds meaning beyond the schema by explaining where the value comes from ('Use the chain_code from search_restaurants results') and under what condition it exists, which a schema alone cannot convey.

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 a specific verb and resource: 'List all outlet branches for a restaurant chain.' It clearly differentiates from siblings like get_restaurant_details and search_restaurants by focusing on branch-level listing and ends with the user-facing goal ('so the user can pick a specific branch').

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

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

The description gives clear context on when to invoke this tool: it explicitly names search_restaurants as the source of chain_code and states the availability condition ('only available when total_outlets > 1'), which implies the exclusion case. However, it does not name an explicit alternative to use when total_outlets == 1.

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 of behavioral disclosure. It discloses the required human-confirmation workflowaine and the payment-method limitation, which are meaningful behavioral constraints. However, it does not mention post-call side effects such as whether the cart is cleared, whether an order confirmation is returned, or whether the order can be canceled.

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?

Three compact sentences carry the action, a mandatory prerequisite, and the key payment constraint without any filler. Critical workflow information is front-loaded immediately after the main verb phrase.

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 two-parameter tool with no output schemahare, the description covers prerequisites, user-confirmation requirements, and payment restrictions. The main gap is the absence of any statement about what happens after the order is placed, such as cart clearing or a returned order identifier, but the essential invocation context is present.

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

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

The input schema already describes both parameters with 100% coverage, including the exact payment_method value and the delivery_instructions purpose. The description reinforces the payment_method constraint but adds little semantic detail beyond what the schema provides, so the 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 opens with a specific verb and resource: 'Place the current cart as an order.' This clearly distinguishes the tool from its sibling preview_order, which only previews rather than finalizes, and from cart-management tools like add_to_cart and remove_from_cart.

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 states the mandatory precondition: call preview_order first and obtain explicit user confirmation before invoking place_order. It also names the only supported payment method and explains why credit card and GCash are not viable alternatives through MCP, giving the agent clear when-to-use and 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?

With no annotations provided, the description carries the full burden. It discloses the return contents (items, totals, delivery address, payment methods) and the critical requirement to obtain user confirmation before place_order. It does not state whether the preview mutates state, but 'preview' implies read-only; the workflow constraint is well covered.

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

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

Two sentences, no wasted words. The primary purpose is stated first, followed by the critical usage directive. The structure is optimal for an agent to quickly parse and act.

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

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

For a zero-parameter tool with no output schema, the description fully covers what an agent needs: the action, the expected return summary, and the required subsequent workflow. 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?

The schema has zero parameters, so the baseline is 4. The description adds no parameter details, which is appropriate since there are none to document. It doesn't need to compensate for any coverage gap.

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

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

The description states a clear verb ('Preview') and resource ('the current cart as an order'), and specifies what the result includes. It differentiates from the sibling place_order by explicitly positioning this as a pre-confirmation step.

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

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

Provides explicit usage guidance: after preview, the agent MUST show the summary and ask for confirmation before calling place_order. It also implies when not to use it (never place an order without confirmation). This is a clear conditional workflow instruction.

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 provided, so description fully discloses interactive login, manual user action, CAPTCHA/MFA handling, automatic token capture, desktop requirement, and headless alternative. 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?

Well-structured with numbered triggers and a clear sequence, but slightly verbose. Every sentence adds value though; front-loads the trigger conditions before procedural details.

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

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

For an interactive auth tool with no output schema, it covers prerequisites, side effects, error conditions, and environment constraints. 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 already documents timeout with default and purpose. Description adds practical guidance ('Increase if the user needs more time'), going slightly beyond the schema's description.

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

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

Clearly states it opens a browser window, intercepts the session token, and updates the server. Distinct from sibling tools (all foodpanda operations) by focusing on authentication.

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 lists two conditions for invocation: session token expired/not configured errors, or user wants to switch accounts. Also provides headless server 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. It mentions the side effect of recalculating totals, which is a useful behavioral trait, but it does not disclose whether removal is destructive to the cart item permanently, whether there are any constraints (e.g., cannot remove after order placed), or whether the operation requires specific cart state. This is a mutation tool with zero annotation coverage, so more detail is needed.

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 waste; the core action and the side effect are front-loaded. A perfect score would require additional detail, but for the scope it is efficient and well-structured.

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 it is a simple one-parameter tool with no output schema, the description covers the essential usage. The only gap is the lack of behavioral context (e.g., error conditions or irreversible nature), but it is not severely incomplete for a straightforward removal operation.

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

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

Schema coverage is 100%, and the description reinforces the parameter's purpose by providing an example ('cart-1'). This adds value beyond the schema by giving a concrete, recognizable format, though it is a single parameter and the schema already explains it well.

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

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

States a specific verb and resource ('Remove an item from the cart') and clarifies the identifier used ('cart item ID'). It is clearly distinguished from siblings like add_to_cart and get_cart, so an agent can select it without ambiguity.

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?

Clear context for when to use: when you need to remove a specific cart item. Does not explicitly exclude alternatives or state when not to use, but in this toolset the purpose is self-evident and sibling names clarify scope.

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 discloses the return structure (id, name, cuisine, rating, delivery fee, etc.), the chain-related fields, and the branching condition for using another tool. It does not explicitly state read-only behavior, but the nature of a search tool implies it; this is a minor omission.

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

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

Two sentences, front-loaded with the main purpose and location/currency, then the return fields and the chain branching. Every sentence earns its place with no filler or repetition.

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

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

Without an output schema, the description explains the return fields and chain logic sufficiently. It does not mention pagination or sorting, but the limit parameter covers result count. For a search tool, this is reasonably complete, though a note on result ordering would push it to 5.

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 parameters are fully documented in the schema. The description adds context about the query examples and the return behavior, but does not materially enhance parameter understanding beyond the schema. 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 states a specific verb (search) and resource (restaurants on foodpanda Hong Kong), adds location and currency context, and enumerates the return fields. It clearly distinguishes itself from siblings like get_restaurant_details and list_outlets by focusing on the search function.

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

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

The description explicitly provides an alternative when total_outlets > 1, directing the agent to use list_outlets with chain_code. This gives clear conditional guidance on tool selection, exceeding the bare minimum.

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