AgentRoam

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds genuinely new behavior: it returns the payment wallet address, exact crypto amount, a 30-minute expiry, and a status URL, and critically discloses that the purchased code/QR is emailed by Cryptorefills and never returned here. That last point is a real fulfillment gotcha an agent would otherwise not know.

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?

Four tight sentences with zero waste; the dependency and the return/fulfillment facts are front-loaded in a logical order. Every sentence carries information an agent needs.

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 destructive, open-world mutation with only one required parameter, the description covers the prerequisite, the return payload, the expiry window, and the out-of-band delivery of the purchased code. Even though an output schema exists, the email-not-returned warning is essential context that is complete 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%, so the schema already documents both parameters, including that confirm_token comes from validate_order and its 10-minute validity and the FULLNAME_MISSING condition on full_name. The description largely restates the token's origin rather than adding syntax or format detail, so 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?

States a specific verb+resource ("Creates the real order") and implicitly contrasts with the sibling validate_order by calling this the real, final order versus the validation step. An agent can distinguish it from purchase_wizard and validate_order 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?

Explicitly names the prerequisite (a confirm_token minted by validate_order) and the conditional case for full_name after FULLNAME_MISSING. It gives clear context for when the tool applies, though it never states an explicit when-not-to-use or names a competing tool for the read-only path.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds the mild note that the response reflects the 'current set,' implying the list is dynamic rather than static, but says nothing about caching or freshness guarantees — modest added value beyond the annotations.

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 preamble waste. The parenthetical about the current set is borderline redundant with 'all supported,' but it carries a small amount of meaning and costs little.

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 need not explain the return payload, and with no input parameters there is little else to specify. The only real gap is the missing distinction from get_payment_methods, a minor routing concern for a simple list tool.

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

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

The tool takes zero parameters, so the schema has nothing to document and there is no parameter semantics for the description to compensate for. The baseline of 4 for a no-parameter tool 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 states a specific verb and resource: 'List all supported payment cryptocurrencies.' An agent can tell it retrieves the coin set. However, it never distinguishes itself from the closely related sibling get_payment_methods, so the sibling differentiation that would earn a 5 is absent.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The nearest sibling, get_payment_methods, is left for the agent to disambiguate on its own, which is exactly the case where routing guidance would help.

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=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds real value beyond them by disclosing the terminal states (CANCELED/EXPIRED) and the intermediate PARTIAL state, which tells the agent that multiple polls are expected and defines a stop condition. It stops short of stating rate limits or how to distinguish a failed token from a not-yet-created order.

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, zero filler. The state sequence and the prerequisite are both front-loaded and each clause carries information an agent needs to call this correctly.

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 return-value explanation is unnecessary, and the state machine plus token prerequisite gives the agent what it needs to invoke and interpret. The only remaining gap is the undocumented external_order_id, which slightly undercuts completeness for a two-parameter required 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 50%: status_token is documented and the description reinforces its origin ('from create_order'), but external_order_id is undocumented in both the schema and the description. Baseline 3 is appropriate since the description adds origin context for one parameter without compensating for the 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?

States a specific verb ('Poll') and resource ('order state'), and immediately enumerates the exact state machine it reports (WAITING_FOR_PAYMENT → PARTIAL → COMPLETED, or CANCELED/EXPIRED). Combined with the dependency pointer to create_order, an agent can distinguish this from validate_order and the read-only catalog siblings without opening any 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 word 'Poll' implies the repeat-call pattern, and the dependency 'Requires the status_token from create_order' tells the agent this is the follow-up step to order creation. It does not, however, state when to prefer this over validate_order or how often to poll, so one condition remains 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?

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the data is live ('currently available', 'live totals') and the returned network strings are the exact values orders expect, which matters for downstream calls.

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, with the core identity (full coin × network matrix) front-loaded and the practical detail about exact network strings placed second. Nothing repeats the name or 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 no parameters, an output schema present, and annotations covering the safety profile, the description only needs to establish what the list contains — which it does. It stops short of noting ordering, caching, or when the matrix changes, but nothing required for correct invocation 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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is 100% and the empty object schema matches the description's no-argument framing.

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 a specific resource (coin × network combinations) and its distinguishing property: it returns the exact network strings orders require. That clearly separates it from get_currencies, but it never names or contrasts with that sibling explicitly.

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: by saying these are the strings 'orders require', an agent can infer this should be consulted before create_order. There is no explicit when-to-use statement, no exclusions, and no pointer to alternatives such as get_currencies.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that pricing is live and that no order is created, which is useful reinforcement, but says nothing about rate limits, caching, or how often prices change.

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, followed by useful scope detail. The coin enumeration is somewhat dense but earns its place as the only source of valid coin values, since the schema has no enum.

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, return values need no explanation, and all parameter provenance is in the schema. The description covers scope, supported coins, and the non-mutating nature, leaving only prerequisite ordering (search_products before this call) to inference.

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 all seven required parameters are already documented with sources (brandSlug from search_products, exact network string, etc.). The description adds the list of supported payment coins, which is mildly useful given there are no enums, but it does not add syntax or format detail 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?

States a specific verb+resource: returns the live crypto price for one product/denomination. It distinguishes itself from get_payment_methods by naming it as the source of the current coin set, but it does not differentiate from get_currencies, which an agent could plausibly confuse it with.

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 routing to get_payment_methods for the current coin set is genuine guidance, and 'Creates no order' implicitly contrasts with create_order. However, there is no explicit when-to-use condition (e.g. must call search_products first to obtain brand_slug/country_code) and no statement of when not 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the agent knows this is a safe read. "Creates no order" reinforces that in domain terms, but the description adds little beyond this and says nothing about result size, pagination, or coverage 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?

Single sentence, front-loaded with the action and resource, with the no-side-effect reassurance tacked on the end. The catalog-size details ("500+ US brands", "100+ countries") are mildly promotional but cheap and clarifying.

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 read tool with full schema coverage, an output schema, and clear read-only annotations, the description supplies enough to select and invoke it correctly. Missing only alternative-routing guidance against sibling list/search tools.

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 both parameters are already documented (country_code as ISO code, kind as a product-type filter). The description adds no additional syntax, allowed values, or defaults for `kind`, so 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?

States a specific verb (list/browse) and resource (brands/carriers) scoped to a country, and clarifies the two catalogs covered (gift cards, mobile top-up). It is clearly distinct from transactional siblings like create_order, though it does not explicitly differentiate itself from list_products or search_products.

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?

"Browse all available brands/carriers for a country" implies the context (browsing a catalog by country) and the required input is obvious from the schema, but there is no explicit when-to-use vs when-not guidance and no named alternative (e.g., list_products/search_products) for narrower lookups.

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, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuinely new context: live pricing, the widget-rendered interactive picker in supporting clients, and the explicit guarantee that no order is created — all beyond what annotations convey.

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

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

Two tight sentences with the core scope front-loaded and the non-mutating reassurance last. No filler, every clause carries information.

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 return values need not be explained; the description still usefully flags the widget rendering behavior. For a simple two-param read tool, nothing an agent needs to invoke it correctly 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 coverage is 100%, so both parameters are already fully documented, including the "eu"/"ww" destination values. The description restates the destination and pricing scope but adds no syntax or format detail beyond the schema, making the baseline 3 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?

States a specific verb+resource (list live eSIM data plans) and immediately scopes it by destination coverage (110+ countries, "eu", "ww") with pricing in USD and crypto. An agent can distinguish this from get_price, search_products, and create_order without opening the 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?

Usage is implied by the destination-scoped description and the closing note "Creates no order by itself," which steers the agent away from the purchase path. However, no alternative tool is named and there is no explicit when-to-use/when-not guidance relative to get_price or purchase_wizard.

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=true and destructiveHint=false; the description reinforces this with 'Creates no order' and adds useful cross-tool context that the returned labels are the exact ones the pricing/order tools expect. It does not mention pagination or how live pricing is fetched, but against rich annotations the added context is solid.

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-loaded with the core resource and scope, with the sibling exclusion in a parenthetical and the safety note last. 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?

An output schema exists, so return values need no elaboration, and the description covers the key sibling routing plus required inputs implicitly. The only gap is the undocumented country_code, which neither schema nor description explains.

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 67%: the schema already documents coin (default USDC) and brand_slug's source. The description adds the semantic that coin selects live pricing, but leaves country_code entirely unexplained in both places. Baseline 3 is appropriate given the schema carries most of the load.

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 (List) and resource (a brand's live products/denominations with prices in a chosen coin), and explicitly carves out the eSIM case to sibling list_esim_plans. An agent can distinguish this from search_products/list_brands without reading further.

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 clear context: use it to get denomination labels that the pricing and order tools expect, and routes eSIM destinations elsewhere. However, it never states when NOT to use it beyond the eSIM exclusion, nor any prerequisite ordering against get_price/create_order.

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, readOnlyHint=false and openWorldHint=true, but the description adds operational behavior the annotations cannot convey: the multi-call session loop, session-token reuse, the empty first call, and the fact that the final 'confirm' answer creates a real order. That is genuinely value-adding context beyond structured fields.

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 dense sentences with no filler: the first establishes scope and audience, the second establishes the call protocol and the destructive outcome. Front-loaded and every clause 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?

Because an output schema exists, return values needn't be described, and the description correctly references the terminal 'complete' status instead. It leaves minor gaps around handling of expired/invalid sessions or bad answers, but is otherwise complete for a stateful wizard 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 description coverage is 100%, so all three parameters (action, answer, session_token) are already documented, including 'back' and 'omit on first call'. The description only lightly reinforces these (same session_token across calls, empty first call), which is the expected baseline 3 when 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 specific tool type (stateful text-only purchase flow) and scopes it to clients without widget support, which implicitly separates it from the direct create_order sibling. However, it never names an alternative or explicitly contrasts itself with the other order tools, so the differentiation is inferred rather than stated.

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 gives a clear invocation protocol: repeat calls with the same session_token, one question at a time, until status is complete, and the first call takes empty arguments. That is strong when-to-use guidance, but it stops short of naming a preferred alternative (e.g. create_order) for clients that do have widget/direct support.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by naming the return shape (product handles as brandSlug + countryCode) and explicitly reassuring 'Creates no order', which is useful domain context for an agent deciding whether this is a safe exploratory call.

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?

Front-loaded with the search verb and catalog scope, followed by a compact return-value and side-effect sentence. Dense but every clause carries information; 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?

Given full schema coverage, an output schema, and read-only annotations, the description supplies the catalog scope, the return format, and the no-side-effect guarantee. It is complete enough to call correctly, with only the when-to-use routing left implicit.

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 all three parameters (kind, query, country) are already documented in the schema; baseline is 3. The description reinforces the query domain (brand, carrier, destination) but adds no syntax or filtering detail 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?

States a specific verb (search) and resource (the AgentRoam travel-crypto catalog) and enumerates the three product families it covers with concrete examples. It is clearly distinguishable from siblings like list_products and list_brands, which enumerate rather than query.

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 downstream usage by saying the returned handles are 'used by the pricing and order tools', but it never states when to prefer this over list_products or list_brands, nor any precondition for a search. Usage is inferable but not explicit.

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

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

Adds substantial context beyond the annotations: a 10-minute token validity window, single-use semantics, and the explicit assurance that no order is created and no funds are reserved. Annotations only give the coarse readOnly/destructive profile, so this detail is genuinely additive.

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 action and token output, then the no-side-effect guarantee. Nothing is redundant with the title or schema.

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 full parameter coverage, the description only needs to carry behavior and routing, which it does. An agent has everything needed to call it correctly and know what it returns.

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 all 9 parameters (including the conditional phone requirement and the enum-like network string) are already documented. The description adds no parameter-level meaning, which matches the baseline of 3 when 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?

States a specific verb and resource ('Dry-run an order and mint a one-time confirm_token'), and its scope is immediately distinguishable from the sibling create_order, which it explicitly names as the consumer of the token.

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?

Clearly establishes this as the pre-step for create_order ('the one-time token that create_order requires') and rules out side effects ('Creates no order and reserves no funds'), but never states when it should be skipped or what to do if validation fails.

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