Powder to the People Snow Reports

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to cover safety. It adds that the return is a 'full document' and lists id formats, which is useful context, but provides no further behavioral details like pagination or authentication.

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, front-loaded sentence that states the action and then immediately enumerates the parameter formats. No wasted words, and the most critical information (purpose and id syntax) is presented first.

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

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

For a simple read tool with one parameter, no output schema, and annotations covering safety, the description provides the key missing context: the id format examples. It is nearly complete, though it could mention whether the returned document includes content or 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?

Schema coverage is 0% for the single id parameter, so the description must compensate. It does so by listing valid id formats (e.g., resort:slug, history:slug, state:xx), which is essential for correct invocation. Minor gap: it does not explicitly state that an empty id is invalid, though the schema enforces minLength 1.

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 ('Fetch a full document by id') and clarifies the source ('from search results'), which distinguishes it from search or search_resorts siblings. However, it does not explicitly name an alternative tool, leaving the differentiation slightly implicit.

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 phrase 'from search results' implies this tool is used after a search, giving indirect context. There is no explicit guidance on when not to use it or which sibling to choose instead, so usage is only implied.

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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar is low, but the description adds no behavioral context at all — no indication of data freshness, granularity, or what the 'overview' and 'season comparison' actually contain. It neither contradicts nor enriches the 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?

One sentence, front-loaded with the core purpose. The trailing parenthetical is low-value filler that could be dropped without loss.

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 tool with no output schema, the description is adequate but thin: it never characterizes the returned 'overview' (time window, resort breakdown, units), which an agent would need to decide between this and get_state_snow.

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

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

Schema coverage is 100% and the single parameter is documented with an example ('Region slug, e.g. colorado'), so the schema does the heavy lifting. The description only echoes 'for a region slug' and adds the public-site context, which is marginally useful but not new syntax or constraint info.

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 names a concrete resource (regional snowfall) and adds scope beyond the title with 'season comparison for a region slug'. It is clear what the tool returns, but it never differentiates itself from close siblings like get_state_snow or get_resort_snow, leaving the region-vs-state boundary to inference.

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?

There is no when-to-use guidance, no exclusions, and no named alternative, despite four other snowfall tools in the sibling list. The parenthetical about the 'same market dashboard as the public site' is a scope remark, not a routing rule.

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, non-destructive, closed-world, so the safety profile is covered. The description adds that data comes from 'precomputed Convex snapshots,' hinting at cached/stale data, which is useful, but it does not state freshness windows or confirm what is not returned.

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?

One dense sentence with the resource and scope front-loaded, followed by an inline enumeration of the metrics returned. No filler sentences and nothing redundant.

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, and the description compensates by enumerating the returned metrics (24h/7d/10d modeled, season total, % normal, vs last year) and naming the data source. Missing only freshness/staleness specifics for a snapshot-backed 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% and the single 'resort' parameter is documented with an example ('vail'), so the schema carries the load. The description's 'by slug' restates rather than extends the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('snowfall and season comparison for one resort by slug') and scopes it to a single resort, which implicitly separates it from the region/state siblings. It stops short of explicitly naming those alternatives, so an agent still infers the granularity 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 phrase 'for one resort by slug' implies the usage context (single-resort lookup) and contrasts with the region/state siblings in the list, but there is no explicit when-to-use statement, no prerequisites, and no named alternative to route to.

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 read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds meaningful context beyond that: the data is modeled Open-Meteo archive rather than measured, only completed seasons are covered, and the caller is instructed to cite the history page URL.

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?

One dense sentence that front-loads the returned metrics, then tacks on the two operational constraints (completed seasons, citation). Every clause earns its place; there is no 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 no output schema, the description does the work of naming the return fields, and it discloses the modeled-data provenance and season-completeness limit. It stops short of units/measurement system or response shape, which are minor gaps for a single-parameter read tool.

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

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

Schema description coverage is 100% and the single 'resort' slug parameter is documented in the schema with an example ('alta'). The description only repeats 'for a resort slug' and adds no format or lookup guidance, so the schema carries the load — 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?

States a specific retrieval verb and resource, then enumerates exactly what is returned (average annual snowfall, season totals by year, monthly averages, snowiest season). The 'history' framing plus the metric list separates it from the sibling get_resort_snow without needing to open either 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?

The parenthetical 'completed seasons only' implies this is for retrospective/seasonal analysis rather than current conditions, but the description never explicitly contrasts this with get_resort_snow or get_weekly_summary. Usage is inferable from the name rather than stated.

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 and non-destructive, so the safety profile is covered. The description adds genuine value beyond them by disclosing the return shape (image plus a stable, cacheable, embeddable public URL), which is exactly the context an agent needs for a render 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?

One dense sentence, front-loaded with the artifact type and its return payload. Every clause carries information, though the enumerated view descriptions make it slightly long for a single 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 burden of describing the return and does so (image + stable public URL). Combined with 80% schema coverage and full annotations, an agent has enough to invoke it correctly, though metric semantics and error behavior remain implicit.

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 80%, so a baseline of 3 applies, but the description goes further by explaining that view=card shows 5 past + 10 future days with a best-day callout and view=week is a 7-day calendar, and that leaderboards apply to region, state or all resorts. It does not clarify the metric enum or the id format, leaving small gaps.

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 artifact (a branded PNG snow card) and enumerates the three render modes it produces (card, week, leaderboard), so an agent can distinguish it from data-returning siblings like get_resort_snow. The verb+resource+scope are 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?

Explains that the output can be looked at or shown to the user and maps each view/kind combination to what gets drawn, giving clear selection context. It stops short of explicitly naming when to prefer this over get_resort_snow or get_top_snowfall (e.g., 'use when the user wants a visual rather than data').

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, non-destructive, and closed-world, so safety is covered. The description adds genuinely useful behavioral context beyond that: exactly which metrics come back (24h, 7-day, next-7-day forecast, season totals) and the presence of a canonical page URL for citation.

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 with the resource scope front-loaded and the return payload following immediately. No filler, no repetition of the title.

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-value burden and does so well by naming the metrics and the citation URL. It leaves minor gaps: behavior for an unknown/unsupported code and whether the result is empty for states with no tracked resorts.

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

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

Schema coverage is 100% and the sole parameter's description already gives the two-letter format and examples (CO, NY, BC). The description restates 'two-letter code' without adding format, validation, or error behavior beyond what the schema provides, so the baseline of 3 applies.

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 ('every tracked resort in a US state or Canadian province') and enumerates the returned metrics, so the scope is unmistakable. It does not, however, distinguish itself from the sibling get_region_snow, leaving the state-vs-region boundary for the agent to infer.

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 aggregation scope: reach for this when you want all resorts in one state/province rather than a single resort. There is no explicit when-to-use, when-not, or named alternative (get_region_snow, get_resort_snow) to route the agent.

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, non-destructive, closed-world behavior, so the safety profile is fully covered. The description contributes one extra fact beyond them: the data comes from the resort board snapshot. It says nothing about result ordering, the limit cap, or how ties/regions are handled.

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 front-loaded sentence with zero filler; the ranking verb and the three windows are exactly the information needed to select the tool.

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 three-parameter, read-only leaderboard tool with annotations covering safety and an enum documenting the required window, the description supplies enough to call it correctly. Only the limit semantics (default 10, max 25) are left entirely to the schema, which is a minor gap given no output schema exists to explain the return shape.

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 67%: window and region already carry descriptions and window has an enum. The description restates the window values (24h, 7d, season-to-date inches) with slight added meaning but says nothing about the limit parameter or the region slug format. Baseline 3 for mostly schema-covered params 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?

Specific verb (rank) plus resource (resorts) and the three ranking windows, so the agent knows it produces a snowfall leaderboard. It implicitly distinguishes itself from the sibling single-scope tools (get_resort_snow, get_region_snow, get_state_snow) by ranking across resorts, but never explicitly differentiates.

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 ranking framing implies when an agent would reach for this tool, but there is no explicit when-to-use, no when-not-to, and no named alternative among the ten siblings that also return snow data. Guidance is inferred rather than stated.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that the content is the latest snapshot and what categories appear in it, which is useful but not a behavioral trait beyond annotations (no freshness window, caching, or payload format).

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?

One dense sentence, front-loaded with the resource and immediately followed by the returned content categories. No filler, no restatement of the name.

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 burden of describing the return value, and it does so by enumerating the three payload pieces. Minor gap: it doesn't indicate how 'latest' is determined or the data format, but for a zero-param read-only tool with full annotations this is close to sufficient.

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 takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly spends no words on inputs.

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?

Names the specific artifact (weekly report snapshot) plus the concrete contents it returns: bulletin headline and highlight stats with examples (leaders, regions above/below normal). An agent can tell it apart from the per-region/per-resort snow tools by the 'weekly report' framing, though no sibling is named explicitly.

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 only implied by 'Latest weekly' – an agent infers this is the weekly overview versus granular get_region_snow/get_resort_snow calls, but the description never states when to prefer it or what it excludes. No alternatives or prerequisites are mentioned.

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, destructiveHint=false and a closed-world scope, so the safety profile is fully covered and the description can't add much there. What it does add — the returned shape (slug plus display name) — is genuinely useful because no output schema exists. It says nothing about ordering, count, pagination, or whether regions with no resorts appear, which keeps it at an adequate-but-thin 3.

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?

One sentence, front-loaded with the verb and resource, with the return fields appended as useful detail. Nothing is wasted and nothing is buried.

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 parameterless read-only catalog tool, the description covers the essential facts: what is listed and what each entry contains. Minor gaps (ordering, whether the list is exhaustive or filtered by tracked coverage, size) remain, but an agent can call this correctly with what is given.

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 takes zero parameters, which is the stated baseline of 4; there is no parameter semantics for the description to clarify or for the schema to omit.

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 ('List tracked ski regions') and even names the returned fields, so the agent knows this is a catalog enumeration tool rather than a data-fetch sibling. It stops short of a 5 because it never contrasts itself with the many data-retrieval siblings (get_region_snow, get_state_snow, search_resorts), leaving the agent to infer that this is the discovery/ID-resolution step.

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?

There is no when-to-use guidance, no prerequisite, and no reference to any alternative. An agent is not told that this is the natural first call to resolve a region slug before calling get_region_snow, nor when it should prefer search_resorts instead.

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, destructiveHint=false, and notably openWorldHint=false (closed corpus of resorts/regions), so the safety profile is covered. The description usefully adds the return shape (snippets with citations), but does not disclose result limits, pagination, or that the corpus is the built-in resort/region dataset rather than open web.

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, zero filler, with the core purpose front-loaded and the return shape immediately after. Nothing in the text is redundant.

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, fully annotated read-only search, the description covers purpose plus return contents (which matters because no output schema exists). The remaining gap is tool selection against search_resorts and any result-count/paging behavior.

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 a single parameter at 100% schema description coverage, the schema already documents "query" as "Search query". The description adds nothing about query syntax, matching behavior, or the implications of "OpenAI-compatible" formatting, so baseline 3 applies.

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 gives a concrete verb and resource ("search over resorts and regions") plus the response shape (id, title, url, text snippets with citations), so an agent knows what it returns. It does not, however, explicitly differentiate itself from the sibling search_resorts, which overlaps heavily on the "search resorts" surface. Clear purpose, weak sibling disambiguation.

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?

There is no when-to-use statement, no exclusions, and no named alternative despite several overlapping siblings (search_resorts, list_regions, fetch). "OpenAI-compatible" hints at an integration context but gives the agent no routing rule for choosing this over search_resorts.

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, and non-destructive behavior, so the safety profile is covered. The description adds value beyond that by disclosing the return content: compact snow metrics and a citation URL to the public site, which is useful given there is no output schema.

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 tightly packed sentences with zero waste: the searchable fields come first, then the return summary. 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?

For a simple read-only search with no output schema, the description covers what can be searched and what comes back, which is enough to call it correctly. It could go further on result limits or ranking, but 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 the schema already documents all three parameters, including examples for state and region. The description largely restates those fields and adds no format or syntax detail beyond them, making the baseline 3 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 verb (search) and resource (resorts) plus the fields usable for matching, so an agent knows exactly what the tool does. It does not, however, distinguish itself from siblings like `search`, `list_regions`, or the various `get_*_snow` tools, so it falls short of a 5.

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 searchable fields (name, slug, region, state code), but there is no explicit when-to-use statement or reference to alternatives such as `list_regions` for browsing or `get_resort_snow` for a known resort. An agent must infer when this beats a sibling.

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