AgentRoam

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

Goes beyond the annotations by disclosing the actual side-effect boundary: the purchased code/QR is emailed and 'never returned here'. It also reveals the wallet address, exact crypto amount, and 30-minute expiry, giving the agent realistic expectations about the result of invoking this mutation.

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

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

Three dense sentences with no filler: action and precondition first, then return values, then the email caveat. Each sentence earns its place and is front-loaded with the most important 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?

Given the output schema already captures return values, the description adds the critical non-schema context: email delivery, non-return of code/QR, and the approval sequence. It is complete for an agent deciding whether and how to call this tool.

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

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

Schema description coverage is 100%, and the description largely restates what the schema already says about confirm_token and full_name. It reinforces that confirm_token is one-time and originates from validate_order, but adds little new meaning 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 and resource: 'Create the real order', clearly distinguishing from validate_order by requiring confirm_token and 'after user approval'. The description also specifies what it returns, so an agent can select it unambiguously.

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 establishes the precondition: confirm_token comes from validate_order and user approval must already be obtained. It does not name an alternative like purchase_wizard, but the sequence is clear enough to route the agent correctly.

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, covering the safety profile. The description adds the nuance that the response carries the 'current set', implying dynamic data that may change over time. However, it does not disclose additional behavioral details like caching implications or possible empty responses, though the annotation coverage reduces the burden.

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

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

A single sentence conveys the action, resource, and a behavioral nuance ('current set') without redundant phrases. The structure front-loads the verb and resource, and the parenthetical adds value rather than fluff. Nothing in the description is extraneous.

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 no-parameter list tool, the description is sufficient: it states the purpose and the dynamic nature of the data, and the presence of an output schema covers return-value details. It does not mention authentication or pagination, but annotations and schema richness mitigate these gaps. A 5 would require explicit integration guidance with sibling tools, which is absent, so 4 is appropriate.

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

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

The tool has zero parameters and an empty input schema, so there are no parameter semantics to clarify. The description correctly omits parameter information, and the schema trivially covers the parameter surface. A baseline of 4 is appropriate for a parameterless tool.

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

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

The description uses the explicit verb 'List' with the resource 'supported payment cryptocurrencies', clearly distinguishing it from sibling tools like get_payment_methods or list_products. The parenthetical about the response carrying the current set further clarifies the tool's intent without ambiguity.

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

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

The description implies use whenever the current set of payment cryptocurrencies is needed, but it does not name alternative tools or state when not to use this tool. Sibling tools like get_payment_methods and get_price suggest nearby alternatives, but no differentiation or exclusion criteria are provided, leaving the decision 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, so the description's lack of explicit 'read-only' mention is fine. The description adds the state transition list, which is behavioral context beyond annotations. It does not mention rate limits or return format, but the output schema covers return values. With annotations covering safety, this is a solid 4.

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

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

The description is one sentence, front-loaded with the state transitions and the requirement for the token. Every word adds value; no fluff.

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

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

The tool is simple with only 2 required parameters decentralized over annotations and output schema. The description provides the crucial constraint (status_token) and state transitions. Nothing essential is missing for an agent to call this 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 coverage is 50%, and the description adds meaning to status_token by explaining it comes from create_order (beyond the schema's 'statusToken'). However, external_order_id has no description in the schema and the description doesn't clarify its role, so the description partially compensates but doesn't fill all gaps.

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

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

The description clearly states a specific verb ('Poll') and resource ('order state'), enumerates the state transitions, and mentions the required token. It differentiates from siblings like create_order and validate_order by focusing on polling status.

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 explicitly states that the tool requires the status_token from create_order, which is a clear prerequisite. It implies usage for checking order state after creation, but does not explicitly say when to use it instead of validate_order. The context is generally clear.

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, so safety is covered. The description adds that the response includes live totals and that agents should report them rather than using memorized counts, which is useful behavioral context. There's a possible contradiction: openWorldHint=false but the description says 'currently available' implying a dynamic set, but that's not a direct contradiction. The description doesn't mention pagination or rate limits, but given the matrix scope, it's acceptable.

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 purpose and key detail about network strings. The instruction about reporting live totals is included without waste. Excellent conciseness.

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 tool has no parameters, an output schema exists (though not provided in detail here, it's indicated), and the annotations cover safety, the description is sufficient. It tells the agent what data is returned and how to use it. The only minor gap is not mentioning if there's any caching behavior or timing, but the warning against memorized counts addresses that. The description is complete for a no-arg 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 has zero parameters, so schema coverage is 100% (no params to cover). The description adds value by explaining the meaning of the response: every coin × network combination and exact network strings. It also emphasizes reporting live totals. With no parameters, the baseline for parameter semantics is 4 per instructions, and the description enhances that with response semantics.

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

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

The description clearly states the tool provides a full payment matrix of coin × network combinations with exact network strings needed for orders. This distinguishes it from siblings like get_currencies which lists currencies and create_order which places orders. However, the name 'get_payment_methods' is broad but the description sharpens it to the specific matrix.

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 this is used to retrieve supported payment methods and exact network strings required by orders. It mentions 'report those, never a memorized count' which warns against using cached values, implying usage is to fetch live data. It does not explicitly state when not to use it or contrast with siblings like get_currencies, though the boundary is fairly clear.

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, and the description reinforces this with 'Never creates an order.' It adds that the price is 'live' and that the coin list is dynamic (pointing to get_payment_methods), which is useful context. It does not mention rate limits or authentication, but given annotations cover safety, this is adequate.

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 sentences, front-loaded with the core purpose. Each sentence earns its place — the coin/network list and the read-only caveat are directly useful to an agent deciding to call this tool. No wasted words.

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 tool has an output schema and detailed parameter descriptions, the description covers what's needed: purpose, read-only nature, and coin-list source. It could mention the typical workflow (e.g., 'call search_products first'), but the schema hints at that. For a price query tool, this is sufficient.

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 has 100% description coverage for all 7 parameters, each with a clear description. The tool description adds value by clarifying that the coin list is not exhaustive ('Payment coins include... call get_payment_methods') and that dynamic ranges exist (explaining fixed vs dynamic denominations). This enriches the coin and dynamic parameters 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 opens with 'Live crypto price for one product/denomination,' a specific verb and resource. It clearly differentiates from sibling tools like create_order by adding 'Never creates an order,' and from listing tools. The purpose is unambiguous.

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

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

It provides clear context: it's for getting a live price, and explicitly tells the agent to call get_payment_methods for the current coin list, which is a related tool. It doesn't explicitly state when to use it versus alternatives, but the read-only nature and the pointer to get_payment_methods give practical guidance. No explicit exclusions beyond never creating an 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 carry readOnlyHint=true and destructiveHint=false; the description reinforces and extends this with 'Never creates an order' and adds concrete scope details like 500+ US brands and 100+ countries. This is useful context beyond the annotations without contradiction.

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 short sentences with the purpose front-loaded. The safety clarification 'Never creates an order' earns its place and every clause adds useful information without repetition.

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

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

For a simple two-parameter browse tool with 100% schema coverage, clear annotations, and an output schema present, the description provides everything needed to invoke it correctly. No gaps for callers.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by giving examples of product types ('gift cards' and 'mobile top-up carriers') that map to the kind parameter, and 'for a country' reinforces the country_code parameter.

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

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

States the verb 'Browse' and resource 'brands/carriers for a country,' and gives concrete categories (gift cards, mobile top-up carriers). The line 'Never creates an order' explicitly separates it from order-related 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?

Clearly signals when to use it: when browsing brands/carriers for a country. The 'Never creates an order' note provides an explicit when-not that disambiguates from order tools, though it does not name an alternative like search_products.

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 read-only and non-destructive behavior, and the description adds meaningful context beyond them: live pricing, widget rendering, and the guarantee that no order is created by the tool itself. No contradiction with 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?

Three dense sentences: the first front-loads the purpose and preferred status, the second adds the widget behavior, and the third clarifies the no-order boundary. Every sentence earns its place with no filler.

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

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

Given the output schema covers return shape and annotations cover safety, the description provides the remaining necessary context: destination scope, live pricing, widget interaction, and no-order guarantee. An agent has enough to select and invoke this tool 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 adds color around destination coverage and USD/crypto amounts, but it mostly restates the schema's destination and coin semantics rather than revealing new parameter behavior.

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 (live eSIM data plans), a destination scope, and a distinctive presentation behavior (interactive plan-picker widget). It also separates itself from order-related siblings by stating 'Never creates an order by itself.'

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' is an explicit usage directive, and 'Never creates an order by itself' warns against using it when order creation is the goal. It does not explicitly name alternative sibling tools like create_order, so it stops short of a full when-not pitch.

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 carry readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description reinforces this with 'Never creates an order' and adds that prices are live and in the chosen coin — useful behavioral context beyond the annotations, but it doesn't describe pagination or return mechanics.

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 primary purpose and scope are front-loaded, followed by the key routing and safety clarifications. 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?

An output schema exists, so return values need no prose explanation, and annotations cover the safety profile. The description provides purpose, exclusions, and downstream compatibility. Minor gap: no mention of result volume or pagination, but given the output schema, the definition is essentially 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 67% (coin and brand_slug described, country_code left bare). The description adds downstream meaning by tying the coin selection to output labels consumable by get_price/validate_order, complementing the schema. It doesn't compensate for the undocumented country_code, but the schema carries most of the load, so a 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?

States a specific verb (list), resource (a brand's products/denominations), and adds scope (live, priced in chosen coin). Explicitly distinguishes itself from list_esim_plans and positions its output as the exact labels for get_price/validate_order, so an agent can select it correctly.

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?

Names the alternative tool list_esim_plans with the exact condition that triggers it (eSIM use), and clarifies it never creates an order, ruling out create_order. This is solid routing guidance, though it doesn't enumerate conditions for other siblings like get_price — but the core discrimination is covered.

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?

While annotations already set destructiveHint=true, the description adds crucial behavioral specifics: the final 'confirm' answer creates a REAL order and requires explicit user approval. It also explains the stateful nature (call repeatedly, answer one question at a time), which is not apparent from annotations alone. No contradiction with 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?

Three tightly packed sentences deliver the fallback use case, alternative tools, stateful flow, and critical safety warning. Every sentence serves a distinct purpose with zero redundancy, and the most critical information (fallback + alternatives) is front-loaded.

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

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

It covers the essential flow: first call empty, stateful progression, completion status, and destructive final action. It could elaborate on error handling or the nature of the questions, and the output schema existence mitigates the need for return-value details. Minor gaps remain but the description is largely complete for a complex stateful wizard.

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

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

Schema coverage is 100%, so all parameters already have descriptions. The description merely restates 'First call: empty arguments' and 'same session_token', which are also in the schema. It adds no new semantic meaning beyond what the schema provides, meeting the baseline for high schema coverage.

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 explicitly states it is a 'Text-only fallback purchase flow for clients WITHOUT widget support' and directly contrasts it with list_esim_plans / list_products + validate_order + create_order, making the purpose and resource unmistakable and clearly distinguishing it from sibling 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?

It gives explicit when-to-use context ('for clients WITHOUT widget support') and when-not-to-use ('In ChatGPT prefer ... instead'), listing the preferred alternatives. It also details the stateful interaction pattern: repeated calls with the same session_token, answering one question at a time until status is 'complete', with first-call behavior specified.

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 provide readOnlyHint (true) and destructiveHint (false), so the safety profile is clear. The description adds the key behavioral trait that it never creates an order, which reinforces the read-only nature. It also mentions returning product handles for use with get_price/validate_order, which adds operational context. Overall, it supplements the annotations well without contradiction.

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 compact and front-loaded: it states the tool's function, the catalog scope, the output, and the important constraint (never creates an order) all in three sentences with no redundancy. Every sentence adds essential information for the agent.

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

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

The description is complete for a search tool given the rich annotations and output schema. It covers the scope, output, and relation to other tools. However, it doesn't mention potential filters (like kind or country) in the description, though these are in the schema, so an agent might not know that searching by country or product type is possible. But since the schema documents those, the description doesn't need to repeat them. A slight gap is absence of mention about result limits or pagination, but that's not critical.

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 parameters are documented in the schema. The description adds semantic context by mentioning the types of items searched (gift cards, eSIM plans, mobile top-ups) and the output value (product handles), which helps agents understand the purpose of the 'query' parameter beyond the schema's simple description. However, it doesn't add detailed format or syntax beyond the schema.

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

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

The description clearly states the search tool's purpose: searching the AgentRoam travel-crypto catalog with specific categories (gift cards, eSIM plans, mobile top-ups) and lists the output (product handles) and relationship to other tools (get_price/validate_order). It distinguishes itself as a search operation and clarifies it never creates an order.

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

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

It explicitly mentions the alternatives get_price/validate_order and states what this tool returns (product handles) for those tools, providing clear context for when to use it. It also implicitly indicates it is for searching before purchasing, but does not explicitly state when not to use sibling tools like list_products or list_brands which might have overlapping functions.

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 mark it non-read-only and non-destructive; the description adds the important behavioral details: the confirm_token is single-use, valid for 10 minutes, and the operation has no order-creation or fund-reservation side effects. This goes beyond the annotation flags and accurately sets expectations for the agent.

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 uses three concise sentences with no wasted words. It front-loads the primary action, then adds the valid duration, the mandatory user-approval step, and the non-mutating boundary. Every line 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?

Given the large parameter list and the fact that an output schema exists, this description is complete. It captures the validate-then-create flow, the temporary token, the required approval step, and the lack of side effects: an agent has everything it needs to call the tool correctly and process the returned summary.

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 all parameters in full. The description does not add parameter-level details, but with full schema coverage the baseline of 3 is appropriate since nothing is missing.

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 ('dry-run') and a specific resource ('an order'), then names the exact output (a one-time confirm_token). It explicitly distinguishes itself from create_order by noting that it does NOT create the order or reserve funds, so an agent immediately knows which sibling it is not.

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 says exactly when to use the tool: before calling create_order, and it requires showing the returned summary to the user for approval. The statements 'Does NOT create the order or reserve funds' make the boundary with create_order unambiguous.

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