StyleKit

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

Annotations already cover read-only, idempotent, non-destructive and open-world behavior, and the description adds substantive context on top: licensing/contentLevel gating of source, the structured unavailable error when a remote source is down, the rule that a download URL is not treated as source code, and missingFiles reporting for unmatched paths. This is behavior an agent cannot infer from the annotations or schema.

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

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

Well structured and front-loaded: the retrieval rule comes first, then Args, Returns, and three worked examples. It runs somewhat long and restates the includeSource behavior in two places, but nearly every sentence carries information an agent needs to call the tool correctly.

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 4-parameter read tool with an output schema, the description covers the retrieval contract, licensing limits, failure mode, and size-control strategy. Since an output schema exists it does not need to detail return values, and its brief note about structured JSON plus provenance is sufficient.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further: it explains that kind is the namespace produced by stylekit_list_assets, that id must be exact within that namespace, that files omitted means all files, and that unmatched paths surface as missingFiles. That error semantics for a parameter is 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?

States a specific verb and resource with its scope qualifier: 'Retrieve one public asset by its exact kind and id.' It also routes the agent to stylekit_list_assets for obtaining the kind/id pair. It does not differentiate from specialized siblings like stylekit_get_style or stylekit_get_style_tokens, which overlap with several of the 18 namespaces in the kind enum.

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?

Gives concrete when-to-use guidance: use includeSource:false or files to keep responses small, use files for a subset of template sources, and get kind/id from stylekit_list_assets. It never states when this generic tool should be preferred over the narrower sibling getters, so the alternative-selection rule is left 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds genuinely non-redundant behavior: a five-minute live-cache and a bundled snapshot fallback during outages marked by origin/fallbackReason. This is real operational context beyond the structured fields.

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?

Front-loaded with the core action, then organized into Args, Returns, and Examples sections. Every sentence is useful, though the Returns JSON listing is somewhat redundant given an output schema exists.

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?

It covers inputs, output shape, caching/fallback behavior, an example invocation, and the error case (listing available recipes when the component isn't found). For a 2-param read-only tool with an output schema, nothing an agent needs is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds example values for 'component' ('button', 'card', 'input') and an example mapping ('glassmorphism button' -> slug/component), giving concrete semantics beyond the terse schema descriptions.

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

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

States a specific verb and resource: 'Render a ready-to-use component for a style: the full Tailwind className and JSX code.' It also names a concrete sibling (stylekit_get_style) as the place to discover recipe ids, so an agent can distinguish it from the other stylekit 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?

It explains that components are usually 'button', 'card', 'input' and directs the agent to stylekit_get_style to check recipeIds, which is a useful routing hint. However, it does not address when to prefer this over siblings like stylekit_get_implementation_brief or stylekit_get_shadcn_install, leaving the broader routing to inference.

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

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

Beyond annotations (already covering readOnly/idempotent/non-destructive/openWorld), the description adds genuinely useful traits: the payload is often 30k–60k characters, so callers should anticipate large responses and subset via sections. It also explains that provenance.source (bundled/static/community) is distinct from transport origin and includes an explicit caveat that coverage guidance does not certify visual quality or accessibility.

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?

Front-loaded: purpose, then the warning about payload size, then the subsetting rule. The Args block partly duplicates the schema, but Returns and the two Examples each carry distinct information, so nearly every line 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 two-parameter read tool with a full output schema, the description supplies everything else an agent needs: when to call it, the size hazard, the subsetting lever, the section vocabulary, provenance semantics, and a caveat about what the payload does not guarantee.

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 goes further by enumerating the twelve valid section values inline and repeating the omit-for-full-brief behavior. This gives an agent the selection vocabulary without opening the schema, though it adds no format constraints beyond what is structured.

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 verb and resource: 'Fetch one complete implementation contract before generating UI,' and clarifies the bundled payload (rules, CSS, templates, recipes, tokens). It implicitly differentiates from token/recipe-only siblings by emphasizing the 'in one call' bundle and the optional sections subset, but it never names a sibling tool 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?

It states a clear trigger ('Use this when you need the full rules, CSS, templates, recipes and tokens in one call') and gives a narrowing strategy ('Pass sections to return only identity/provenance plus the parts you need'), reinforced by two concrete examples. It stops short of naming when to prefer a sibling tool such as stylekit_get_style_tokens instead.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds real operational context beyond that: the tsconfig.json prerequisite and the meaning of lookupOrigin/fallbackReason, which tells the agent how slug confirmation may vary.

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?

Front-loaded purpose sentence, then compact Args/Returns/Examples blocks. Every element earns its place; nothing is redundant with the schema.

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

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

With an output schema present, return values need not be explained, yet the description still names the key fields. A single-param, read-only lookup tool is fully specified: purpose, prerequisite, input meaning, and example all covered.

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

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

Schema coverage is 100% and there is only one parameter, so baseline is 3. The description goes further by clarifying slug is a style identifier and demonstrating how a natural-language request maps to a slug value, which the bare schema does not convey.

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

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

States a specific verb and resource: 'Get the one-line shadcn CLI command that installs a style's color theme (light + dark) into a shadcn project.' This separates it cleanly from siblings like get_style_tokens or get_component_recipe without needing the schema.

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

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

Provides a concrete trigger example ('how do I install the synthwave theme?' -> slug: synthwave') and a hard prerequisite (tsconfig.json required or the shadcn CLI errors). It does not name a competing sibling or say when NOT to use it, so it falls short of a 5.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses meaningful behavior: a five-minute live-catalogue cache and a bundled-snapshot fallback marked with origin and fallbackReason. That fallback/origin disclosure is genuinely useful and not derivable from the annotations. The sentence about 'content provenance is separate from origin when returned by the implementation brief' is muddy and undercuts it slightly.

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?

Purpose is front-loaded, which is good, but the full JSON return shape is restated at length even though an output schema exists (redundant), and the provenance sentence is confusing filler. Several lines do not earn their place against the structured fields.

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?

Covers purpose, arg example, fallback/caching behavior, and error handling; with an output schema present it need not explain return values (though it does, redundantly). It is largely complete for a single-parameter read tool, missing only explicit sibling routing.

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

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

Schema description coverage is 100% and the single slug parameter is already documented in the schema, so the baseline is 3. The description adds only extra example values ('glassmorphism', 'neo-brutalist') beyond the schema's example, which is marginal added meaning.

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

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

States a specific verb+resource ('Get one style's full profile') and enumerates the exact fields returned (philosophy, palette, do/don't rules, keywords, availability flags). An agent can distinguish this from siblings like stylekit_get_style_tokens and stylekit_get_component_recipe because it describes the aggregate profile rather than the individual artifact.

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 a usage example ('how should I use neo-brutalist?' -> slug) and notes the error behavior for unknown slugs, which implies when to call it. However it never states when to use this versus stylekit_search_styles (to discover a slug) or the token/recipe/shadcn siblings, leaving the routing to inference.

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 cover the safety profile, but the description goes well beyond them: it discloses the five-minute cache, the bundled-snapshot fallback, the origin/fallbackReason provenance markers, the distinction between content provenance and transport origin, and the failure mode when no tokens exist. That is exactly the extra behavioral context annotations cannot provide.

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?

Purpose is front-loaded in the first clause, followed by well-separated Args/Returns/Examples sections. It is somewhat long for a one-parameter tool and the 'Content provenance is distinct from transport origin' aside is a little verbose, but every section carries signal.

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

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

With an output schema present, the description need not detail return values, and it still supplements them with provenance and fallback semantics. Combined with annotations and examples, an agent has everything required to call this correctly, including the error case.

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

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

Schema description coverage is 100% and the single 'slug' parameter is already documented in the schema; the description's arg line ('style identifier') restates it with only marginally more meaning. With the schema doing the heavy lifting, baseline 3 is appropriate.

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

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

States a specific verb (Get) and resource (a style's design tokens) and enumerates the token categories (border, shadow, typography, spacing, semantic colors, forbidden/required classes), which cleanly separates it from the broader stylekit_get_style sibling. An agent can identify exactly what payload this returns without opening the schema.

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

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

The two examples ('give me the spacing and border tokens for bento-grid') imply usage and the error condition ('no tokens registered') gives a hint about preconditions, but the description never states when to prefer this over stylekit_get_style or the other stylekit_get_* siblings. Usage is implied rather than asserted.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context on top: what parsing it understands (JSX/HTML class attributes, cn()/clsx(), template literals, variant prefix resolution), that rule sources come from a live brief with a five-minute cache and bundled fallback, and that ok is only true for a conclusive static pass while runtime expressions may be inconclusive.

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?

Purpose and usage are front-loaded in the first two sentences, and the args/returns blocks are compact. The structure slips in the 'Examples' block, where two of three bullets are actually parameter notes (strict) and status semantics rather than examples, which is a minor organizational flaw.

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 multi-param linting tool, the description covers parsing scope, rule provenance, caching/fallback reporting, strict semantics, and the pass/fail/inconclusive status model. An output schema exists, so restating the return shape is redundant but harmless, and nothing needed to invoke the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that code may be JSX/TSX, HTML, or a bare class string, and clarifies non-obvious semantics such as 'Required checks cover the whole input, not each element' and that strict only applies to static snippets.

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 opening sentence gives a specific verb and resource: 'Check whether code actually follows a style's rules.' It implicitly separates itself from generation/repair siblings by framing the tool as a verifier, but it never names an alternative sibling (e.g., stylekit_repair_code), so it stops short of full explicit differentiation.

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?

'Use this AFTER generating or editing UI code to verify it matches the style, instead of assuming it does' gives clear workflow context for when to reach for this tool. It also warns 'Only pass components the code is supposed to contain' for checkRequired, but it never names the repair sibling as the follow-up alternative, so there are no explicit exclusions or alternatives.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description still adds substantive behavior: an empty page is a successful result, private kits and unpublished submissions are never listed, and templates with source files can be large. It also enumerates the page envelope fields (count, hasMore, next_offset, availability, contentLevel, license, attribution, provenance), which goes well beyond the annotation baseline.

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?

Front-loaded with purpose, then args, returns, and examples, so the agent can stop reading early. It is somewhat long and the Args block largely restates a schema that is already 100% described, which is mild redundancy rather than waste.

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?

An output schema exists, yet the description still characterizes the page envelope and empty-page case, and it explains the list-then-fetch workflow with the sibling. Nothing an agent needs to invoke this correctly — namespaces, paging, search semantics, scope exclusions — is missing.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by giving concrete kind examples (animation, component-pattern, template, experience-pack) that make the 18-value enum navigable, and it restates the default page size and offset semantics. It does not add much on the query string beyond the schema's own wording.

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

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

States a specific verb and resource ('Browse StyleKit's public asset catalogue') with explicit scope (public only, private kits and unpublished submissions excluded). It also names the paired sibling (stylekit_get_asset) and explains the kind/id handoff, so an agent can distinguish it from fetch-style tools without opening the schema.

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

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

Gives a concrete usage flow: list, then call stylekit_get_asset with the returned kind/id, plus a worked example ('show me a pricing template') and a cost warning about fetching large templates. It does not, however, address the overlap with the sibling stylekit_search_styles even though the query parameter searches names/descriptions/tags, leaving one routing decision to inference.

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?

Goes well beyond the annotations by describing exact transformation behavior: replacements come only from style tokens, variants (dark:/md:/hover:) are preserved, multi-class replacements are deduplicated, cn()/clsx() string literals are rewritten while variable references and interpolation spans are untouched, and spacing/layout/structure are never changed. This is rich context the readOnlyHint/idempotentHint annotations do not convey, and it is consistent with readOnlyHint=true since it returns rewritten code rather than mutating anything.

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?

Front-loads the core action and the routing decision, then adds behavior, args, return shape and examples in a tight structure. Every section earns its place and there is no filler despite the length.

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?

An output schema exists, yet the description still usefully summarizes the return shape (slug, code, edits, unfixed with reasons) and prescribes the correct follow-up action: apply returned code as-is, then manually review unfixed entries. Nothing an agent needs to invoke and use the tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description restates them ('slug: style identifier', 'code: 1-100000 chars source to repair') with no added syntax, format, or constraint detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource+scope: 'Rewrite code that drifts from a style, using the style's own tokens as replacements.' It also explicitly names the sibling it replaces (stylekit_lint_code), so an agent can distinguish it from the linter and other stylekit tools without opening schemas.

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?

Gives explicit when-to-use: 'Use this instead of hand-editing class names after stylekit_lint_code reports violations.' It names the alternative (manual editing) and the triggering condition (lint reports violations), plus an exclusion example noting that an empty edits list with before.status='pass' means no changes should be made.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds substantive behavior beyond them: empty results are not an error, exact matches rank first, full pagination envelope (total, count, hasMore, next_offset null on last page), a deprecated has_more alias, and an optional fallbackReason. That is well past what the annotations convey.

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?

Front-loads purpose, then Args with defaults and constraints, then the return envelope, then three concrete examples. Every block is scannable and none of the sentences are filler.

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

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

An output schema exists, yet the description still summarizes the return shape and the empty-result edge case, plus paging behavior for an openWorld search over a large style catalog. Nothing needed to invoke or interpret the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description meaningfully enriches it: query is documented as case-insensitively matching slug, name, description, tags and keywords, and the defaults/ranges for limit and offset are restated in context of paging. The added matching semantics genuinely go beyond the schema's terse "Keyword to match".

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?

Starts with a specific verb+resource ("Search StyleKit design styles") and immediately specifies the search axes (keyword and/or category) plus ranking behavior for exact slug/name matches. This cleanly separates it from the get_* siblings that retrieve a single known style.

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 closing line names an explicit alternative and the condition that selects it: "For full tokens of one style, use stylekit_get_style_tokens instead." The example block also maps natural-language intents ("find a glassy frosted style", "next page of retro styles") onto concrete calls, so an agent knows both when to use this tool and how to apply it.

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