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

With no annotations, the description carries the full behavioral burden. It states 'Never silent-deletes' and mentions 'recoverable path,' explicitly disclosing the non-destructive, reversible nature 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 three concise sentences with no redundant or vague language. Each sentence adds specific value: what the tool does, how the default works, and how to trigger the actual action with a safety note.

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

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

Given the simple parameter set, the description covers the tool's behavior, default mode, explicit action trigger, and a key safety guarantee. No output schema is needed, and no additional context appears 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?

The single parameter 'apply' is fully described, including its boolean effect and default value (false = dry-run). Schema coverage is 100%, and the description adds meaningful context beyond the schema type.

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?

Clearly states the tool lists idle and shadowed user-tier skills and, with apply:true, archives them. The verb 'List' plus the archive action are both explained, making the purpose unambiguous despite the name.

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

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

Provides explicit usage instructions: default dry-run reports what would move, and apply:true triggers the archive. Lacks an explicit comparison to sibling tools, but the self-contained guidance is sufficient for a user to know when and how to invoke 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?

The description discloses persistence scope and precedence ('Default global. Priority: session > project > global') and where data is stored for project and global scopes. However, with no annotations provided, it carries the full burden and still does not clearly explain side effects such as overwriting existing bindings or exactly what clearing does beyond the phrase 'to clear'.

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 uses separate sentences for distinct details, making it easy to scan. It includes scope paths and clear behavior without excessive verbosity, though the telegraphic style makes some phrases like 'Max 3' underexplained.

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

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

With no output schema and no annotations, the description needs to be self-sufficient, but it leaves important gaps: the purpose of the 'reasons' parameter, the exact meaning of 'none', and what the tool returns or changes are not explained. It is not complete enough for an agent to confidently invoke the tool in all intended scenarios.

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%, so the description must compensate, but it only partially explains parameters. It covers clear and scope, and loosely references 'name/description/path only' and 'Max 3' for names, but it does not explain the 'none' property clearly and completely omits the 'reasons' object parameter.

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 says 'Persist lean binding' and mentions clearing and scope, which gives some sense of the action, but it never explicitly states that the tool binds skills to a scope or what a 'binding' represents. 'Max 3' is ambiguous and could refer to the number of skills or entries. It is distinguishable from siblings like list_skills and read_skill, but not as crisp as it could be.

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 parameter-level instructions such as 'Pass clear:true or none to clear' and scope options, but it does not state when to use bind_skills versus alternatives like get_binding or write_host_contract. There is no explicit guidance about the intended use case or when a binding should be created.

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 explicitly states 'Never mutates' and 'Dry-run only,' which are key behavioral traits indicating the tool is read-only and safe to invoke. This transparency helps an agent understand side effects without needing 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?

The description is brief and to the point, covering the essential aspects (dry-run, check items, non-mutating) in a compact form. It avoids redundancy, though the term 'shadowed' might be unclear to some users, slightly reducing clarity.

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?

While the description explains the tool's function and side-effect profile, it does not mention the output format or return value. For a diagnostic tool, this omission could leave an agent uncertain about what to expect, making the description somewhat incomplete.

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

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

The tool has no parameters, so schema coverage is effectively 100%. The description does not need to explain any parameters, and adding more would be superfluous. The baseline of 3 applies here as there are no parameter details to clarify.

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

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

The description clearly states the tool's function as a dry-run check for skill roots existence, counts, shadowing, and binding path. It uses a specific verb ('check') and identifies the resource (skill roots/binding path), making its purpose understandable even without additional context.

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 mentions 'Dry-run only' and 'Never mutates,' which implies it is for non-destructive diagnosis, but it does not explicitly compare to sibling tools like get_binding or why. There is no guidance on when to prefer this tool over others, leaving the usage context implicit.

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?

No annotations are present, and the description does not disclose side effects, read-only nature, performance implications, or any behavioral details beyond the core function. The tool's behavior is largely unspecified.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the primary action and mode options.

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

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

Given the lack of annotations and output schema, the description is incomplete. It does not explain the return format, whether the estimate is per skill or aggregate, or any error conditions, leaving an agent uncertain about the outcome.

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 description partially clarifies parameters by indicating 'one/many/all' for name/names and 'mode: body|description', adding value over the bare schema. However, it does not define the exact meaning of each mode, how to specify 'all', or the relationship between name and names.

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 action ('Estimate tokens') and the resource ('skills'), with a mode parameter indicating body or description. This distinguishes it from sibling tools like list_skills or bind_skills.

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 no guidance on when to use this tool versus alternatives. It does not mention conditions such as needing token counts before binding or when to choose a specific mode.

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 explains what the tool returns, including the host contract and the layered resolution. With no annotations, this provides useful behavioral context, though it does not mention side effects, errors, or authentication requirements.

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 sentences, each adding meaningful information: what it returns, default behavior, and scope usage. No redundant or vague phrasing.

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

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

Given the simple tool and no output schema, the description adequately covers the purpose, defaults, and parameter behavior. It could be more explicit about the exact output format, but it is sufficient for selecting and invoking the 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?

The single optional scope parameter is explained beyond the schema: it specifies which layer to inspect, and the default is the resolved binding. The enum values are self-explanatory in context.

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?

Clearly states the tool returns the current lean skill binding, with a specific verb ('Return') and object. It is distinct from sibling tools like bind_skills and list_skills by focusing on the binding state.

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 the default behavior (resolved binding with precedence) and how to inspect a specific layer via the scope parameter. However, it does not explicitly say when to prefer this over sibling tools such as list_skills or read_skill.

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 no annotations, the description carries the burden of explaining behavior. It discloses a notable behavior: including shadowed duplicates with an explanation ('why'). This is more than a generic 'list' and gives the agent expectations about the output's richness, though it does not specify output format or side effects (which are likely none).

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

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

The description is a single, concise sentence that packs essential details: the action (catalog), the target (local SKILL.md skills), the scope (configured roots), and a key feature (include shadowed duplicates with why). No unnecessary words or redundancy.

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

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

The description conveys the tool's core functionality and scope, and the absence of parameters and output schema keeps it simple. It could be more explicit about the output format or the meaning of 'why', but for a listing operation it is largely complete.

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

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

The input schema has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters since none exist, and it does not mislead about them.

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

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

The description clearly states the tool catalogs local SKILL.md skills from configured roots, and specifically mentions including shadowed duplicates with reasons. This distinguishes it from sibling tools like suggest_skills or bind_skills, making its purpose 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?

The description gives clear context about what the tool does—listing skills from configured roots—so an agent knows when to invoke it for enumeration. It does not explicitly contrast with alternatives, but the name and action are self-explanatory enough for most use cases.

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?

No annotations are provided, so the description carries the burden. It mentions a risk (routing fight) and explains the effects of the boolean, but does not detail side effects, permissions, or where the overrides are written.

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, dense with useful information: purpose, behavior for true/false, and a risk warning. No filler or redundancy.

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

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

For a single-boolean-parameter tool with no output schema, the description covers the action, the rationale, and a risk. It could mention what 'prior host file' refers to, but overall it is sufficiently complete.

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

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

The parameter schema already has 100% coverage with a clear description of 'enabled'. The tool description repeats the same semantics without adding new information, 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?

The description clearly states the action (write Claude skillOverrides name-only) and the purpose (to avoid dumping every skill description in the host listing). This distinguishes it from sibling tools like list_skills and read_skill.

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 implies when to use the tool (to slim down host listing) and explains the two states (enabled true/false), but does not explicitly contrast it with alternatives or 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?

With no annotations, the description carries full responsibility. It only states what is read, but doesn't disclose behavior on missing names, errors, or side effects, leaving the agent to infer basic read semantics.

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 concise sentence efficiently conveys the purpose and key constraint, with no redundant wording.

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 operation, the description is adequate, but it lacks detail on edge cases (e.g., missing skill, empty body) and does not clarify what 'opt-in' entails in practice.

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 provides no description for 'name', and the tool description only says 'explicit skill name' without clarifying format, case sensitivity, or expected values. Schema coverage is 0%, so the description must compensate but only minimally does.

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

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

The description clearly states the tool reads the full SKILL.md body by explicit skill name, with a specific verb and resource. It distinguishes itself from leaner alternatives, though it doesn't name them 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?

The phrase 'opt-in; other tools stay lean' implicitly suggests using this when full contents are needed, but it doesn't explicitly name sibling tools or specify conditions for choosing this over list_skills or others.

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 discloses the side effect (updating the in-memory catalog) and specifies that it does not restart the MCP process, which satisfies transparency for a non-destructive operation. It does not mention potential performance implications, but the key behavioral aspects are covered.

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 concise, using two sentences that efficiently convey the action and its effect. There is no redundant information or unnecessary detail.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is complete enough for an agent to understand the purpose, the action taken, and the resulting state. It covers all necessary contextual 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?

With zero parameters, the description does not need to explain parameter semantics. The baseline for 0 parameters is 4, and since there are no parameters to describe, the score is appropriate.

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

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

The description clearly states the specific action ('rescan skill roots') and the resource (the in-memory catalog), and it differentiates from sibling tools by noting the effect on list_skills and suggest_skills. This makes the purpose unambiguous and distinct.

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 when to use this tool (after skill changes to update the catalog) and indicates that list_skills and suggest_skills will reflect changes, but it does not explicitly mention alternatives or exclusions. The context is clear, though not exhaustive.

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

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

No annotations are present, so the description carries the burden of disclosing behavior. It says the tool 'Returns reasons and dropped (cap/budget)' and uses the verb 'suggest,' which implies a read-only ranking operation, but it never explicitly states that it has no side effects or does not modify skills.

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

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

The description is a single, compact sentence that conveys the core behavior, constraints, and return highlights without unnecessary words.

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 mentions that returns include 'reasons and dropped (cap/budget),' but it does not fully specify the result shape or how the ranked skills are represented. This is adequate for a simple tool but leaves some ambiguity.

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 both parameters, including the default budget and the cap constraint. The description adds 'CJK-aware' and repeats the hard cap, but it does not substantially deepen parameter understanding 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 tool's purpose: 'Lexically rank skills for a prompt.' This uses a specific verb and object, and is distinct from sibling tools like list_skills or bind_skills.

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 constraints like 'Hard cap 3' and a default token budget, but does not explain when to use this tool versus alternatives such as list_skills, bind_skills, or estimate_tokens. There is no explicit when-to-use or when-not-to-use guidance.

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 no annotations, the description carries the full burden of disclosing behavior. The action 'Explain' clearly indicates a read-only operation with no side effects, which is transparent enough. However, it does not explicitly state that it makes no changes, though this is strongly implied.

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

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

The description is a single, short sentence that is direct and free of extraneous detail. It is well-structured and immediately conveys the tool's function without any fluff.

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

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

Given the simplicity of the tool (no parameters or output schema), the description fully covers what an agent needs to know to invoke it correctly. It is self-contained and does not require additional context about return values or side effects.

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

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

The tool has zero parameters, and the schema coverage is 100% (since there are no parameters to describe). The description adds no parameter-related meaning, and the baseline score of 3 applies because there is nothing beyond the schema to clarify.

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

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

The description clearly states the tool's purpose: to explain why current skills are bound. This is a specific verb ('Explain') and resource ('current skills'), distinguishing it from siblings like list_skills (which lists) or bind_skills (which binds). It is unambiguous and concise.

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 no guidance on when to use this tool versus alternatives such as get_binding or doctor. It does not mention any prerequisites or typical scenarios, leaving the agent to infer usage from the tool name and sibling context.

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 discloses the primary side effect—writing files and forbidding unbound skills—but does not clarify whether existing files are overwritten, appended, or require a pre-existing contract. With no annotations, more detail on the write behavior would be expected.

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, highly concise, and immediately states the action and outcome without extraneous details.

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 no output schema, the description adequately covers the tool's purpose and effect. It lacks context on what 'current binding contract' refers to, but that may be domain-specific and not required for basic usage.

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

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

The input schema has zero parameters, so the description does not need to explain parameter semantics. Baseline of 4 is appropriate.

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

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

The description clearly states the tool writes the current binding contract into specific files (CLAUDE.md and .cursor/rules) and explains the content (list only bound skills, forbid others). This distinguishes it from sibling tools like bind_skills or list_skills.

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 guidance on when to use this tool versus alternatives. While 'in one shot' hints at convenience, there is no mention of conditions that would make this preferable to, say, bind_skills or manually editing files.

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