stablecoin-yield

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

No annotations provided, so the description carries the full burden. It discloses the pricing model ($0.01 per call via x402), which is valuable behavioral context. However, it doesn't state whether results are cached, rate-limited, or what the response contains.

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?

Efficient single sentence with purpose plus examples and pricing in parentheses. Front-loaded with the core purpose. No wasted sentences, though the parenthetical pricing info could arguably be separate.

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 2-param lookup tool with 100% schema coverage, this is adequate but not rich. No output schema exists, so the description should explain what 'routes' means as a return value (list of bridges? quotes? fees?). The gap between input and expected output is undocumented.

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 (symbol, from_chain as lowercase strings). The description adds the example 'USDC from arbitrum' which reinforces format but adds little beyond the schema. Baseline 3 when schema does the heavy lifting.

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

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

States a specific verb-like resource ('cross-chain route availability for a stablecoin from a given chain') with clear scope (bridge/venue coverage). Distinguishes itself reasonably from siblings like barker_execution_quote, though it doesn't explicitly name which sibling is the alternative.

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?

Provides example queries ('bridge USDC from arbitrum', '跨链路径') that signal when to use it. However, it doesn't state when NOT to use it or explicitly contrast with barker_execution_quote or other routing siblings.

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 full burden. It describes output fields, mentions real-time, and states the cost. It does not explicitly state read-only or error behavior, but the provided details are sufficient for a query 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?

Three sentences, front-loaded with purpose, then output, then examples. 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?

Despite no output schema, the description explains return fields clearly. Parameters are fully covered in schema. Missing details like sorting default or pagination, but overall complete for a query tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context about output fields (e.g., multiplying apy by 100) but does not add meaning to 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 clearly states the tool queries stablecoin supply yield pools from a specific index, using a strong verb 'Query' and specifying the resource. It distinguishes itself from siblings by focusing on stablecoins and yield pools.

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 explicit usage examples ('best stablecoin yield', 'where to earn on USDC') and implies the tool is for stablecoin yield questions. It does not explicitly exclude alternatives but the context is 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?

With no annotations, the description carries full burden. It discloses cost ($0.01 via x402), APY unit format (decimal), and output compatibility (pool_uid exact string for quote tool). These are valuable behavioral traits beyond any structured metadata.

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 front-loaded with 'EXECUTION DISCOVERY' and each sentence adds unique value: purpose, relationship to quote tool, output, skip condition, optionality, APY unit, use cases, and cost. Dense but well-structured with no 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?

For a discovery tool with 6 optional params and no output schema, the description covers key output fields, operational workflow, cost, and APY semantics. It is complete enough for an agent to select and invoke the 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 baseline is 3. The description adds that all parameters are optional and explains the no-argument behavior, but does not provide additional parameter-specific semantics beyond what the schema already states.

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

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

The description opens with 'EXECUTION DISCOVERY' and explicitly states it identifies stablecoin vaults supporting direct deposit/redeem through barker_execution_quote. It clearly distinguishes this from siblings by referencing the specific workflow and output fields (adapter support, is_full, APY/TVL).

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?

Provides explicit when/when-not: 'Call this before barker_execution_quote' and 'Skip this call entirely if you already know the vault contract address.' Also clarifies that all parameters are optional and that no-arg calls return top executable pools, giving clear invocation context.

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 full behavioral burden and delivers extensively. It discloses the non-custodial security posture ('Barker NEVER broadcasts and never holds funds'), the exact return structure (transaction_request with chainId, from, to, data, value + route + risk summary + approval info), failure modes (POOL_NOT_FOUND, 409 POOL_AMBIGUOUS with candidates), the 'rejects ambiguity instead of guessing' policy, the paid $0.05/call cost, and the 'backend rejects a mismatch' cross-check behavior. Nothing is left to inference.

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 long but every sentence earns its place given the high-stakes money path — security posture, flow, identity rules, error behavior, and concrete examples are all load-bearing. It is front-loaded with the core action and prioritized with critical constraints near the top. Likely slightly overstuffed exactly where safety justifies it, so not a 5 but well above adequate.

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 complex 7-parameter financial tool with no output schema and no annotations, the description is remarkably complete. It covers the return payload structure (compensating for the missing output schema), error semantics, dimensionality/decimals handling, cross-chain edge cases, and the full flow with sibling tools. An agent has everything needed to 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 coverage is 100%, so the baseline is 3, and the description clearly adds value on top. It explains the amount vs amount_base_units mutual-exclusion and server-side conversion using the pool's own decimals, explains why signer_address is mandatory (it is the tx sender and share recipient — 'Barker can never infer or default it'), and clarifies when chain_id matters (same address on several chains). This goes beyond the raw property descriptions.

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 ('buy an unsigned, ready-to-sign transaction that deposits into or redeems from a stablecoin vault') and clearly distinguishes this from siblings by placing it in an explicit flow (barker_yield_advisor → barker_executable_pools → this tool → user signs). It also clarifies what it is NOT (non-custodial, never broadcasts). An agent can immediately tell this apart from discovery/pricing tools like barker_executable_pools or barker_yield_advisor.

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?

Extremely explicit when-to-use guidance: names the flow context, states to use it when 'you already know the vault address' (no discovery call needed), gives concrete example prompts in both English and Chinese, and spells out constraints like 'vault shares always go to signer_address' and 'Same-chain only'. It also tells the agent what to NOT do (never accept symbols or asset-token addresses as identity) and states exclusions for alternatives.

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 full burden. It adds key behavioral details: share_pct fields are decimals (0.425 = 42.5%) and the call costs $0.001 via x402. This goes beyond the schema and helps the agent understand data format and cost.

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 concise sentences, front-loaded with the core purpose, followed by usage examples and a critical data format note. Every sentence adds value with no unnecessary 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 zero-parameter, no-output-schema, no-annotation tool, the description covers purpose, usage, data format, and cost. It lacks an explicit output structure but is sufficient for this low-complexity 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 the baseline is 4. The description does not need to explain parameters and instead provides context about output fields (share_pct), which is useful.

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 stablecoin market snapshot with specific metrics (total cap, yield-bearing cap, asset distribution, chain distribution). This is a specific verb+resource that distinguishes it from sibling tools like market_trend or pool_search.

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 explicit example use cases ('stablecoin market cap', 'USDT market share', '稳定币市场份额'), giving clear context on when to use. It does not mention exclusions or alternatives, but the guidance is direct and actionable.

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 full burden. It adds useful context like the lookback window and paid nature, but doesn't disclose what the trend output looks like (series data, chart, etc.) or any access/rate limits. This is a moderate disclosure level.

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, front-loaded with the core purpose, and includes use-case phrases and pricing. No unnecessary 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?

For a tool with one parameter and no output schema, the description explains the main purpose and use cases clearly, but fails to describe the return format or data granularity. Since it's a trend tool, the output structure (e.g., time series vs summary) is important and not addressed.

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

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

Schema coverage is 100% and the schema already describes the days parameter with min/max and default. The description repeats the lookback range but adds no new semantic meaning beyond what the schema provides, so 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?

The description clearly states the tool provides a historical APY trend for stablecoins vs. US Treasury benchmark over a specific lookback window. This distinguishes it from siblings like barker_market_overview or barker_pool_history by specifying the exact comparison and metric.

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

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

The description gives explicit use cases ('DeFi vs treasury', 'is stablecoin APY going up') which help the agent know when to invoke it. However, it doesn't mention when not to use it or point to alternative tools, so it falls short of a perfect 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions the paid cost ($0.005 per call) and lists informational data fields, but it does not explicitly state that the tool is read-only, what happens with an invalid pool_uid, or any authorization requirements. The term 'dossier' implies safety but this is not explicit.

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, front-loaded with purpose, then usage, then pricing. Every sentence adds distinct value with no redundancy or 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 description covers what the tool does, the data it returns, the workflow context, and the cost. It does not mention error handling or pagination, but for a single-parameter detail tool with no output schema, this is largely sufficient. The enumerated return components compensate for the lack of an output schema.

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 input schema has 100% coverage with a clear description of pool_uid ('Pool uid from list tools'). The tool description reinforces the source by saying 'Use after barker_defi_vaults / barker_yield_advisor,' but adds no additional format or constraint details. Baseline 3 is appropriate given the schema already handles parameter documentation.

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 single-pool dossier' with specific components (APY components, TVL, terms, execution capability, reward breakdown). It distinguishes itself from sibling tools by specifying it inspects one pool after using list tools, making its purpose unmistakable.

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 says 'Use after barker_defi_vaults / barker_yield_advisor to inspect one pool,' providing clear workflow guidance. It does not explicitly mention when not to use it or compare to alternative detail tools such as barker_pool_history, so it stops short of a full 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 provided, the description carries the burden of behavioral disclosure. It adds useful context: default 30-day range, APY in percent units, and cost per call. But it does not explain the response format, data granularity, failure behavior, or how pool_uid is obtained, leaving significant gaps.

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 concise sentences with a parenthetical cost note. It front-loads the core function, provides usage guidance, and adds practical billing info without unnecessary words. Every sentence contributes value.

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 and no annotations, the description should explain what the tool returns, but it only vaguely says 'time series'. It omits details like whether both APY and TVL are returned separately, data point frequency, and how to interpret results. For a paid tool, this is a notable gap that could hinder 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 0%, so the description must compensate. It mentions pool_uid as the target pool and 'default 30d' which clarifies the days parameter's meaning and default, but it does not explain parameter bounds, format, or that days is optional with constraints. This is insufficient for such low 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 clearly states the tool's function: providing per-pool APY/TVL time series for trend and volatility analysis of a single pool. It specifies the resource (Barker's index), scope (one pool_uid), and default period, distinguishing it from sibling tools like barker_pool_detail or barker_market_trend that likely offer different data.

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 says 'Use for' with concrete example queries ('is this pool's APY stable', '这个池子收益稳不稳'), giving clear usage intent. However, it does not mention when not to use it or alternatives, so it falls short of the full 5-point criterion.

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 full behavioral disclosure. It reveals that search is fuzzy, that it resolves to a pool_uid, and adds cost information ('$0.001 per call via x402'), which goes beyond the schema. It does not describe the full return structure, but the core behavior is transparent.

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 concise sentences with no redundant words. The core action is front-loaded, and the cost note is relevant and succinct.

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 fairly complete for a simple search tool: it states the purpose, the output type (pool_uid), and cost. It lacks details on return structure, empty results, or error behavior, but this is mitigated by the clear purpose and the absence of an output schema.

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 define the 'keyword' parameter as 'protocol name / pool name / asset', which is helpful. However, the 'limit' parameter is not explained, leaving it undocumented beyond the schema's basic type and range.

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 ('Fuzzy search') and resource ('Barker's pool index'), then explains the purpose ('Resolves natural-language pool references to pool_uid for the detail/history tools'). This distinguishes it from sibling tools like barker_pool_detail and barker_pool_history.

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 when to use it: when you have a natural-language pool reference and need to get the pool_uid for detail/history tools. However, it does not explicitly name alternative tools or state when not to use it, but the context is clear enough.

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?

Despite no annotations, description fully discloses on-chain read nature, smart contract calls (balanceOf + convertToAssets), variable resolution from pool_uid, and cost ($0.001 per call). Also warns that Barker does not store deposit baseline.

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?

Well-structured with purpose first, then details. Includes bilingual example. Slightly long but every sentence is informative.

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, but description explains return values (shares, current_value, value_asset). Covers prerequisites, cost, and data storage limitation. Fully sufficient for agent to use 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 has 100% coverage, but description adds value: explains that address is EVM wallet with format, and pool_uid comes from specific sibling tools. Provides context beyond 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?

Clearly states verb 'read' and resource 'vault position', specifies it returns shares and current_value. Ties to sibling tools (barker_executable_pools, barker_execution_quote) for context. Differentiates from other tools by focusing on monitoring positions post-deposit.

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 says 'Use after depositing via barker_execution_quote to monitor a position' and advises users to track their own principal. Could add more explicit when-not-to-use but is clear enough.

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 discloses that the call is paid ($0.03 per call via x402) and explains the APY unit. It also mentions the return includes data-driven reasons and risk flags. However, it lacks details on limitations like no results cases, rate limits, or auth requirements.

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 concise, front-loaded with the tool's purpose, and includes useful examples and unit clarification without extraneous 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 tool's complexity as a flagship with 5 parameters and no output schema, the description covers the purpose, usage, cost, and return characteristics comprehensively. It effectively compensates for the lack of output schema and sibling differentiation.

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 100% schema description coverage, the description adds no additional meaning beyond the schema's parameter descriptions. 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?

The description clearly states it returns a ranked top-N recommendation for stablecoin yield, with specific risk flags and data-driven reasons. Example prompts like 'Where should I park my stablecoins right now?' and 'best place for my USDC' show the exact verb+resource, and it distinguishes itself from sibling tools as the flagship yield advisor.

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

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

The description gives explicit usage scenarios via example prompts, but does not explicitly state when not to use the tool or mention alternatives. However, the context signals show distinct sibling tools, so the implied usage is clear.

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