PumpPill — token safety and measured outcomes

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral detail: hourly recomputation, occasional long latency, possible error='recomputing', and cache warming on retry. This goes well beyond the annotations and prepares the agent for real-world 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 well-structured, front-loading the core outcome definition, then explaining the honest methodology, then noting the recompute behavior. Each sentence adds value and is tightly written 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?

With no parameters and no output schema, the description covers the essential context: what is measured, how the metric is defined, why it is trustworthy, and operational notes about recomputation. An agent has enough to call and interpret 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?

There are zero parameters, so the schema is empty. The description does not need to add parameter semantics, and the baseline for zero-parameter tools is 4. It does not discuss parameters because none exist, which 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 states a specific purpose: reporting forward-measured outcomes (doubled, 5x, 10x, never moved) for a logged token population. It clearly differentiates itself from a track record or win rate, making the tool's role 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 explains what the tool is not (not a track record, not a win rate) and frames its usefulness for citing honest population-level outcomes. It does not explicitly mention sibling tools or when to choose this over alternatives, but the context is clear enough for an agent to infer its niche.

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?

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description adds valuable behavioral context: hourly recomputation, payload includes its own computed_at to quote instead of the request time, counts are counts not rates, entry is market cap at logging, and the index is limited to PumpPill's observations. This meaningfully clarifies the tool's data freshness and interpretation.

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

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

The description is front-loaded with the core purpose and metric list, followed by essential caveats about quoting and interpretation. Every sentence carries substantive information; no filler or repetition. The two-paragraph structure is efficient for the amount of critical context provided.

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

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

With no output schema and no parameters, the description serves as the primary guide to what the tool returns and how to interpret it. It enumerates included metrics, clarifies the time to attribute, and explains limitations. An agent would know exactly what to expect and how to handle the response, making it complete for this tool's complexity.

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 empty schema already covers everything (100% coverage). The baseline for 0 parameters is 4, and the description adds context about the payload contents (e.g., computed_at, metrics), which further supports interpretation even though it does not describe input 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 the tool measures chain statistics from PumpPill's index, listing specific metrics (tokens seen, outcome counts, doubling/10x thresholds, $100k crossing, tokenized stock quotes). This goes beyond a tautology and distinguishes it from siblings like rh_stock_pairs or rh_token_safety, which target specific token 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 implies usage by describing the tool's scope (chain-level statistics, hourly recomputation) and notes the index covers 'what PumpPill has seen rather than everything that exists,' providing a context cue. However, it does not explicitly advise when to use this tool over alternatives or when not to use it, leaving selection partly 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?

The annotations already indicate readOnlyHint, idempotentHint, and non-destructive, so the description doesn't need to restate those. It goes beyond by explaining the behavior of omitting records for factory/relayer wallets and single-launch wallets, which is non-obvious and critical for interpreting results. It also clarifies that no win rate is computed because 'crossed' rows only exist for successes, preventing the agent from inferring a misleading statistical field. This is a deep behavioral disclosure that annotations do not cover.

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 well-structured paragraph that starts with the core value proposition, then explains the filtering logic, and ends with the win-rate rationale. It is front-loaded with the key question an agent would ask ('What one wallet has launched...'). Every sentence earns its place, though the latter half gets into nuanced details that might be dense for some agents. It is not overly long but is dense with 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 has a single parameter, a simple input schema, and no output schema, the description is more than complete. It tells the agent what to expect (tokens, liveness, liquidity, crossings), what to not expect (no record for certain wallets, no win rate), and the rationale behind those behaviors. There is nothing an agent needs to call this tool correctly that is missing. The complexity is low, and the description addresses all potential questions.

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 only one parameter, address, with no description coverage. The description doesn't explicitly explain the format or validation of the address, but it implies it's a wallet identifier. Since the parameter is self-explanatory (an address string), the description doesn't need to add much. However, it could have clarified that the address is expected to be a Robinhood Chain wallet, but that is implied by the tool name. Baseline 3 is appropriate because the schema is minimal and the description adds limited but sufficient 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 purpose: to show what one wallet has launched on Robinhood Chain and how those launches went, focusing on tokens, liveness, liquidity, and crossing $100,000. It distinguishes this tool from siblings like rh_wallet_record and rh_chain_stats by emphasizing the deployer's perspective. The description uses specific terms like 'launchpad rows' and 'crossed $100,000' to make the functionality 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 explains when to use this tool: when a launchpad buyer wants to know if a wallet has launched tokens successfully. It also states when not to use it, by detailing the exclusion of factory/relayer wallets and single-launch wallets. It references 'wallet above the launch ceiling' and 'one launch is a fact about a token', giving clear criteria for when no record is returned. This guidance is comprehensive and prevents misuse.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable interpretive context: entries are findings with evidence, not price verdicts or accusations, and the scan window is 30 days. This goes beyond annotation coverage without contradicting 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 appropriately concise and front-loaded with the core behavior. The second sentence adds necessary caveats and examples, though it is slightly dense in one long sentence.

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 one-optional-parameter tool with no output schema, the description covers the main semantics, temporal scope, and intended interpretation of results. The only notable gap is not explaining the 'limit' parameter or output structure, but the provided examples partially compensate.

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 should compensate for parameter documentation, but it never mentions the 'limit' parameter. The schema shows only an integer with default 25, leaving unclear whether limit caps tokens, findings, or entries.

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 identifies the tool as returning tokens with HIGH or CRITICAL structural risk from scans in the last 30 days, with named findings. It is specific about the resource and scope, but does not explicitly differentiate from sibling tools like rh_token_safety or sol_token_detail, so it falls short of full sibling distinction.

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 clear intended use: show what the current wave of bad launches looks like. It also states an explicit when-not ('never as a list to trade against'), but it does not mention alternative tools or when to prefer a sibling over this one.

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 annotations already signal a read-only, idempotent, non-destructive tool. The description adds meaningful behavioral detail beyond that: results are 'unflagged' tokens, include liquidity and scan-risk information, and can return an aggregate count. No contradiction with annotations exists.

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 establishes the unique concept, gives the parameter behavior with examples, states the omit behavior, and explains why the tool matters. No sentence is wasted.

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 one-parameter, no-output-schema tool with rich annotations, this description is sufficient. It tells the agent exactly what input to provide, what the two output modes are, and what kind of data to expect.

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 only a bare optional 'stock' string with no description, and schema coverage is 0%. The description fully compensates by explaining both branches of behavior: passing a symbol like NVDA, SPY, or TSLA filters results to that stock, while omitting it returns a count per stock.

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 identifies the resource and behavior: listing memecoins that are quoted in tokenized stocks, with optional filtering by a stock symbol. The phrase 'pairing exists on no other chain' distinguishes it from sibling tools and highlights its unique scope.

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 operational guidance: pass a stock symbol to see tokens quoted in it, or omit it to get every stock with a count. It does not explicitly name alternative tools or state when not to use it, but the usage 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?

Annotations already mark the tool read-only, idempotent, and non-destructive, so the description's burden is lower. It adds valuable behavior beyond annotations: the selection gate (alive, $10k pool, not HIGH/CRITICAL), returning a count instead of a list, and the meaning of found=false.

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 main action is front-loaded and all sentences carry meaningful information about selection criteria, return shape, or found=false semantics. It is slightly wordy with rhetorical framing like 'costs people money' and 'a menu,' but remains focused.

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

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

With one parameter, no output schema, and annotations covering safety, the description is complete enough for correct invocation. It explains what the tool returns, how the canonical contract is chosen, why other contracts are only counted, and what found=false means.

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 0% description coverage and one 'symbol' parameter. The description clarifies that symbol means a ticker symbol and relates it to contract resolution, but it does not provide format, case-sensitivity, or examples. This is adequate but not richly compensating for the schema gap.

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

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

The description opens with a specific verb and resource: 'Names ONE Robinhood Chain contract for a ticker symbol.' It clearly distinguishes this tool from siblings by emphasizing 'real ticker' and the single canonical contract among many possible deployments.

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

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

Usage is implied rather than explicit: an agent can infer this is for resolving a symbol to its canonical contract, and the gate criteria clarify what qualifies. However, it never names alternatives or states when not to use this tool versus the related sibling tools.

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?

Beyond the annotations' readOnlyHint and idempotentHint, the description discloses crucial behavioral nuances: no new scan is ever triggered, found=false is an honest miss, deep=true changes which checks ran, flags are evidence-backed findings not predictions, and peak is measured since scanning began. These details meaningfully shape how the agent should interpret results.

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 longer than average, but almost every sentence adds a needed caveat or semantic clarification. It is front-loaded with the core purpose and then layers essential interpretation rules. Slight redundancy around the stored/no-new-scan point keeps it from being maximally tight.

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 this tool has nuanced result semantics, the description covers the critical return-value meanings: found, deep, flag, and peak. It also addresses timing and interpretation pitfalls. An agent has enough context to invoke the tool and correctly interpret its result without additional documentation.

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 only says 'Address', but the description specifies the exact required format ('0x + 40 hex') and ties it to a Robinhood Chain token. With 0% schema coverage, this fully compensates for the missing schema-level documentation and gives the agent a precise validation rule.

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 verb and resource: 'STORED safety read for one Robinhood Chain token', then enumerates the exact data dimensions (sellability, flags, launch money, market-cap run). It is clearly distinct from siblings like rh_flagged_recent or sol_token_detail because it is address-keyed, Robinhood Chain-specific, and read-only.

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 clear usage context: it is a fast cached read that 'NEVER triggers a new one', so agents know it is appropriate when a stored result is acceptable. It also explains how to interpret found=false as an honest miss rather than a clean bill of health. It stops short of naming alternative tools for fresh scans or other token chains, so it lacks explicit when-not/alternatives guidance.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description adds critical behavioral context: sell sizes are floors derived from the router's minimum-out and must not be converted into P&L, and many addresses are routing contracts rather than people. These disclosures prevent serious misinterpretation and go well beyond what structured annotations provide.

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 sentences with no fluff: purpose is front-loaded, followed by two high-value caveats. Every sentence earns its place and the structure is easy to parse.

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 read-only, single-argument tool, the description covers the source, the returned content (holdings and trades), and the most important interpretation pitfalls. It lacks explicit output shape and address format details, but the low complexity and strong annotations make it largely adequate.

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 for the lone 'address' parameter. It only generically implies address identifies a wallet, but gives no format, constraints, examples, or validation context. This falls short of what an agent needs for correct invocation.

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-plus-resource: it reports what a single wallet holds and has traded, sourced from the chain's own feed. This clearly differentiates it from sibling tools like rh_deployer_record or rh_whale_wallets by scope and focus.

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

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

Usage is implied by the purpose statement — an agent needing a wallet's holdings/trades would select this tool — but there is no explicit when-to-use guidance, alternatives, or exclusions. The caveats about sell floors and contract addresses aid interpretation, not tool selection.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: it clarifies the data is on-chain balances, not inferred activity, and that trade counts start from meta.trading_since (a dynamic start time). It also warns that the tool measures capability, not correctness or following value, which is valuable interpretive 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 dense with useful information yet not verbose. It opens with a clear one-sentence definition, then adds a cautionary note and sorting explanation. Every sentence adds value: the stats (1,967 wallets, 14 traded, ten largest made zero trades) and the clarification about trading_since are directly relevant to usage. The formatting with emoji and bold improves scannability without adding 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 the tool has no output schema and only two simple parameters, the description covers everything an agent needs: what the tool returns (list of qualifying wallets), how to sort, the meaning of trade counts, and caveats about interpretation. The annotations cover the read-only and idempotent aspects. The description also references meta.trading_30d and meta.trading_since, providing context on fields likely in the response. This is complete for a list-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 0%, so the description must explain parameters. It explains the sort parameter in detail: default is balance, and sort='active' orders by trades instead. It also mentions meta.trading_30d and trading_since, which relate to the trade counts used in sorting. The limit parameter is not explicitly explained, but its meaning is self-evident as a standard limit on number of results. Overall, the description compensates well for the schema's lack of parameter 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 clearly states the tool lists wallets holding at least 10 ETH or $50,000 in tokens, read as on-chain balances rather than inferred activity. This specifies the resource, the filtering criteria, and differentiates it from activity-based tools like rh_wallet_record or rh_chain_stats. The phrase 'who CAN move a pool' further clarifies its purpose.

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 strong usage context: it warns that most wallets hold rather than trade, explains that meta.trading_30d is part of the answer, and explains that sort='active' orders by trades. It doesn't explicitly name sibling tools as alternatives, but it implies when to use this tool (to assess who can move a pool) and how to interpret results. The guidance on time frames (trading_since) and sorting adds practical usage direction.

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 the safety profile is covered. The description adds valuable behavioral nuance beyond annotations: meta.verdict is the lead output, the rest is supporting evidence, and a clean read is not a buy signal. This is useful interpretive context for an 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 is compact, front-loaded with the core purpose, and every sentence earns its place. The list of returned fields is efficient, and the caveat about clean reads is essential context rather than 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 there is no output schema, the description does enough by naming the major output sections and explaining how to interpret meta.verdict. It could be more explicit about error cases or the exact return shape, but for invoking the tool correctly with one parameter, it is sufficiently 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 by specifying that the single parameter 'mint' is a base58 Solana mint address. This adds real meaning beyond the bare schema and is adequate for a one-parameter 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 clearly identifies the resource (Solana token by mint) and enumerates the data returned: holders, bundled-launch read, deployer holdings, socials, and meta.verdict. It reads as a specific lookup tool, though it does not explicitly differentiate itself from siblings like rh_token_safety.

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 any Solana token lookup and gives a reading order ('Start from meta.verdict'). However, it never states when to choose this tool over sibling tools, nor does it mention exclusions or alternatives.

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