Server Quality Checklist

Tool Scores

• add_meal_plan_eventC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the core action ('Schedule'). It lacks disclosure of mutation behavior (does it overwrite existing events?), validation rules (must recipe exist first?), or idempotency characteristics critical for a calendar scheduling tool.

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

  Conciseness5/5

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

  Single sentence with zero waste. Key verb 'Schedule' front-loaded, followed by content options and location. Every word serves a distinct purpose in conveying the tool's function.

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

  Completeness2/5

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

  Given 5 parameters with complex conditional logic (recipe_id/name vs title) and no output schema or annotations, the description is incomplete. It omits success/failure behaviors, return value structure, and whether the operation is idempotent or destructive—essential context for calendar mutation operations.

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

  Parameters3/5

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

  Schema description coverage is 100%, establishing baseline 3. The description adds high-level mapping ('recipe or titled event') that clarifies the parameter grouping logic, but doesn't add syntax details, format examples, or validation constraints beyond what the schema already provides.

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

  Purpose4/5

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

  The description uses specific verb 'Schedule' with clear resource 'meal plan calendar' and distinguishes content types ('recipe or titled event'). It effectively differentiates from sibling 'add_*_list' tools by using domain-specific terminology ('schedule' vs 'add', 'calendar' vs 'list').

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

  Usage Guidelines2/5

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

  No guidance provided on when to use recipe_id vs recipe_name vs title, nor when to use get_meal_plan first to check existing events. The parameter relationships (mutually exclusive options) are undocumented, leaving agents to infer from schema descriptions alone.

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

• get_list_itemsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description lacks critical details: return format, behavior when list_name doesn't exist, or whether results are paginated for large lists.

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

  Conciseness5/5

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

  Extremely concise at 7 words in a single sentence. No filler words or redundant information. Immediately front-loaded with the action and target resource.

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

  Completeness3/5

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

  For a single-parameter read operation, the description meets minimum viability but has clear gaps. Without an output schema or annotations, it should at least mention error conditions (e.g., list not found) or return value structure to be complete.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema fully documents the list_name parameter. The description adds minimal semantic value beyond the schema, merely referencing a 'specific shopping list' without adding format constraints, examples, or validation rules.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('items on a specific shopping list'). It implicitly distinguishes from sibling 'get_lists' by specifying 'items' versus lists, though it could explicitly clarify this distinction.

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

  Usage Guidelines2/5

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

  No guidance provided on when to use this tool versus alternatives like 'get_lists' (which retrieves the lists themselves). Does not mention prerequisite steps like obtaining the list_name or error handling if the list doesn't exist.

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

• get_recipe_detailsA
  3.6/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It compensates partially by disclosing return content (ingredients, preparation steps) since no output schema exists. However, it omits safety properties (read-only), error behavior (not found), and whether partial name matches return single or multiple results.

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

  Conciseness5/5

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

  Two efficiently structured sentences with zero waste. First sentence front-loads the action and return value; second covers parameter usage. Every word earns its place.

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

  Completeness4/5

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

  Appropriate for tool complexity. Without an output schema, the description usefully enumerates what 'details' include (ingredients, steps). Could improve by noting error cases or search behavior, but adequate for a simple lookup tool.

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

  Parameters3/5

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

  Schema has 100% description coverage (case-insensitive partial match vs exact lookup), establishing baseline 3. Description reinforces the lookup methods ('name or ID') but adds no additional semantic context beyond what the schema already provides.

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

  Purpose4/5

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

  Clear verb (Get) + resource (recipe details) and scope (ingredients, preparation steps). Implicitly distinguishes from sibling 'get_recipes' by specifying 'specific recipe' and 'full details', though it doesn't explicitly name the alternative.

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

  Usage Guidelines3/5

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

  Provides lookup method guidance ('Look up by name or ID'), implying the two identification options. However, lacks explicit when-to-use guidance versus 'get_recipes' and doesn't clarify that at least one parameter is required despite the schema showing zero required fields.

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

• get_listsA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. While 'List' implies a read-only operation, the description lacks crucial behavioral details: authentication requirements, rate limits, pagination behavior, or the structure/format of the returned list data.

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

  Conciseness5/5

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

  Single sentence of eight words with zero redundancy. Information is front-loaded and every word serves a purpose in defining scope and resource.

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

  Completeness3/5

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

  Adequate for a simple parameterless tool, but gaps remain: without an output schema, the description should ideally specify what list attributes are returned (IDs, names, metadata). However, given the low complexity, it meets minimum viability.

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

  Parameters4/5

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

  The input schema has zero parameters, which establishes a baseline score of 4 per evaluation guidelines. The description appropriately signals no filtering capabilities by stating 'all' lists.

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

  Purpose5/5

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

  The description uses specific verb 'List' with clear resource 'shopping lists' and scope 'in the AnyList account'. It effectively distinguishes from sibling 'get_list_items' by specifying 'all shopping lists' (plural, account-level) versus items within a specific list.

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

  Usage Guidelines3/5

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

  Usage is implied by the name and description (use when you need to retrieve all lists), but there are no explicit when-to-use guidelines, prerequisites, or contrasts with alternatives like 'get_list_items'.

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

• add_item_to_listA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully documents the duplicate-checking behavior, but omits other critical mutation details such as error handling when lists don't exist, authentication requirements, or what constitutes a duplicate match.

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

  Conciseness5/5

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

  The description consists of two highly efficient sentences with zero waste. The first sentence establishes purpose immediately, while the second adds behavioral context. Every word earns its place.

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

  Completeness4/5

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

  Given the tool's simplicity (3 flat parameters, 100% schema coverage, no output schema), the description is adequately complete. It covers core functionality and key behavior (duplicate checking). Minor gaps remain regarding error conditions and return values, but these are less critical for a straightforward mutation operation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already comprehensively documents all parameters including quantity examples. The description adds minimal semantic value beyond the schema, though 'freeform' slightly clarifies the item_name parameter's nature. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific action ('Add'), resource type ('freeform item'), and target ('shopping list'). The term 'freeform' effectively distinguishes this tool from sibling tools like 'add_ingredients_to_list' and 'add_recipe_ingredients_to_list' which imply structured data.

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

  Usage Guidelines3/5

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

  The description provides implied usage guidance through the 'freeform' designation, suggesting use for arbitrary text items rather than structured ingredients. However, it lacks explicit when-to-use guidance or named alternatives (e.g., 'use this instead of add_ingredients_to_list when items are not from a recipe').

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

• add_ingredients_to_listA
  4/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses critical deduplication logic ('each ingredient is only added once') and default list behavior ('Defaults to the Groceries list'). Missing error handling behavior and return value description.

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

  Conciseness5/5

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

  Two well-structured sentences with zero waste. First sentence establishes core purpose; second covers default behavior and deduplication. Information is front-loaded and appropriately sized for the tool's complexity.

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

  Completeness4/5

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

  Adequate for a 3-parameter tool with no output schema. Covers purpose, defaults, and deduplication. Deducted one point because it fails to clarify parameter relationships (whether recipe_names and recipe_ids are alternatives) and provides no return value information.

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

  Parameters3/5

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

  Schema has 100% description coverage, establishing baseline 3. Description reinforces the default list value but does not add syntax details or clarify the relationship between 'recipe_names' and 'recipe_ids' parameters (mutually exclusive vs. complementary).

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

  Purpose5/5

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

  Description provides specific verb ('Add'), resource ('ingredients from multiple recipes'), and scope ('at once'). The phrase 'multiple recipes' effectively distinguishes this from sibling tools 'add_ingredient_to_list' (singular) and 'add_recipe_ingredients_to_list' (likely single recipe).

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

  Usage Guidelines3/5

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

  Implies batch usage through 'at once' and 'multiple recipes', but does not explicitly state when to use this versus siblings like 'add_recipe_ingredients_to_list' or 'add_item_to_list'. No explicit exclusions or prerequisites mentioned.

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

• get_recipesA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of disclosing what the tool returns, specifically listing the output fields (name, rating, cook time, etc.) to compensate for the missing 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.

  Conciseness5/5

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

  Three well-structured sentences with zero waste: purpose declaration, return value disclosure, and parameter usage guidance. Information is front-loaded appropriately.

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

  Completeness4/5

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

  For a low-complexity tool (1 optional parameter, no nesting), the description is complete. It adequately compensates for missing annotations and output schema by describing return values, though explicit differentiation from get_recipe_details would strengthen it further.

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

  Parameters3/5

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

  With 100% schema coverage, the baseline is 3. The description mentions the optional search parameter but adds minimal semantic meaning beyond the schema's existing description of 'Optional text to filter recipes by name (case-insensitive)'.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and resource ('saved recipes from the AnyList account'), clearly distinguishing it from sibling tools like get_recipe_details (singular details) and get_lists (shopping lists).

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

  Usage Guidelines3/5

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

  It provides implied usage by explaining the search parameter's purpose, but lacks explicit guidance on when to use this bulk listing tool versus get_recipe_details for detailed single-recipe retrieval.

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

• add_ingredient_to_listA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full behavioral disclosure burden. It successfully explains the fuzzy matching behavior ('Matches existing items or recent items by name') and AnyList categorization system integration, adding valuable context beyond the schema. However, it omits whether the operation is idempotent, what happens if the ingredient isn't found in the recipe, or return value details.

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

  Conciseness5/5

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

  Two sentences with zero waste: the first front-loads the core action and scope, while the second adds essential behavioral context about the matching algorithm. Every word earns its place; no redundancy or filler present.

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

  Completeness4/5

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

  Given 100% schema coverage and the tool's moderate complexity (6 parameters with interrelationships), the description adequately covers the essential operational logic and matching behavior. Minor gap: no output schema exists, and the description doesn't indicate return values or success/failure signaling, though this is partially mitigated by the straightforward 'add' operation pattern.

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

  Parameters4/5

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

  Schema coverage is 100%, establishing a baseline of 3. The description adds semantic value by clarifying the relationship between parameters—specifically that 'ingredient_name' is matched against recipe ingredients and sourced from the recipe identified by 'recipe_name'/'recipe_id'. This contextual linkage exceeds the raw schema definitions.

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

  Purpose5/5

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

  The description provides a specific verb ('Add'), resource ('specific ingredient'), source ('from a recipe'), and target ('shopping list'). The use of 'specific ingredient' effectively distinguishes this singular operation from sibling tools 'add_ingredients_to_list' (plural) and 'add_recipe_ingredients_to_list' (bulk), while 'from a recipe' differentiates it from 'add_item_to_list' (generic items).

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

  Usage Guidelines3/5

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

  The description implies usage context through 'from a recipe,' suggesting it requires recipe context, but lacks explicit guidance on when to use this versus 'add_recipe_ingredients_to_list' (all ingredients) or 'add_item_to_list' (manual entry). No alternatives or prerequisites are explicitly stated.

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

• add_recipe_ingredients_to_listA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: the duplicate-checking logic (skips existing, unchecks checked-off items) and default list targeting. It could be improved by mentioning error conditions or what happens if both recipe_name and recipe_id are provided.

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

  Conciseness5/5

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

  Three well-structured sentences with zero waste: first establishes the core action, second covers defaults, third explains behavioral specifics (duplicate handling). 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.

  Completeness4/5

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

  Given the simple flat schema with 3 parameters and no output schema, the description is nearly complete. It covers the primary function, default behavior, and side effects. Minor gap: it does not clarify the logical requirement that at least one of recipe_name or recipe_id must be provided (since both are marked optional in the schema).

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

  Parameters3/5

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

  Schema description coverage is 100%, providing detailed descriptions for all three parameters (recipe_name, recipe_id, list_name). The description reinforces the default 'Groceries' behavior but does not add significant semantic meaning beyond what the schema already provides, which 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.

  Purpose5/5

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

  The description clearly states the specific action (Add), source (all ingredients from a single recipe), and target (shopping list). It effectively distinguishes from siblings like 'add_ingredient_to_list' and 'add_item_to_list' by specifying the recipe-to-list workflow.

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

  Usage Guidelines4/5

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

  The description implies the use case through 'from a single recipe' and mentions the default 'Groceries' list, providing clear context. However, it does not explicitly state when to use this versus 'add_ingredients_to_list' or clarify that at least one recipe identifier (name or ID) must be provided since both are optional in the schema.

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

• get_meal_planA
  4.2/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Discloses default date range behavior (Mon-Sun). However, lacks disclosure of rate limits, empty result behavior, or data freshness guarantees expected for a read tool with no safety annotations.

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

  Conciseness5/5

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

  Three sentences optimally structured: purpose first, defaults second, usage recommendation third. No redundancy or filler; every sentence earns its place with actionable information.

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

  Completeness4/5

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

  For a 2-parameter read tool with 100% schema coverage, description adequately covers purpose, defaults, and usage patterns. Minor gap: does not describe return value structure (though no output schema exists to reference).

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

  Parameters4/5

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

  Schema coverage is 100% (baseline 3). Description adds semantic value by framing defaults as 'current week (Mon-Sun)' and providing concrete usage pattern 'start_date 6 weeks ago' that illustrates how to construct date ranges for pattern analysis.

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

  Purpose5/5

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

  Specific verb 'Get' + resource 'meal plan events' + scope 'date range'. Clearly distinguishes from sibling 'add_meal_plan_event' (mutator vs reader) and 'get_recipes' (events vs recipes).

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

  Usage Guidelines4/5

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

  Provides explicit positive guidance: 'Use a 6-week lookback... to understand recent eating patterns when recommending new meals.' Includes concrete example (6 weeks). Does not explicitly name alternatives to avoid, but clear differentiation from sibling tools.

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