CoinBucha

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

Annotations already declare read-only, idempotent and closed-world behavior; the description adds substantial context beyond them — up to 5 events soonest-first, truncation via `truncated`, statutory windows that are never exact dates, date_status values, free vs paid route, disclaimer, and data_contract. This is rich operational context for a read-only 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?

Front-loaded with purpose, then params, returns, caveats and monetization. However, it is long for a two-parameter tool and repeats itself — data_contract appears both in the return list and again at the end as 'Every answer carries data_contract...'. Some sentences, such as the awkward 'named with its price in `full`', could be tightened.

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?

There is no output schema, so the description carries the return burden. It fully documents the response shape (as_of, today, days_ahead, ticker, count, available, truncated, events[], full, disclaimer, cite, data_contract), event fields, possible date_status values, truncation, and the paid vs free access model. Nothing an agent needs to interpret the result is missing.

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 already documents both parameters (ticker up to 12 chars, days_ahead 1-60 default 60). The description mostly repeats that and adds brief example payloads, but adds no new syntax or constraint meaning beyond the schema. Baseline 3 is appropriate.

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

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

States a specific resource (next results dates and SEC 10-Q/10-K filing windows of listed bitcoin holders) and names representative tickers (MSTR, COIN, MARA, HOOD). An agent can tell this is an earnings/filing calendar, not a generic signal feed like the sibling tools.

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

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

Explicitly bounds the tool to 'one question, one answer' and routes bulk/history/backfill/scheduled pulls to CSVs and datapackage.json at coinbucha.com/data. It does not explicitly compare against sibling signal tools, but the scope boundaries and alternatives are 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 establish readOnly, idempotent, non-open-world behavior, and the description adds meaningful context beyond them: no arguments, exact return fields, required CoinGecko attribution text, a 'not financial advice' disclaimer, and a data_contract envelope with source/as_of/status. It does not discuss rate limits or freshness guarantees for the daily digest, leaving a small gap.

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?

Front-loads the purpose well, but it is padded: the title phrase 'the CoinBucha Daily Brew' is restated, and 'Example: {}' is an empty-object example that conveys nothing for a no-argument tool. Attribution, disclaimer and server-routing clauses are useful but crowd the core statement.

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, the description carries the return contract and does so by enumerating the fields plus the data_contract envelope, so an agent knows what comes back. The only shortfall is that it never explains the shape or ordering of signals_summary[] entries beyond 'one summary line per signal.'

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?

Zero parameters, so baseline is 4; the description correctly confirms 'Takes no arguments,' which matches the empty schema and removes any ambiguity about how to call it.

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

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

States a specific verb and resource — the day's machine-readable digest of the whole signal set — and the 'whole signal set' framing implicitly separates it from the per-signal siblings (get_etf_flows, get_hiring_signal, get_treasury_holdings, etc.). It never explicitly names those siblings or scan_signals, so the differentiation is inferable rather than spelled out.

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

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

Gives real routing guidance: 'one question, one answer' bounded questions belong here, while bulk, history, backfills and scheduled pulls should use the CSVs/datapackage.json. The exclusion is explicit, though the external data files are named as the alternative instead of the sibling tools like get_signal_history.

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 only cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false); the description goes well beyond them, disclosing the exact return object, the reason for retirement, backward-compatibility intent, and the critical semantic that 'absent' must never be read as a zero flow.

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?

Front-loads the essential RETIRED status and the absence-is-not-zero warning efficiently. Some trailing content (data_contract boilerplate, 'information not financial advice', the server's bounded-question policy and CSV pointer) is generic server-level text rather than tool-specific, slightly diluting focus.

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 carries the full burden and does so completely: return shape, semantics of the absent value, alternatives, and callability for legacy integrations are all covered.

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?

Zero parameters, so the baseline is 4. The description reinforces this by stating it takes no arguments and giving an empty example {}, but adds no param-level detail because there is none to add.

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 unambiguously that this is a retired tool that serves no flow figures and returns { available: false }. The verb+resource situation is fully resolved: the agent learns not to call it for data and exactly what a call returns, and it names the live-signal siblings by name.

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

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

It gives an explicit when-not (retired, do not read absence as zero) and lists concrete alternatives (scan_signals, get_sovereign_reserves, get_treasury_holdings, get_hiring_signal, get_network_signal, get_daily_brew). Nothing is left for the agent to infer about routing.

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 readOnly/idempotent/closed-world, so safety is covered; the description goes further by disclosing the no-match behavior (response gains coverage_note and tracked_count, framed as a coverage limit rather than a hiring finding) and the 'information, not financial advice' caveat. These are genuine behavioral disclosures, though the long data_contract sentence is closer to output documentation than 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?

Purpose is front-loaded in the first sentence and the paragraphs follow a sensible order: purpose, return shape, call examples, edge case, compliance, bulk routing. It is on the long side — the field-by-field enumeration and the data_contract sentence add bulk — but with no output schema those fields are load-bearing rather than padding.

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, the description carries the full return contract (as_of, per-company fields, derived deltas, coverage_note/tracked_count fallback, data_contract), and the annotations cover safety. An agent has everything needed to call it correctly and interpret the response, including the explicit truncation of scope versus CSV exports.

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 documents the case-insensitive company filter, so the baseline is 3. The description adds real meaning beyond the schema by showing that an omitted company ({}) returns every tracked employer, which the schema does not state since the parameter is optional with no default explained.

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 first sentence states a specific resource (hiring velocity across tracked Bitcoin/crypto-infrastructure employers) and its source of truth (live ATS boards), a topic none of the siblings cover. An agent can tell this is the headcount-velocity tool without comparing schemas against get_etf_flows, get_network_signal or get_sovereign_reserves.

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

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

It gives an explicit usage boundary ('one question, one answer') and routes away bulk, history, backfill and scheduled-pull workloads to the CSV/datapackage at coinbucha.com/data. It also states the two calling modes up front ('{"company": "coinbase"} for one employer, or {} for every employer tracked'), so the agent knows both when and when-not to call 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?

Adds substantial context beyond the readOnly/idempotent annotations: the value is an expected rate derived from difficulty × 2^32 / 600 s read from block headers rather than a measured hashrate, the epoch basis, the disclaimer, and the per-answer data_contract { source, as_of, status, corrections_url, license }. That is exactly the epistemic caveat an agent needs before repeating the number.

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?

Front-loads what the tool is and how the value is derived before the return shape, then ends with scope and legal caveats. The enumerated return fields are long but earn their place given there is no 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?

With no output schema, the description carries the return contract and does so fully: field list with units (hashrate_eh in exahashes per second), basis, difficulty provenance URL, why, and disclaimer, plus the always-present data_contract. An agent can answer without calling blindly.

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?

Zero parameters, so the baseline is 4; the description corroborates this with 'Takes no arguments' and the empty example call, leaving nothing ambiguous about 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?

States a specific resource (Bitcoin network hashrate level and trend) plus the verb-like framing of what it derives from (difficulty, 2016-block epoch). The derivation formula and the 'expected rate, not a measured one' qualifier make it unmistakable against siblings like get_hiring_signal or get_etf_flows.

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 'Takes no arguments' and routes bulk/history/backfill use to the CSVs and datapackage.json, which is clear when-not guidance. It does not, however, distinguish this tool from sibling signal tools such as get_signal_history or scan_signals, so the routing within the server is left inferential.

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?

Goes well beyond the readOnly/idempotent annotations: it discloses free-tier truncation and how `truncated`/`available_points` signal it, guarantees no interpolation to fit a window, describes the `more` field and paid x402 route, and names the data_contract block and disclaimer carried on every answer.

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?

Purpose and ordering are front-loaded in the first sentence, and with no output schema the enumeration of returned fields earns its place. The long inline field list is dense and the bulk-CSV point is made twice (via data_contract.bulk_url and the closing sentence), costing some tightness.

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 history tool with no output schema, it covers return shape, point semantics (0-100 strength, direction enum), truncation behavior, upgrade paths, and provenance fields — everything an agent needs to call and interpret 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 `days` (1-90) and the `signal_type` enum are already fully documented in the schema. The description restates the enum members and gives an example call, which is mildly helpful but adds little semantic meaning beyond the schema — baseline 3.

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?

Opens with a specific verb+resource+scope: 'Dated strength history for one CoinBucha signal, newest first.' It clearly carves out a different role from siblings like get_network_signal or scan_signals, which are point-in-time or scanning tools, and it names the required signal_type enum up front.

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

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

It explains the bounded-question model and routes heavier needs ('bulk, history, backfills and scheduled pulls') to the CSVs/datapackage.json, and tells callers the paid x402 route exists for full series. It never explicitly contrasts with the sibling snapshot tools, so the selection guidance is strong but not fully exhaustive.

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 only cover readOnly/idempotent/closed-world; the description adds substantial behavioral context beyond them: source_quality semantics (primary = confirmed at source, secondary = reported but unconfirmed), the mandatory CoinGecko attribution and source_terms, the per-answer data_contract, and the bounded 'one question, one answer' server policy. This is real disclosure an agent needs to 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?

Front-loaded with purpose and return shape in the first two sentences, with filters and examples after. It is dense but nearly every clause carries information; the attribution/legal boilerplate is the only mildly padded portion, though it is genuinely operationally relevant.

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?

There is no output schema, so the description correctly carries the full burden by enumerating the return envelope and per-row fields (country_name, holdings_btc, tier, source_quality, etc.). Combined with the filter behavior and bulk-data escape hatch, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds usable examples for both parameters and states the default behavior of calling with {} (full ranking), which the schema does not convey. It does not add filtering syntax or multi-value semantics 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?

States a specific resource and scope: 'Nation-state Bitcoin holdings, ranked largest first.' The nation-state qualifier implicitly distinguishes it from the sibling get_treasury_holdings and from sovereign_diff, and the return-shape enumeration confirms exactly what an agent gets back.

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

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

Gives concrete invocation examples ({"country": "US"}, {"tier": 1}, {} for full ranking) and an explicit out-of-scope route ('for bulk, history, backfills and scheduled pulls use the CSVs and datapackage.json'), plus the 'one question, one answer' framing. It never names a sibling tool as the alternative, so the routing to sovereign_diff or get_treasury_holdings is left 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?

Beyond the read-only, idempotent, and closed-world annotations, the description discloses the exact return structure, attribution requirements, source terms, data contract, disclaimer status, and no-argument behavior. This is unusually rich behavioral context for a no-parameter retrieval 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 front-loaded with purpose, then discusses output structure because no output schema exists. It is dense and mostly earns its length, but the very long field enumeration and the unhelpful 'Example: {}.' slightly reduce conciseness.

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

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

With no output schema and no parameters, the description fully carries the burden by defining the return shape, nested exposure fields, attribution, data contract, and bulk-data alternative. An agent has enough information to call the tool and interpret the response.

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 reinforces this by stating 'Takes no arguments,' which prevents the agent from expecting filters or input options.

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 resource and scope: Bitcoin held on the balance sheets of tracked public companies, in aggregate and by largest holder. This clearly differentiates the data domain from siblings such as sovereign reserves or ETF flows, but it does not explicitly name or contrast the sibling tools.

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

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

It gives a clear usage context and an explicit exclusion: for bulk, history, backfills, and scheduled pulls, use the CSVs and datapackage.json. However, it does not explicitly say when to choose this tool over related sibling tools like get_sovereign_reserves or get_etf_flows.

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, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real context beyond them: the mandatory CoinGecko attribution string and source_terms, the observational/'not financial advice' framing, and the one-question-one-answer bounded-query constraint. It stops short of rate-limit or freshness details.

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?

Purpose is front-loaded, then filters, then the inline return shape, then constraints. The return-shape enumeration is long, but it is justified because there is no output schema. Minor redundancy exists between the 'disclaimer' field listing and the standalone 'information, not financial advice' 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?

With no output schema, the description carries the return contract itself and does so thoroughly: top-level fields, per-signal fields (id, type, value, signal_strength, direction, why, sources, as_of), attribution terms, and the data_contract envelope. Nothing an agent needs to invoke or interpret the call correctly is missing.

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% with per-parameter descriptions and an enum for direction, so the baseline is 3. The description goes further by showing a concrete combined filter example ({min_strength: 70, direction: tailwind}) and clarifying that an empty object yields the full ranked list, which is behavior the schema alone does not convey.

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 opening noun phrase 'Ranked cross-signal feed of CoinBucha's leading, non-price Bitcoin indicators' clearly identifies the resource and its aggregate, ranked nature, which implicitly sets it apart from the single-signal siblings (get_hiring_signal, get_network_signal). It never names a sibling explicitly, so the differentiation is inferred rather than stated.

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

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

It gives an explicit when-not-use with an alternative: bulk, history, backfills and scheduled pulls should go to the CSVs/datapackage.json instead of this server. It also explains the default empty call ('{} for the full ranked list') and shows a filter example. The gap is that it never routes the agent among in-server alternatives like get_signal_history.

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

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

Annotations already cover readOnly/idempotent/closed-world, and the description still adds substantial behavior: the insufficient_snapshots edge case (status "insufficient_snapshots" and diff: null, explicitly not an empty diff), required attributions ('Powered by CoinGecko', source_terms), and the data_contract envelope on every answer.

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?

Front-loaded with the core diff purpose and return shape before trailing boilerplate. It is dense with many clauses, and the disclaimer/attribution/paid-route tail is longer than a caller strictly needs, but nearly every sentence carries functional 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?

No output schema exists, so the description carries the return burden and does so thoroughly: the top-level shape, per-row fields (country_code, source_quality, changes[] with field/basis/from/to), the empty-result edge case, and the appended contract envelope. Nothing needed to call and interpret it is missing.

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 both params are documented there, so baseline is 3. The description goes further by supplying default behavior ('defaults to the two newest') and directional meaning (from = earlier, to = later), which the schema only implies, plus a concrete worked example.

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 ('What changed') and resource ('two frozen, immutable sovereign-reserve snapshots'), and the diff framing cleanly separates it from the sibling get_sovereign_reserves (which returns a single snapshot). An agent can pick the diff tool without opening a schema.

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

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

It gives clear trigger context ('between two snapshots', 'defaults to the two newest') and a when-not rule ('for bulk, history, backfills and scheduled pulls use the CSVs and datapackage.json'). It does not name the sibling get_sovereign_reserves as the alternative for single-date reads, so routing between those two is left to inference.

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