AgentRoam

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

Annotations flag this as a non-read-only, destructive, open-world operation, and the description adds substantial context beyond that: a 30-minute expiry window, that the purchased code/QR is emailed by Cryptorefills rather than returned, and that payment is crypto to a returned wallet address. These are exactly the behavioral facts an agent needs before committing to an irreversible purchase.

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 its prerequisite, then outputs, then the delivery caveat. No filler or repetition of the tool name.

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?

Covers the full call contract: prerequisite token, approval gate, expiry, payment target, and where the actual goods are delivered. Although an output schema exists, the description's summary of return values is accurate and the crucial 'code is emailed, not returned' disclosure is not something the schema conveys.

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% and both parameters are documented in the schema (including the FULLNAME_MISSING retry condition for full_name). The description adds only marginal provenance for confirm_token ('after user approval') beyond the schema's 'returned by validate_order', 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?

States a specific verb+resource ('Create the real order') and distinguishes itself from the sibling validate_order by framing this as the 'real' order that follows validation. An agent can tell immediately that this is the committing step, not a dry run.

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 (confirm_token from validate_order) and the gating condition (after user approval), which routes the agent through the correct sequence. It stops short of stating when NOT to use it (e.g., token expired or missing), leaving a small inference gap.

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 establish the safe read-only, closed-world profile, so the bar is lower; the description still adds real behavior: the data is live ('currently available', 'includes live totals') and it instructs the agent to report the returned totals rather than a memorized count. That freshness/staleness warning is genuinely beyond the annotations, though no rate limit or caching behavior is mentioned.

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 padding, with the scope stated first and the live-totals caveat second. Every clause 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?

An output schema exists, so return structure need not be explained, and there are no parameters to document. The description supplies the conceptual payload (coin × network matrix, exact network strings, live totals) and is sufficient to call the tool correctly; the only shortfall is the absent explicit pointer to when this beats get_currencies.

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, which is the baseline-4 case per the rubric. The description correctly characterizes the query as unfiltered and full-matrix, so nothing about inputs is left ambiguous.

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 concretely names the resource and scope: 'every supported coin × network combination currently available', plus the exact network strings needed. It is clearly not get_currencies or get_price, though it never explicitly names the sibling it contrasts with (e.g. currencies vs. networks), so it stops just short of the top band.

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?

'with the exact network strings orders require' implies this is the lookup you perform before building an order, which is useful implied guidance. However there is no explicit when-to-use statement, no prerequisite, and no exclusion against alternatives such as get_currencies, leaving routing to inference.

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 the explicit 'Never creates an order' note and adds that prices are 'live', implying volatile, non-cacheable values. It stops short of describing rate limits, caching, or what a price object contains, but the safety profile is well covered jointly.

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 core capability, followed by the coin enumeration and the read-only guarantee. No filler; the long coin list earns its place because the schema carries no enum constraints.

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 the annotations carry the safety profile. The description covers coins and cross-references sibling tools, but for a 7-required-parameter tool it says nothing about grouping semantics (dynamic-range vs fixed denomination, how amount_usd and denomination_label interact), leaving a small gap.

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 by enumerating valid payment coins (USDT, USDC, BTC incl. Lightning, ETH, SOL, DAI, PYUSD, LTC, TRX, TON, DOGE, SUI) when the schema has zero enums, and points to get_payment_methods as the authoritative source. It does not clarify the dynamic/amount_usd interplay, which limits it below 5.

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 ('Live crypto price for one product/denomination') and adds explicit scope ('Never creates an order'), which separates it from create_order and purchase_wizard. An agent can identify this as a read-only pricing lookup 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?

It routes the agent to get_payment_methods for the current coin list and rules out order creation, which is useful. However, it never says when to call get_price versus, say, list_products or get_currencies, nor what prerequisites (e.g., needing a brand_slug from search_products) gate a successful call. Usage is implied rather than stated.

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 useful scale/scope context (500+ US brands, 100+ countries) and reaffirms it never creates an order, but discloses nothing about auth, rate limits, or result shape.

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 tight sentence with the catalog scope front-loaded and the read-only reassurance appended, with 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 no explanation, and the read-only nature is covered. However, for a catalog-browsing tool whose 'kind' parameter has no enum, the description should enumerate or point to the accepted product types; instead the agent must guess valid values.

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

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

Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description's mention of gift cards vs mobile top-up carriers loosely hints at the product categories that 'kind' filters, but with no enum on 'kind' it gives no explicit allowed values.

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 concrete verb and resource ('Browse all available brands/carriers for a country') and scopes it to a country, so an agent knows exactly what it returns. It implies a distinction from list_products/search_products by calling out brands/carriers, but it does not explicitly contrast itself with those 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?

There is no explicit statement of when to use this tool versus list_products, search_products, or list_esim_plans, nor any prerequisites. 'Never creates an order' is a safety reassurance, not usage routing, so the agent must infer the discovery use case on its own.

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, non-destructive, openWorld), so the description adds real value by disclosing the interactive plan-picker widget render and the fact that no order is created as a side effect. This is meaningful UI/behavior context an agent could not infer from the annotations or schema.

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

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

Two dense sentences with the highest-value signal ('PREFERRED for any eSIM request') front-loaded, followed by scope, output hint, and the negative constraint. 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 not be spelled out; the description still gives a useful output hint ('USD prices and crypto amounts'). Combined with the safety annotations and full schema coverage, an agent has everything needed to select and call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates destination conventions ('eu', 'ww') that the schema already documents and adds only the general coverage claim, so it does not meaningfully extend parameter understanding.

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 ('live eSIM data plans for a destination') with coverage scope ('110+ countries, plus "eu" and "ww"'). It is clearly distinguishable from siblings like create_order and purchase_wizard because it explicitly says it lists rather than transacts.

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?

'PREFERRED for any eSIM request' gives a strong positive routing signal, and 'Never creates an order by itself' tells the agent when this is NOT the purchasing step. It stops short of naming the actual alternative (create_order/purchase_wizard) for completing a purchase, so the routing is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description still adds real value beyond that: it clarifies that products are 'live' (pricing is fetched at call time) and reinforces 'Never creates an order', which disambiguates it from create_order/purchase_wizard.

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 with purpose first, then downstream use, then the exclusion, then the non-mutation guarantee. No filler and nothing is buried at the end.

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 described, and the description still usefully frames the labels as inputs to get_price/validate_order. The only gap is that neither the description nor the schema explains the required country_code, which is minor in this otherwise complete definition.

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%; coin has a default note and brand_slug's source is documented, while country_code is bare. The description adds that prices come back 'in the chosen coin', which gives the coin parameter meaning, but it does not explain country_code's role, so it only partially compensates for the 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?

States a specific verb and resource ('List a brand's live products/denominations') and immediately scopes it by coin pricing and by brand. It explicitly distinguishes itself from list_esim_plans, so an agent can separate it from its closest sibling 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?

Gives concrete downstream usage ('exact labels to use with get_price/validate_order') and names the alternative tool with its condition ('for eSIM use list_esim_plans instead'). This is explicit when-to-use and when-to-use-something-else 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 declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, and the description goes well beyond them: it discloses the stateful session protocol, the 'complete' terminal status, and that the final 'confirm' answer creates a REAL order requiring explicit user approval. That is exactly the extra behavior an agent needs to avoid an accidental purchase.

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 dense sentences, front-loaded with the identity of the tool and the preferred alternative, then the stateful protocol, then the destructive-action warning. No filler and nothing important 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?

An output schema exists, so return values need no explanation, yet the description still surfaces the key status value ('complete') that governs the loop. Combined with the routing guidance and approval gate, an agent has everything needed to invoke it correctly and safely.

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

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

Schema coverage is 100%, so all three params are documented structurally. The description adds lifecycle meaning the schema cannot: session_token is omitted on the first call because a session is minted, the first call takes empty arguments, and action="back" rewinds a step. It does not, however, add answer-format or validation detail.

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 and scope: a text-only fallback purchase flow for clients without widget support. It names the sibling tools (list_esim_plans / list_products + validate_order + create_order) that should be preferred in ChatGPT, so an agent can distinguish it from all ten 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?

Explicitly states when to use it (no widget support), when not to (ChatGPT — use the listing/validation/creation siblings instead), and the calling protocol (repeat with the same session_token, one question at a time, empty arguments first). It also gates the terminal step behind explicit user approval.

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

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

With readOnlyHint=true and destructiveHint=false already declared, the description reinforces the read-only profile with 'Never creates an order' and adds a useful behavioral fact not in the annotations: the output is product handles destined for pricing/validation. It does not mention pagination or rate limits, which keeps it out of 5 territory.

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 densely packed sentences with the search verb and catalog scope front-loaded, followed immediately by output usage and the non-mutation guarantee. The long parenthetical enumerations are informative rather than wasteful, though they make the first sentence heavy.

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, and annotations cover the safety profile. The description supplies the catalog scope and the workflow hand-off to get_price/validate_order, leaving only the sibling-boundary question (search vs. list) unanswered.

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 three parameters are already documented and the baseline is 3. The parenthetical details ('500+ US brands', '110+ destinations incl. Europe/Global region plans', '100+ countries') hint at the vocabulary the query/kind/country values should use, adding modest value beyond the schema.

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

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

The description names a specific verb (Search) and resource (the AgentRoam travel-crypto catalog), then enumerates its scope: gift cards, eSIM data plans, and mobile top-ups. It distinguishes itself from get_price/validate_order by stating the returned handles feed those tools, but it never clarifies how it differs from the closely named sibling list_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?

It tells the agent the downstream purpose ('Returns product handles for get_price/validate_order') and rules out a competing action ('Never creates an order'). That is clear context for when to reach for this tool, though it never states when to prefer it over list_products, list_brands, or list_esim_plans.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, but the description adds genuinely new behavioral facts: a one-time token is minted with a 10-minute validity window, no order or funds are committed, and the output is a user-facing summary requiring approval. This also explains why readOnlyHint is false for a 'dry-run' (token minting is a side effect), preventing a misleading read-only interpretation.

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 short sentences, zero filler, and the most decision-critical facts (dry-run, token, must show to user before create_order, no side effects) are front-loaded. Every clause carries information an agent needs to act 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?

With an output schema present, the description need not enumerate return fields, yet it still characterizes the return as a human-readable summary that must be surfaced to the user. Combined with the token lifetime and the no-commitment guarantee, an agent has everything needed for this 9-parameter, 8-required step in the ordering flow.

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% and every field carries its own explanation, including cross-tool provenance cues like 'brandSlug from search_products' and 'Exact network string from get_price/networks'. The description adds no parameter-level detail of its own, so the baseline of 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 names a specific operation (dry-run an order) and its distinctive output (a one-time confirm_token valid 10 minutes), which is exactly what separates it from create_order. It also states the explicit negative boundary: it does NOT create the order or reserve funds. An agent can distinguish this from every sibling in the list 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?

It gives a clear workflow rule: you MUST show the returned summary to the user for approval before calling create_order, which effectively names the alternative tool and the condition that selects it. What is missing is guidance on when validation can be skipped or re-run (e.g., after the token expires or inputs change), so it falls just short of fully explicit when/when-not coverage.

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