Horizon AI Intelligence

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

The annotation readOnlyHint=true already signals a safe read operation, and the description adds a critical caveat: 'invisible' means zero pickup in the Western feeds Horizon tracks, not a claim about all media. This prevents misinterpretation of the results. While it doesn't disclose rate limits or response format, the read-only nature and the scope clarification make it adequately 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 moderately sized and front-loads the core purpose in the first sentence, then adds necessary clarification about the measurement scope. It avoids unnecessary fluff and each sentence serves a purpose, though it could be slightly trimmed without losing meaning.

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 tool with a well-defined purpose, documented parameters, and an existing output schema, the description is complete. It explains the ranking and per-region counts, defines the key term 'invisible', and clarifies the corpus limitation. An agent has everything needed to call it correctly and interpret the results.

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?

Both parameters (days and limit) are fully described in the input schema, including defaults and ranges, so the schema does the heavy lifting. The description does not add extra parameter detail beyond what the schema provides, so the baseline of 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 states a specific verb and resource ('Coverage blind spots') and explains exactly what it returns: companies, models, and people covered by regional press but not Western feeds, ranked with per-region counts. It also provides a clear framing question ('what is Western tech media missing right now?') that distinguishes it from sibling tools like get_region_signal or get_china_signal, which focus on specific regions rather than cross-region gaps.

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 useful context by defining 'invisible' within Horizon's corpus and clarifying the measurement scope, but it does not explicitly mention alternatives or state when not to use this tool. It implies a use case (identifying cross-region coverage gaps) but does not compare against siblings like get_region_signal or search_news, so the agent must infer the appropriate choice.

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 annotation readOnlyHint already signals safety. The description adds useful context about the returned signal (ranked by momentum) and its unique coverage of Western-feed blind spots. No hidden behaviors are disclosed, but the output schema covers return format, so this is sufficient.

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

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

Two concise sentences: the first defines the tool's purpose and scope, the second gives actionable alternative guidance. No filler or 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 single-parameter read-only tool with output schema, the description covers purpose, scope, ordering, and when to use the alternative. It is fully sufficient for correct invocation without further external context.

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 fully documents the 'limit' parameter with default and cap (100% coverage). The description does not add extra parameter semantics, but per the rubric, baseline 3 is appropriate when schema covers all 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 identifies the tool as a shortcut for 'get_region_signal' with region 'china', specifying exact geographic scope and example model providers (Qwen, DeepSeek, Zhipu, Moonshot, ModelScope). It also mentions the ranking by momentum, which distinguishes it from broader 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?

Explicit guidance is provided: 'Prefer get_region_signal if you may query more than one region.' This gives a clear condition for when to choose an alternative, making the usage context unambiguous.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context: the briefing is curated, once-daily, synthesized from HN/Reddit and legislative sources, and the full archive is public. No contradictions with annotations.

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

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

Two sentences with no filler: the first front-loads what the tool returns and its sources, and the second handles the alternative tool and date behavior. Every sentence earns its place.

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

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

For a single optional-parameter read-only tool with an output schema, the description covers purpose, sources, behavior, date handling, and the key alternative. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents the optional date parameter. The description restates the date format and archive availability, but adds little beyond what the schema already provides.

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 ('aggregate AI industry briefing') and lists the content categories: top stories, emerging signals, new entrants, and regulation updates. It also names the sibling it is not (get_new_since), so an agent can distinguish it from raw item-level 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 says to use get_new_since instead when raw item-level updates since the last check are needed, making the boundary between the two tools clear. It also explains that any past date can be passed and that omitting it returns the latest briefing.

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 states that the tool is read-only (readOnlyHint: true is already annotated) and gives temporal scope ('over the last 30 days') and data nature (descriptive counts, not a score or judgment). It adds context beyond the annotation, explaining what the tool returns without contradicting the annotation.

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 long, front-loads the key action and entity scope, and avoids fluff. It efficiently conveys purpose, data context, and exclusions. Could be considered slightly dense but not verbose; earns a 4 for being concise and well-structured.

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

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

The tool has only one parameter, complete schema coverage, and a provided output schema. The description explains the tool's purpose, data time window, and what it does not provide, making it complete for an agent to select and invoke correctly. No gaps are present given the simplicity and available structured metadata.

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 documents the 'entity' parameter with examples (e.g., 'Qwen 3.8' or 'Anthropic'). The description adds meaning by clarifying the kind of entity (company, model, or person) and the context of how the data is used (provenance split). Since schema coverage is 100%, the baseline is 3, but the description provides valuable extra semantics, earning a 4.

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

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

The description clearly states the tool's purpose: for one entity (company/model/person), it shows how much claim provenance data is self-reported vs independently evaluated, over the last 30 days. It specifies the verb ('get'), resource ('entity provenance'), and distinguishes from a score or judgment, differentiating it from siblings like get_china_signal or get_topic_signal.

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 when to use this tool ('to answer is the buzz around X coming from X?') and clarifies what it does not do (not a score, not a judgment). It provides clear context but does not explicitly state when not to use it or list alternatives among the provided 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 readOnlyHint annotation, the description discloses ordering (oldest→newest), pagination via nextCursor, the omitted-cursor behavior for starting fresh, content returned (titles, links, topics), and paid-tier restrictions. This is substantial contextual disclosure.

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 action, and every clause provides value. No fluff or redundancy; it achieves high density of useful 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 small parameter surface and the presence of an output schema, the description adequately covers return contents, pagination mechanics, and usage patterns. There are no significant gaps in what an agent needs to know to invoke it correctly.

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

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

The input schema covers 100% of parameter descriptions, so the baseline is 3. The description adds meaningful guidance by explaining the cursor's rollover ('nextCursor for your next call') and clarifying the omit-cursor first-call scenario, earning a 4.

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

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

The description explicitly states 'Incremental poll: raw item-level AI news added since a cursor' with a clear verb and resource, and distinguishes itself from get_daily_briefing. It is specific and unambiguous.

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

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

It provides an explicit use case ('what's new since I last checked') and names the alternative tool for curated synthesis (get_daily_briefing). It also explains the behavior when omitting the cursor, covering initial and subsequent calls.

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 provide readOnlyHint=true, but the description adds substantial behavioral context: items are relevance-scored and ranked by momentum, local-language press is translated to English, and the output includes titles, sources, and links. This goes well beyond the annotation to explain how the tool behaves and what the user receives.

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, front-loading the core purpose, then covering translation and return details. Every sentence contributes distinct information with no redundancy or 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?

With a readOnly hint, a present output schema, and full parameter schema coverage, the description still adds value by explaining the signal's nature (relevance-scored, momentum-ranked), translation of local press, and return fields. It also addresses the relationship to a sibling tool, making it complete for the 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?

Schema coverage is 100% with descriptions for both region (enum) and limit (default/cap). The description adds little beyond the schema—only reiterating the region values and noting that get_china_signal is a preset, which doesn't materially enhance parameter meaning. Baseline 3 is appropriate given the high schema coverage.

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

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

The description clearly states the tool retrieves the current AI signal for a region, enumerates the valid regions (china, korea, japan, eu), and describes the content (recent, relevance-scored items ranked by momentum) along with the return format (titles, sources, links). It distinguishes itself from the sibling get_china_signal by positioning itself as the canonical regional tool with get_china_signal as a preset.

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

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

The description explicitly states it is 'the canonical regional tool' and calls out get_china_signal as a preset for region 'china', directly informing the agent when to use this tool versus an alternative. While it doesn't compare against every sibling, the guidance is clear and actionable for regional signal needs.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful context about the state-bill majority and legislative-stage breakdown, but does not disclose freshness, pagination, or rate-limit behavior. This is adequate but not rich.

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

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

Two sentences with no filler. The main scope is front-loaded, followed by the key usage hint about state bills and jurisdiction filtering. Every clause earns its place.

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

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

With an output schema, no required parameters, and annotations declaring read-only behavior, the description provides all necessary context to call the tool correctly. Jurisdiction options and limit semantics are already in the schema, so nothing essential 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 description coverage is 100%, so both parameters are already documented. The description adds a helpful hint that state bills dominate and that jurisdiction narrows results, but this mostly reinforces the schema rather than adding new meaning.

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: get current AI legislation headlines. It enumerates the jurisdictions (US Congress/federal agencies, US states, UK Parliament, EU) and names the included legislative stages, making it easy to distinguish from sibling news/signal 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?

The description gives clear context on what the tool returns and explicitly suggests using the jurisdiction filter to narrow state-heavy results. It does not name alternative tools or exclusions, but the context is enough to infer when this tool applies.

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 the readOnlyHint annotation covering safety, the description adds meaningful behavioral context by explaining the use of embedding similarity, recency filtering, and the nature of the output. This enriches understanding beyond the annotation alone, without contradiction.

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

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

The description is a single, front-loaded sentence that packs in the core concept ('Semantic more like this'), input requirements, and output contents without any fluff. Every part earns its place.

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

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

Given the tool's low complexity, existing output schema, readOnly annotation, and a clear description covering input source and expected output, there are no significant gaps. The description sufficiently orients an agent on when and how to invoke it.

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 fully documents both parameters (id and limit). The description adds extra meaning by clarifying that the id originates from specific source tools (get_new_since, search_news, or the feed), which complements the schema's generic 'UUID of an item from a previous result'.

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 returns semantically similar items via 'semantic more like this' given an item ID, and explicitly lists the output fields (titles, sources, similarity scores, links). It distinguishes itself from sibling tools by focusing on item similarity rather than new/search/regional signals.

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 conveys when to use it by specifying that the input is an item ID from get_new_since, search_news, or the feed, implying it is for follow-up exploration after retrieving an item. It does not explicitly name alternatives, but the context and sibling list make the usage scenario clear.

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

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

Annotations already declare readOnlyHint, and the description adds behavioral context by explaining the items are relevance-scored and ranked by momentum. This goes beyond the annotation without contradicting it, though it does not cover pagination or rate limits.

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 efficient sentences. The first defines the tool's output and ranking, the second provides a sibling comparison. No wasted words, and the most important info is front-loaded.

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

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

With an output schema present and annotations covering safety, the description adequately explains the tool's purpose and ranking logic. It is complete for a straightforward read-only tool, though it could optionally mention the available topic values.

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 parameter descriptions for both 'topic' and 'limit'. The description does not add significant extra meaning beyond referring to topic as 'subject', so the baseline of 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 what the tool does: retrieves the current AI signal for a topic, defined as recent, relevance-scored items ranked by momentum. It also differentiates from get_region_signal by noting the subject-based slicing, making the purpose distinct and specific.

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 compares the tool to get_region_signal, indicating when to use this over a geographic alternative. This provides clear context, though it does not mention exclusions or other 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?

The annotation readOnlyHint=true already conveys safety. The description adds that it provides coverage details and filtering guidance, which is useful behavioral context. No contradictions, and the added value is appropriate for a simple read-only reference 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?

A single, dense sentence that front-loads the core purpose and immediately states when to use it. Every phrase adds value, with no wasted words. The structure is efficient and 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?

Given the tool has no parameters and an output schema (not shown but present), the description sufficiently covers what the tool does and when to call it. It might benefit from mentioning the exact output format, but the output schema likely handles that. For a simple coverage reference, this is adequately 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?

There are zero parameters, so per guidelines the baseline is 4. The description doesn't need to explain parameters, and no schema coverage issues exist. The description's mention of 'how to filter' hints at output structure without requiring 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's purpose: to describe Horizon's coverage, including ingestion sources, source= filter values, regional lenses, and filtering method. It distinguishes itself from siblings by positioning it as a preliminary call to understand the corpus before querying, making its role unique.

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 states when to call ('Call this to understand the corpus before querying'), which positions it as a first step. It doesn't mention alternatives or exclusions, but the context is clear enough for an agent to know this is a pre-query reference tool.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds behavioral specifics: it returns only the top 3 titles with links, and that advanced features are gated behind a subscription. This goes beyond the structured annotations and provides useful context for the agent.

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

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

The description is two sentences. The first clearly articulates the tool's core function and output; the second states the limitation and upgrade path. Every phrase contributes meaning, with no redundant or filler content.

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

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

Given the simple input (one string), the presence of an output schema, and the read-only annotation, the description is largely complete. It explains the scope ('recent AI news'), result count (top 3), and the subscription boundary. Minor ambiguities like the exact meaning of 'recent' are not critical.

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

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

The input schema has 100% coverage for the single 'query' parameter, describing it as 'Search terms.' The description does not add additional detail about parameter semantics, such as syntax, length restrictions, or examples. With full schema coverage, the baseline of 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?

Description states the tool performs a 'quick teaser search over recent AI news' and specifies the output: 'top 3 matching titles with links.' This is a clear verb+resource pair and distinguishes it from the sibling get_* tools, which are not search tools. The teaser scope is explicit.

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 clearly indicates when to use this tool ('Quick teaser search') and contrasts it with the full-text search capability that 'requires a Horizon subscription.' This implies that for full-text, filters, or history, users should not rely on this tool. However, it does not explicitly name an alternative tool, though none of the siblings fill that role.

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