scheduling

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

With no meaningful annotations (all hints false), the description carries the transparency burden and does a good job: it discloses inclusivity, the presence of weekend/holiday counts, and the critical 'no holiday calendar' behavior. It does not describe the exact return structure, but the output components are named.

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 purpose is front-loaded, and the crucial no-holiday-calendar caveat is placed immediately after, making the most important limitation easy to notice.

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 moderate-complexity calculation tool with full schema parameter descriptions, the description is largely complete: it states purpose, inclusivity, result components, and the holiday limitation. It does not spell out the exact return format or behavior for edge cases like from > to, but those are not essential for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds context like 'inclusive' and the weekend/holiday-count behavior, but it mostly reinforces the schema rather than adding new parameter-level 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?

The description names a specific action (count), a specific resource (business days between two dates), and the scope (in a place, inclusive). It also states what the result includes (calendar total, weekend count, holiday count), which clearly distinguishes it from sibling time/calendar tools like convert_time or dst_changes.

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 for when the tool is appropriate and explicitly warns that the result is not holiday-adjusted unless holidays are passed. It does not name sibling alternatives or give an explicit 'use X instead' rule, but the limitation is stated strongly enough to prevent misuse.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral details beyond that: weekends are treated as outside working hours, and it also prints the requesting user's own zone from the shared business profile.

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 dense, front-loaded sentences cover the purpose and key behavioral nuances without repetition or filler. Every clause adds information the agent needs.

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

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

With no parameters and safety fully covered by annotations, the description sufficiently explains the return content: contact zones, current local time, working hours, in-hours status, weekend policy, and the caller's zone. Nothing critical is missing for correct invocation.

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

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

There are zero parameters and schema description coverage is complete at 100%, so the baseline is 4. The description correctly focuses on output semantics rather than parameter documentation, and no parameters need clarification.

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 ('List'), the resource ('saved contacts'), and the distinctive output: zone, local time, working hours, and in-hours status. This cleanly separates it from sibling tools like contacts_set and the generic time utilities.

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 makes clear the tool is for listing saved contacts enriched with scheduling-relevant information年代中期 local time and working hours. It does not explicitly name alternatives or exclusions, but the use case is strongly implied and distinguishes it from other siblings.

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

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

All annotations are false, so the description carries the behavioral burden. It discloses persistent saving, return of resolved zone and local time, replacement of same-name contacts, and the free limit of 5. It does not cover error cases or permission needs, but the key behaviors are present and non-contradictory.

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

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

Three sentences, each earning its place: core action, return behavior, and replacement caution plus limit. No fluff, front-loaded with the primary purpose.

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 save tool with no output schema and no helpful annotations, the description covers the essentials: what it does, what it returns, replacement behavior, and the free limit. Minor gaps around error handling and exact response structure are not necessary for correct invocation.

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

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

Schema coverage is 100%, with descriptions for all four parameters, so the baseline is 3. The description adds the notion of zone resolution and working hours, but it does not provide meaningful format or usage details beyond the schema. Marginal added value over the structured fields.

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 action and resource: 'Save one person's zone and working hours' with a clear purpose ('so later calls can name them'). It is immediately distinguishable from siblings like contacts_list (save vs. list) and the time-conversion 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?

No explicit when-to-use or when-not-to-use guidance is given, and no alternative tools are mentioned. The purpose clause implies a use case, but the agent must infer when this tool is appropriate versus siblings like contacts_list or convert_time.

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

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

The annotations carry no positive hints (readOnlyHint is false), so the description carries the behavioral burden and it delivers: it explains that the input is wall-clock in from_zone unless it has an offset or trailing Z, that natural-language times work, and that output includes day-change markers and UTC instant. It does not detail gap/fold resolution, though the schema's parameter descriptions cover those cases.

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 short and front-loaded, with the core action in the first sentence and useful parsing detail in the second. The final example '3pm tomorrow works' slightly duplicates the schema's time examples, so it is not maximally tight, but it is not padding either.

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 no-output-schema tool with natural-language input and DST edge cases, the description gives the essential input semantics and a high-level return shape. It leaves exact output formatting implicit and relies on the schema for gap/fold behavior, which is an acceptable but not exhaustive treatment.

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; the description adds value beyond the schema by clarifying the parsing rule for time ('wall-clock ... unless ... offset or trailing Z') and by specifying that all to_zones are included in the conversion. It adds no new detail for gap/fold, but those already have thorough enum descriptions in the schema.

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

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

The description opens with the specific verb 'Convert' and a precise resource ('one time from from_zone into every zone in to_zones'), making the operation unambiguous. It also distinguishes this from date-time siblings like now, dst_changes, and overlap by stating exactly what it produces: zone conversions with day-change markers and the UTC instant.

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 clear context for when the tool applies: converting a point in time across zones. It does not name alternatives or explicitly state when not to use it, but the conversion-specific wording is enough to route an agent away from the sibling scheduling and business-day 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?

Annotations are all false, providing no safety or side-effect hints, so the description carries the burden. It implies a read-only lookup by describing output (clock changes, UTC instant, offsets), but it does not explicitly state that no changes are made or mention any other behavioral traits such as auth or rate limits. 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 only: the first states the output and scope, the second gives a concrete use case. No filler or redundancy, and the core information 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?

For a simple 2-parameter tool with no output schema, the description adequately explains what is returned (UTC instant, offsets before/after) and the typical use. It doesn't specify whether multiple changes per year are returned together, but 'the clock changes' implies plural. Minor gap but not enough to hinder correct invocation.

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

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

Schema covers both parameters (zone required, year optional) with descriptions. The description adds no extra parameter detail (e.g., zone format or year range). Per the coverage baseline, 3 is appropriate since the schema already carries the semantic weight.

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

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

The description clearly identifies the resource (clock changes in a place for a year) and the output (UTC instant and offsets before/after). The use case ('check whether a recurring call moves') distinguishes it from sibling tools like convert_time and now, though it lacks an explicit verb like 'returns'.

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 'Use it to check whether a recurring call moves for one of you in March or October' provides a concrete, clear context for when to use the tool. It does not mention alternatives or when not to use it, but the guidance is specific enough for an agent to route correctly.

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 all annotation hints false, the description carries the transparency burden. It discloses the returned shape and ranking behavior ('UTC instant with the local time for every participant and a fairness score, best first'), and the verbs 'Rank' and 'Returns' imply a read-only search, though it never explicitly states that no data is modified.

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, front-loaded with the core behavior and no filler. Every clause adds either the ranking rule or the return format.

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

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

The description plus the exceptionally detailed input schema covers behavior, defaults, free-tier limits, and argument semantics. Since no output schema exists, the description's mention of UTC, local times, and fairness score provides the essential return-shape information.

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 schema itself explains defaults, limits, and the fairness-score meaning, e.g., 'distance in hours from 13:00 local'. The description only mentions fairness at a high level and adds little beyond the schema.

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

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

The description opens with a specific action ('Rank the times') and names the resource ('meeting slots') and constraint ('every participant is inside their own working hours'). It also states the return format (UTC instant, local times, fairness score), which distinguishes it from sibling tools like overlap or business_days.

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 no explicit when-to-use or alternative routing, such as naming a sibling to prefer in another case. The intended context is only implied by the tool's name and the 'every participant' phrasing, so an agent must infer when this beats the 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 description adds meaningful behavior beyond the annotations: it writes a file and returns the path, reports the start time in UTC and the caller's zone, stores times in UTC for portability, and notes the 3-files-per-month limit. This gives an agent important side-effect and quota context beyond the bare annotation flags.

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

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

Three concise, front-loaded sentences with no wasted words. The main action and return value come first, followed by a timezone clarification and a quota note; 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?

With no output schema, the description usefully summarizes the return value (path plus start time in UTC and local zone). Combined with the rich parameter schema, this is sufficient for an agent to invoke the tool correctly, though it could go slightly deeper on output 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 description coverage is 100%, so the schema already explains all parameters thoroughly, including gap/fold behavior and attendee handling. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'write a .ics for one meeting' and states the return value. This clearly distinguishes it from siblings like convert_time, overlap, and find_meeting_slots, none of which create calendar files.

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 explicitly says 'Call this tool to write a .ics for one meeting,' which is clear usage guidance. It does not name exclusions or alternatives, but no sibling tool provides the same capability, so that is not a material gap.

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 indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.

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 with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential 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?

For a single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.

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

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

The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in the schema.

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

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

The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.

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

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

The description provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.

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 destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.

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 dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information 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 no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.

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

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

There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.

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 begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.

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 when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use 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?

Annotations are all false and provide no safety profile, so the description carries the burden. It discloses the output structure (zone, local date, time, offset, UTC instant) and input flexibility, which is useful. However, it does not mention side effects, error handling, or behavior on invalid input. It does not contradict the annotations—it simply does not assert read-only—so the contradiction flag remains false.

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

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

Two concise sentences: the first states what the tool does and what it returns; the second lists accepted input formats. No redundant wording, key information is front-loaded, and 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?

The description adequately explains the return value (zone, local date, time, offset, one UTC instant), which is crucial given there is no output schema. It also covers input types. It does not mention limits (e.g., maxItems) or error responses, but for a simple single-parameter tool, these are minor gaps. The tool is well-specified for an agent to call 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 schema already describes the 'zones' parameter with examples (['Warsaw','New York','India']) and has 100% coverage, giving a baseline of 3. The description adds meaning by specifying accepted formats beyond the schema: IANA zones, cities, countries, and abbreviations, which is valuable for an agent deciding what to pass. It thus adds value beyond the schema.

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

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

The description clearly states the verb-like action (current time), the resource (one or more places), and the specific details returned (zone, local date, time, offset under one UTC instant). It also specifies accepted input types (IANA zones, cities, countries, abbreviations), which distinguishes it from sibling tools like convert_time (time conversion) and dst_changes (DST transitions).

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

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

The description implies it is for retrieving current time in multiple places, but it does not explicitly mention when to use this tool versus the sibling convert_time or dst_changes. No alternatives or exclusions are named, leaving the usage context implicit. The tool is simple enough that the purpose implies the use case, but explicit guidance would be clearer.

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 adds a genuinely useful behavioral detail: the overlap is computed on a real date so DST changes that widen or narrow it are reflected. The annotations are all false, so they do not affirm read-only or idempotent behavior; the word 'computed' weakly implies no mutation, but the side-effect profile is not explicitly stated.

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 gives the purpose and the second adds the important DST nuance. The key idea is front-loaded and every word 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 tool with no output schema, the description states the conceptual result ('the window') and flags the main edge case (DST). It does not specify the exact return format, but the schema covers defaults and parameter details, so an agent has enough to invoke it successfully.

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 four parameters. The description adds no parameter-specific meaning beyond the general notion of 'listed place' and 'working hours,' which keeps this at the baseline rather than above 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?

The description clearly states the resource ('the window each day when every listed place is inside working hours') and that it is computed on a real date, so the core purpose is unambiguous. It does not explicitly distinguish itself from siblings like find_meeting_slots or convert_time, but the focus on working-hours overlap makes the intent inferable.

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?

No guidance is given about when to use this tool versus find_meeting_slots, convert_time, or dst_changes. The DST note hints at when the computation may matter, but there are no explicit conditions, exclusions, or alternative tool mentions.

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