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

With no annotations, the description must disclose behavior, but it only states the cancel action without detailing consequences such as order state changes, whether partial fills affect ability to cancel, or any required authorization. This leaves significant behavioral information undisclosed.

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

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

The description is a single clear sentence that is appropriately concise and front-loaded. It avoids verbosity but is under-specified in terms of usage and parameter details, though that is covered elsewhere.

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 cancellation tool with one parameter and no output schema, the description is minimal. It lacks information about how order_id should be formatted, how to obtain it, and what response to expect, so it is not fully contextual.

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

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

The schema has one parameter (order_id) with no description, and the tool description does not mention order_id at all. With 0% schema description coverage, the description fails to add meaning about how to identify the order or acquire its ID.

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

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

The description clearly states the action (cancel) and the target (an existing order on Polymarket). It differentiates from sibling tools like place_order and get_trades through the cancel verb.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or edge cases. Users must infer from the name that it is for canceling orders.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It clearly implies a read-only operation via 'Get' and specifies the asset (USDC) and wallet, but does not mention return format, error conditions, or whether any state is affected. This is adequate but lacks richer context.

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

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

The description is a single, focused sentence with no filler. It conveys the essential information without redundancy.

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's simplicity (zero parameters, no output schema), the description is largely complete: it names the asset, the operation, and the scope. It does not explicitly state what the output will contain, but 'balance and allowance' implies the return fields, which is sufficient for a getter.

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 accepts zero parameters, so the baseline is 4. The description adds meaning by clarifying that the balance and allowance are for the pre-configured wallet, reducing ambiguity that might otherwise arise in an empty 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 uses a specific verb ('Get') and clearly identifies the resource ('USDC balance and allowance') and scope ('configured wallet on Polymarket'). It distinguishes itself from sibling tools like polymarket_update_allowance by focusing on retrieval rather than modification.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of relationship to polymarket_update_allowance or any preconditions for use, leaving the agent to infer usage.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It explains what information will be returned, but does not disclose behavior in edge cases such as when no identifier is provided (despite the schema allowing all optional) or when multiple identifiers are supplied. It also does not explicitly confirm read-only behavior, though the name 'get' implies it.

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

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

The description is two sentences: the first front-loads the purpose and return contents, the second gives parameter usage. Every word earns its place, with no redundancy or irrelevant detail.

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 getter with no output schema, the description adequately covers purpose, parameters, and return content. The main gap is the ambiguity around the mandatory nature of the identifier: the description says 'Provide one of' but the schema lists no required parameters, which could confuse an agent. Additional clarity on this would make it complete.

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 0%, so the description must compensate. It does so effectively by stating that condition_id, slug, or URL are alternative identifiers and providing a concrete URL example. However, it lacks details on the exact format of condition_id and slug, and does not clarify precedence if more than one is provided.

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's verb and resource: 'Get detailed information about a specific prediction market' and enumerates the returned fields (token IDs, current prices, description, liquidity, market status). This distinguishes it from sibling tools like polymarket_get_markets or polymarket_get_orderbook, which target different resources.

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

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

The description provides clear context by specifying 'a specific prediction market' and instructs the user to 'Provide one of: condition_id, slug, or a full Polymarket URL'. However, it does not explicitly mention when to use this tool over alternatives (e.g., 'for multiple markets, use get_markets'), so it stops short of a 5.

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

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

With no annotations, the description bears the full burden of disclosing behavior. It mentions sorting by volume and lists the fields returned, which adds context beyond a bare statement. However, it does not disclose pagination behavior, default limits, search semantics, or any potential side effects. It also does not explicitly state that this is a read-only operation, though 'list' implies that.

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

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

The description is a single, efficient sentence. It is front-loaded with the action and resource, then succinctly lists the return fields. Every word adds value, no repetition of schema details occurs, and there is 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?

Given no output schema, the description compensates by listing return fields, which is helpful. However, with three parameters and no annotation or output schema, the description leaves gaps: it does not explain how to use search or paginate through results, nor does it mention the meaning of limit/offset. For a listing tool of moderate complexity, this is adequate but not fully complete.

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

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

The schema description coverage is 0%, meaning the description does not explain the limit, offset, or search parameters. It does not even hint that these parameters exist, nor does it clarify how search works or how pagination is handled. While the schema provides types and defaults, the description adds no value for parameter understanding beyond that.

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 lists prediction markets on Polymarket, sorted by volume, and enumerates the returned fields. The verb 'List' and resource 'prediction markets' make the tool's function immediately understandable and distinct from siblings like get_market (single market) or get_orderbook.

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 does not provide explicit guidance on when to use this tool compared to alternatives. While the purpose implies it is for browsing all markets rather than querying a specific one, there is no mention of sibling tools or situations where another tool would be preferable. The agent is left to infer usage from the tool name and description.

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

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It usefully mentions 'No API key required' and that it uses Google News RSS, but it does not disclose rate limits, potential latency, or the structure of returned data. This is adequate but lacks depth.

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 three short sentences, each adding distinct value: the core action, the use case, and the authentication note. There is no redundancy or filler, making it easy to parse quickly.

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

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

For a simple news-fetch tool with no output schema, the description covers purpose, use case, and auth, which are the key decision factors. However, it does not describe the return format (e.g., list of headlines with dates and links), which would help an agent anticipate results. This is a minor gap given the tool's simplicity.

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

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

The schema provides a description for 'query' with examples, but 'limit' has no description in the schema. The tool description does not explain what 'limit' controls, leaving a gap at 50% schema coverage. It adds no meaning beyond the schema's numeric constraints, so the description fails to compensate for the undocumented parameter.

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

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

The description opens with a specific action ('Fetch recent news headlines for a topic via Google News RSS'), clearly identifying the resource and method. This distinguishes it from the trading/market siblings, which are all focused on Polymarket data or order operations.

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

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

The description explicitly states a use case: 'useful for understanding current events and market context when analyzing prediction markets.' This tells the agent when to use the tool, and the sibling list makes alternatives obvious, though it does not explicitly state when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns current bids and asks with prices and sizes, which implies a read-only operation. However, it doesn't mention any additional behavioral details such as authentication requirements, potential emptiness, or data formatting.

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 focused sentence, immediately states the action, and contains no filler. It is appropriately sized for the tool's complexity.

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

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

For a simple read-only tool with a single parameter and no output schema, the description covers the core return information (bids, asks, prices, sizes). It is nearly complete, though it could mention whether the order book is aggregated by price level or includes other fields.

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 0% and the description does not explain the token_id parameter beyond calling it a 'specific token'. The parameter name is self-explanatory to some degree, but with no schema description and no indication of where to obtain token_id (e.g., from get_markets), the agent lacks essential semantic context.

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's function: 'Get the order book for a specific token showing current bids and asks with prices and sizes.' It uses a specific verb ('Get') and resource ('order book'), and distinguishes itself from sibling tools like get_market or get_trades.

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 the tool is used when you need order book data for a token, but provides no explicit when-to-use or when-not-to-use guidance. It doesn't mention alternatives or contrast with sibling tools like get_market, which could help an agent decide.

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

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

With no annotations, the description carries the full burden. It discloses the data source ('Polymarket Data API'), the scope ('configured wallet'), and return contents (P&L, flags, market info). However, it does not explicitly state that this is a read-only operation, nor does it mention authentication requirements, rate limits, error behavior, or side effects. The response field list adds transparency about output but not about underlying behavior.

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 structured with an introductory purpose sentence, a parameters section, and a response includes section. It is not overly verbose, though listing response fields adds length. The front-loaded purpose and clear sectioning make it easy to scan, and every part serves a purpose given the lack of an output 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?

Given there is no output schema and no annotations, the description provides a thorough overview: purpose, parameter semantics, and detailed response fields. It misses some operational context like error handling, rate limits, or authentication specifics, but for a simple read-only position lookup, it covers the essential information adequately.

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 description explains all three parameters beyond the schema: redeemable ('Filter to only show redeemable (resolved) positions'), market ('Filter by condition ID'), and limit ('Max results 1-500, default 100'). This fully compensates for the 0% schema coverage and does not merely repeat schema constraints—it adds meaningful 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's purpose: 'Get real positions (token holdings) for the configured wallet from Polymarket Data API.' It distinguishes from siblings by emphasizing 'actual token balances with P&L, not just open orders,' contrasting with order-related tools. The verb-resource pair is specific and unambiguous.

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

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

The description provides clear context for when to use this tool: when you need actual token holdings with P&L for the configured wallet. It indirectly differentiates from open-order tools but does not explicitly name alternatives or state exclusion criteria. The 'not just open orders' phrasing implies a contrast with order-related sibling tools, but explicit guidance is missing.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read operation, but there is no detail on what 'recent' means (time window), whether results are sorted, or if this affects wallet state. The description adds no behavioral context beyond the action itself.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds meaning, making it highly concise and well-structured.

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

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

Given no annotations and no output schema, the description should provide more context. It lacks information about the limit parameter, return format, or what constitutes 'recent'. The simple structure does not excuse the missing details that would help an agent invoke 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 0% and the description does not mention the 'limit' parameter at all. The schema provides type/default/min/max but no semantic meaning, and the description offers no compensation, leaving the parameter's role entirely up to inference from its name.

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 'Get recent executed trades for the configured wallet' uses a specific verb 'Get' and identifies the resource 'executed trades' and scope 'configured wallet'. It clearly distinguishes from sibling tools like get_positions (current holdings), get_balance, and get_orderbook.

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 usage when recent trade history is needed, but it does not explicitly compare to alternatives or state when not to use it. There is no mention of using get_positions for open positions or get_orderbook for market depth, so guidance is only 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?

The description includes a prominent CAUTION warning that this executes a REAL trade with REAL funds at market price, and explains the semantics of FOK vs FAK order types. It does not detail the return value or potential slippage, but the risk warning is a significant behavioral disclosure given no annotations exist.

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 well-structured with a clear intro, a caution, a parameter list, and examples. Every section serves a purpose, and the content is concise without unnecessary 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?

While it covers all parameters and risk, it omits the response format (e.g., order ID or confirmation) and prerequisites like allowance, which are important for a trading tool with no output schema and no annotations. The examples and parameter details are strong, but these gaps reduce completeness.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's role, especially the context-dependent meaning of 'amount' (USD for BUY, shares for SELL), and providing concrete examples. This adds substantial value beyond the raw 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 'Place a market order on Polymarket for immediate execution' with a specific verb and resource, and distinguishes itself from siblings like polymarket_place_order (likely limit orders) by emphasizing 'market order' and 'immediate execution'.

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 usage for immediate execution and provides examples, but does not explicitly mention when to use this tool versus alternatives like polymarket_place_order for limit orders, nor does it mention prerequisites such as having sufficient allowance (update_allowance sibling).

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

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

With no annotations, the description carries the full burden. It discloses that this executes a real trade with real funds, includes price bounds (0-1), and specifies size in shares. However, it doesn't disclose prerequisites like allowance or balance, nor what happens on success or failure, which are significant gaps for a trade execution tool.

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

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

The description is three short sentences: the main action, a caution, and key constraints. There is no fluff, and critical information is front-loaded. It is appropriately sized and every sentence 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?

No output schema means the description should explain return values, and it doesn't. It also doesn't mention the need for prior actions like updating allowance, or how the order behaves on the order book. The tool is a trading operation with high stakes, so the missing context around prerequisites and results makes it incomplete.

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 0%, so the description must compensate. It provides some meaning for 'price' (between 0 and 1) and 'size' (in shares), but does not explain 'token_id' at all. The enum for 'side' is self-documenting, but overall the parameter explanations are insufficient for 4 required parameters.

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 'Place a limit order on Polymarket', which is a specific verb+resource. It also differentiates from sibling tools by explicitly saying 'limit order', which distinguishes it from the sibling 'polymarket_place_market_order'.

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

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

The description provides clear context for when to use the tool: when placing a limit order. It doesn't explicitly mention alternatives or exclusions, but the name and description make the usage situation clear. A caution about real funds adds context for the user to consider before using.

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

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

With no annotations, the description carries the burden of disclosing behavior. It explains that the tool tells the CLOB server to re-check and update on-chain allowance state, which implies a mutation. However, it lacks details on permissions, reversibility, idempotence, or failure behavior, leaving some uncertainty.

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, each earning its place. The first sentence states the core purpose, and the second immediately provides usage guidance. No redundant or extraneous content.

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, zero-parameter tool, the description adequately covers what it does and when to use it. It doesn't mention return values or outcome details, but given the lack of an output schema and the straightforward nature of the action, this is a minor gap rather than a critical omission.

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 the description correctly omits any parameter info. Per the guidelines, a baseline of 4 is appropriate for 0-parameter tools since there is nothing to explain beyond the schema (which is empty).

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

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

The description clearly states the action ('trigger a refresh') and the resource ('USDC allowance for trading on Polymarket'), making it distinct from sibling tools like place_order or get_balance. The verb 'refresh' is specific and conveys the tool's purpose 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 explicitly states when to use the tool: 'when orders fail due to insufficient allowance.' This provides clear usage context. It doesn't mention alternatives or exclusions, but the trigger condition is specific and actionable.

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