Simvito eSIM

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavior beyond that: the authoritative source (manufacturers' official lists), the brand coverage, the regional exception handling for mainland China/Hong Kong/Macao, and the shape of the verdict (supports_esim / no_esim).

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 tight sentences, front-loaded with the purpose and the concrete example, followed by source scope and the parameter hint. The China/HK/Macao exception list is slightly granular but directly relevant to a common failure mode, so it earns its place.

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

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

Only three parameters, all documented in the schema, an output schema exists so return values need not be described, and annotations carry the safety profile. The description covers the remaining unknowns: source of truth, coverage limits, regional caveats, and when to supply the optional region.

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 would be 3. The description adds a genuine usage rule for purchase_region — supply it when the user mentions where the phone was bought — which the schema only defines syntactically as an ISO code, not as a when-to-supply signal.

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+resource (check whether a phone supports eSIM) and scopes the data sources to manufacturers' official lists for iPhone, Pixel and Galaxy. The example query ('does my iPhone 13 support eSIM?') makes it immediately distinguishable from siblings like search_plans or compare_networks.

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?

Gives a clear triggering context via the example user question and states the conditional rule 'pass purchase_region when the user says where the phone was bought.' It does not name an alternative tool or state when not to use it, but none of the listed siblings overlap, so the routing risk is low.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered by structured data. The description goes beyond that by disclosing what a row contains (each operator, its best generation, how many plans use it, the cheapest one), which is the kind of added context that matters. It does not discuss ordering, coverage gaps, or fallback behavior for destinations with no operators.

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 filler: the purpose and the question patterns come first, the multi-country parameter caveat second. Every clause earns its place and nothing is repeated across sentences.

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

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

With four parameters, one required, full schema coverage, an output schema present, and comprehensive annotations, the remaining burden on the description is purpose and routing, both delivered. An agent has everything needed to decide to call it and which parameters to set.

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 destination, country, currency and locale are already documented in the schema, and the description only restates the country behavior for multi-country destinations. Nothing is added about locale/currency effects beyond what the enum and pattern already specify. Baseline 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?

"Compare the local mobile networks for a destination side by side" gives a specific verb (compare) and resource (mobile networks per destination), and the description enumerates the exact output facets (operator, best generation, plan count, cheapest plan). This clearly separates it from search_plans, which returns plans rather than a network comparison.

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?

Concrete trigger questions ('which network is best in Thailand', 'which eSIM has 5G in Tokyo') make the intended use unambiguous, and the multi-country conditional ('pass country to see that country's operators') tells the agent when to use an optional parameter. It stops short of naming alternatives (search_plans, plan_trip) or stating when not 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds two useful behavioral facts beyond that: fuzzy tolerance for misspellings and acceptance of names in any language, plus the explicit note that no prices are returned. It omits failure behavior when the query matches nothing and any hint about multiple matches.

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, tightly written, with the resource definition front-loaded and the return contract second. The parenthetical example list is long but earns its place by clarifying fuzzy matching. Slightly dense with nested parentheses but no wasted sentences.

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

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

An output schema exists, so the description needn't detail return values, and it correctly limits itself to the one contract that matters: slugs to feed other tools, no prices. For a two-parameter read-only lookup with full schema coverage this is largely complete; missing only what happens on no-match or ambiguous matches.

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 both parameters are already documented, and the description largely restates them (names in any language, ISO codes, misspellings, plus the locale-driven name/link language). It adds the 'cities and islands work too' nuance not obvious from the schema's 'Country, territory or region' wording, but nothing about query length limits or the default locale handling beyond what the schema states.

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+resource (find a destination) and enumerates exactly what counts as a destination: country, region like 'Europe'/'Asia', multi-country plan, plus cities and islands. It also scopes the return value ('destination slugs for the other tools; no prices'), which distinguishes it from search_plans and the checkout tools.

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 makes clear this is the lookup step that feeds 'the other tools' by producing slugs, which implies when to use it before plan_trip or search_plans. It does not name a sibling as an alternative or state exclusions (e.g. what to do when the destination isn't found), so it falls short of explicit when/when-not routing.

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

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

Annotations already declare readOnlyHint and idempotent, so the safety profile is covered; the description adds meaningful context beyond that by stating the user signs in and pays on simvito.com and that nothing is charged here. It also discloses what the result contains — price in the user's currency totalled for the quantity, plus payment methods for that currency.

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 front-loaded sentences with no filler: the first states the action and result contents, the second states the payment boundary. Nothing is redundant or buried.

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 an output schema present, the description need not detail return fields, and it correctly focuses on the link, the payment boundary and the currency/quantity semantics. The only gap is routing guidance among the adjacent checkout siblings, which is not addressed.

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 every parameter including locale, currency, quantity, trip_days and destination is already documented in the schema with defaults, ranges and examples. The description adds only the notion that the price is totalled for the quantity, which is marginal beyond the schema text, so the baseline 3 applies.

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 specific verb and resource — 'get the simvito.com checkout link for a plan' — and names the source tools search_plans and plan_trip, so an agent can tell it apart from generic plan-browsing siblings. It does not differentiate itself from the closely named start_checkout or get_checkout_options, which limits it to a 4.

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

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

Usage is implied by 'for a plan from search_plans or plan_trip', which gives the upstream step but not an explicit when-to-use rule. There is no guidance on when to prefer get_checkout_options or start_checkout instead, so the agent must infer the ordering from sibling names alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered by structured data. The description's only behavior beyond that is the currency-to-payment-methods dependency and the enumeration of supported payment rails, which is genuinely useful but not accompanied by any note on fallback behavior for unsupported countries or precedence when both country and currency are supplied.

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 resource set before the behavioral detail, with no filler. The parenthetical list of payment rails is long but carries informational value; the only minor redundancy is restating the domain (simvito.com checkout) first stated in the title.

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 zero required parameters, an output schema, and full annotation coverage, the description does what is needed: it explains what is returned (default currency plus eligible payment methods) and the defaults applied. The missing piece is orchestration context — when in the checkout flow to call this before start_checkout.

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, but the description adds real meaning on top: it states that country drives the default currency, and that language determines how names and links are rendered — a downstream effect not captured in the schema's 'language of the conversation' wording. It also clarifies that currency governs which payment methods are payable.

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 names the concrete resource set (languages, currencies, payment methods at simvito.com checkout) and states the outcome of passing country or currency, so an agent knows it is a configuration/lookup tool rather than a transactional one. It does not explicitly contrast itself with start_checkout or get_buy_link, which sit closest to it in the sibling list.

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

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

Usage is only implied: 'Pass the buyer's country or currency to get the default currency there' suggests the tool is called ahead of presenting checkout, but there is no explicit when-to-use statement, no guidance on choosing between country and currency, and no mention of how it relates to start_checkout. The agent must infer the call site.

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?

Beyond the annotations, the description discloses a meaningful behavioral trait: the tool waits up to about 25 seconds for payment and eSIM readiness. It also states what is returned and explicitly notes that installation codes are never returned, though it does not discuss authentication or rate limits.

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

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

The description is a single dense sentence, but it is front-loaded with the trigger context and then explains the outcome. The parenthetical examples and return details are useful, though the sentence is somewhat packed.

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 simple two-parameter schema, existing output schema, and read-only annotations, the description is complete enough for correct invocation. It covers trigger timing, wait behavior, return content, and the key exclusion about installation codes.

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 input schema already documents checkout_id and locale fully. The description only indirectly links checkout_id to start_checkout and adds no additional parameter semantics 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?

The description states a specific resource and outcome: it shows whether payment arrived and whether the eSIM is ready after payment through start_checkout. It also names concrete return content (eSIM, install/manage link, Simvito app) and a key limitation, making it distinguishable from siblings like start_checkout.

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 usage context: after the user pays through start_checkout's links, especially when they say 'paid' or ask 'is my eSIM ready?'. It does not explicitly say when not to use this tool or name alternatives such as list_my_esims, so it falls short of full when/when-not 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered; the description earns full credit by adding what annotations cannot: an account-connection prerequisite and the explicit exclusion 'Never returns installation codes', which stops the agent from promising an install code from this call. It also discloses that results are accompanied by off-site simvito.com management links (install, add data), which is real behavioral context for a read 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?

Two sentences, no filler: sentence one front-loads the resource and its returned fields, sentence two carries the two constraints (account required, no installation codes). The parenthetical '(install, add data)' is short and disambiguates what the manage link is for rather than padding.

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 an output schema present, the enumerated return fields are technically redundant, but they orient the agent about what can be promised to a user; annotations cover the safety profile and the auth prerequisite is stated. The only minor gap is behavior in the failure/empty case (no connected account, zero eSIMs), which is left unstated but is readily inferable from 'Requires connecting a Simvito account'.

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 is a single optional parameter (locale) and schema description coverage is 100%, with the enum listing all supported language codes and the schema text explaining that names and links follow the locale. The description adds no parameter-level meaning beyond that, so the 3 baseline for a fully documented schema is the correct score.

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 the eSIMs in the user's connected Simvito account') and enumerates exactly what each entry contains: destination, plan, status, installed state, data left, expiry and a management link. That account-scoped read is unmistakably different from every sibling (search_plans, find_destination, start_checkout and the rest are all pre-purchase plan tools), so an agent can route without opening a schema.

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 hard precondition – 'Requires connecting a Simvito account' – which is the main thing that can make this call fail or be inappropriate, and it implicitly scopes usage to the user's own existing eSIMs rather than plan shopping. It does not name a sibling alternative or an explicit when-not condition, but none of the listed siblings offers overlapping functionality, so nothing important is left ambiguous.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's real contribution is the selection algorithm: cheapest plan that covers each stop's days at the daily data need. That is genuine behavioral context an agent would not get from the annotations. It omits the 8-stop cap and any statement about how ties or uncovered routes are handled.

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 dense sentence that front-loads the multi-country scenario and immediately follows with a concrete example. Every clause carries information, though the nested comparison logic reads as slightly run-on.

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 an output schema present and rich annotations, the description only needs to explain inputs and selection logic, which it largely does. Remaining gaps are minor: the maxItems=8 trip limit and what happens when no regional plan covers all stops are not mentioned.

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 75%, so the schema documents locale, currency, and data_gb_per_day itself. The description nevertheless adds meaning to the stops array by illustrating the country/days pairing and tying 'daily data need' to the per-day data parameter, which goes beyond the schema text.

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 the job concretely: compare one regional plan covering every stop against a separate plan per country, choosing the cheapest option for each stop's days at the given daily data need. The example (Japan 7 days, then Korea 5 days) makes the resource unambiguous. It does not differentiate from the sibling search_plans, so it stops 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 multi-country scenario and worked example imply when the tool applies, but there is no explicit guidance such as 'use this instead of search_plans for single-country trips' or any stated exclusions. The agent must infer the boundary from the sibling name alone.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — it does so by disclosing the result cap ('Up to 5 plans'), currency conversion into the user's currency, and the substantive fields returned including coverage type, data-exhaustion behavior, and hotspot/top-up support. It does not state latency, ranking/ordering logic, or what an empty result means.

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 the purpose and scope front-loaded, followed by a compact inventory of what comes back. The second sentence is a long comma-chained list but every item is informative rather than padding.

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 an output schema, full parameter coverage, and rich annotations, most burden is already carried by structured fields. The description fills the remaining gap by naming the plan cap and the currency behavior, though it could have said how results are ordered or what happens when no plan matches.

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 reinforces a few parameters — destination as a place, trip-length framing, and price in the user's currency — but adds nothing about locale, plan_type, or data_gb semantics beyond what the schema already specifies.

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 ('Find travel eSIM data plans') and immediately scopes it to one destination plus a trip length, with concrete query examples. That is enough to separate it from siblings like compare_networks or find_destination without opening a schema.

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 scope clause ('for one destination and trip length') implies when the tool applies, and the examples model the expected input shape. However it never names an alternative or an exclusion, so the agent must infer for itself that destination resolution belongs to find_destination and network comparison to compare_networks.

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 a non-read-only, non-destructive, non-idempotent, open-world write, and the description adds meaningful behavior on top: nothing is charged until payment on the link, links must be passed on 'exactly as returned', availability of PayPal may vary per order, and confirmations come only from a prior confirmation_required result after the user saw each text. It does not warn that repeated calls create separate orders despite idempotentHint=false, which is the one behavioral gap.

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

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

The trigger condition is front-loaded and the important constraint (no charge until payment) sits early. The second sentence is long and packs return details, input shapes, and the fallback tool into one block, which is dense but almost entirely load-bearing.

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 9-parameter transactional tool with an output schema, the description covers preconditions, charge timing, input shape alternatives, and language/currency effects on returned names and links. The only omission an agent could stumble on is the absence of a retry/idempotency caution for this non-idempotent order-placement 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%, so the baseline is 3, but the description adds semantics the schema lacks: items and plan_id+quantity are mutually exclusive input styles, items is capped at 5 plans / 10 eSIMs in total, and expected_unit_amount applies only after a price_changed result. The quantity 'one per traveller' intent and currency dependence are also reinforced in prose.

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 outcome: 'places the order on their account and returns two payment links', then enumerates what the links support (cards, Apple Pay, Google Pay, local wallets, PayPal) and what comes back (total, discount, order number). This is clearly distinguishable from sibling get_buy_link, which is named as the fallback for unconnected accounts.

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?

Gives an explicit trigger ('When the user decides to buy'), a precondition ('their Simvito account is connected'), and a named alternative for the negative case ('If the account isn't connected, use get_buy_link instead'). It also directs the agent to obtain plans from search_plans or plan_trip, so the upstream tool chain is clear.

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