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

With no annotations, the description carries the full burden and does so: it discloses the unlock ladder, that it writes to disk, that it never overwrites an existing file, that failures return an 'Error: ...' string, and that a successful call may make one GitHub GET (cached, User-Agent only, nothing installed). Network egress and privacy implications of the update check are spelled out explicitly, which is exactly the kind of context annotations could not supply here.

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 core purpose and the grab_site alternative are front-loaded, which is right. However, the update-check explanation runs four sentences and restates 'at most once per 24 hours' twice, which is disproportionate for an incidental cross-cutting concern on an asset-download tool.

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

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

For a 2-parameter tool with an output schema present, the description covers the write destination, overwrite policy, failure representation, and an unexpected network side effect. An agent has everything needed to invoke it correctly and predict 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?

Schema coverage is 0%, so the description must compensate, and it largely does for out_dir: it is a relative folder inside the working directory, falls back to SEARCHTS_MCP_OUT_DIR, and existing files are never overwritten. The url parameter is only described as 'its direct URL', leaving format expectations (absolute vs relative, auth) to inference.

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 ('Download a single asset file... image, PDF, font, CSS, any file') plus the side effect (save to disk) and the return shape {path, content_type, bytes}. It explicitly differentiates itself from the sibling grab_site, so an agent can route without opening either schema.

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

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

Gives an explicit selection rule: 'Use this for one specific file by its direct URL; to pull a whole page's assets at once use grab_site instead.' It also names the escape hatch for the update check (SEARCHTS_NO_UPDATE_CHECK=1), covering both when-to-use and how to suppress a side behavior.

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 exist, so the description carries the full burden, and it does: no arguments, no web requests beyond a cached update check, exactly one GET to the named GitHub endpoint at most once per 24h cached in a named path, no user data in the request, nothing installed or changed, and an env var to disable it. This is unusually complete disclosure of side effects and constraints.

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 usage guidance, then output format, then the update-check caveat – a sensible ordering. It is somewhat long and the update-check/exfiltration-assurance passage is dense, but each sentence carries distinct operational value (callability, output shape, network side effect).

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?

Although an output schema exists, the description still adds essential semantics the schema cannot: plain-text one-line-per-channel report with ok/warn/error prefixes, never wrapped, indented fix commands copy-ready as-is, and the optional update_available field. Combined with the network/side-effect disclosure, an agent has everything needed to call it and interpret results.

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?

Zero parameters, which is the baseline-4 case, and the description reinforces it ("Takes no arguments"), confirming the agent need not construct any input. No further parameter meaning is needed, so it stops short of 5 only because there is nothing extra to add.

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 ("Report the health of this searchts install") and enumerates what health means: unlocker tiers, search providers, platform integrations, each installed/configured/working. This clearly distinguishes it from siblings like login_status (auth only) and web_search (query execution).

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?

Explicit when-to-use: "Use this first when another searchts tool fails or before relying on an optional capability (e.g. keyed search providers, transcription)." Names concrete triggering conditions and future-facing intent, not just a vague hint.

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 provided, the description carries the full behavioral burden and does so thoroughly: it explains folder collision handling, asset caps, omitted-URL reporting, cap-related return fields, error strings, and the update-check side effect. It even warns the agent not to claim completeness without reading the omitted list.

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 front-loaded with the core action and alternative, then packs useful operational details compactly. However, the update-check paragraph is quite long and includes implementation details that could be shortened without losing essential guidance.

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 complexity, five parameters, no annotations, and an existing output schema, the description is complete. It explains saving behavior, output artifacts, caps, failure mode, and even the side-effectful update check, so an agent has enough context to call it correctly.

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

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

Schema description coverage is 0%, but the description compensates for every parameter: url is the page to grab, read optionally saves page.md, out_dir controls the output folder, max_assets caps saved files, and max_tokens caps retained design tokens. It adds defaults and behavioral meaning well beyond the bare schema.

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

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

The description uses a specific verb and resource: it saves files/assets from a page that a read already named, returns a manifest, and explicitly distinguishes the tool from fetch_asset and read_url. An agent can immediately tell this is a multi-asset grab-and-save tool rather than a single-asset fetcher.

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

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

It explicitly says to use this when the files are the deliverable, and directly names fetch_asset as the alternative for a single listed URL. It also clarifies out_dir behavior and the read=true option, leaving little ambiguity about when to choose this tool.

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 full burden and does so: direct requests only with no relay, a non-obvious side effect (one GitHub release GET, cached at ~/.searchts/update-check.json, once per 24h, opt-out env var), and an explicit 'nothing is installed or changed'. The epistemic caveats ('proves a login wall is absent, not which account', 'expiry is only an upper bound') prevent over-reading results.

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 and almost every sentence carries information, but it reads as a dense run-on with no visual structure. The 24-hour rate limit is stated twice in adjacent sentences, and the update-check mechanics could be condensed considerably given they are secondary to the login verdict.

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 names the result states and their caveats, and both parameters are semantically covered despite 0% schema documentation. Nothing an agent needs in order to call this correctly or interpret it 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 0%, yet the description supplies real meaning for both fields: url is the site whose cookies are used, and check_url substitutes a custom page for the built-in known page while still drawing cookies from url's site. That relationship is precisely the non-obvious part. Minor gap: no URL syntax/format expectations.

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 concrete verb and resource ('read one signed-in-only page with the saved cookies, once') and enumerates the three possible verdicts. It also draws an explicit boundary against the sibling check_url, so an agent can differentiate without opening either schema.

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

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

Gives the exact routing rule: reddit/linkedin/github/x use a known account page, other sites require a signed-in-only URL, and a public page yields 'unknown'. It also states the negative conditions (captcha, block, network error) that must not become a guess, which is unusually explicit 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 and does well: it discloses that deletion is limited to searchts's own stored login, that user browser cookies survive unless also_browser is true, and that the update check performs one GitHub GET cached at ~/.searchts/update-check.json with no user data and an opt-out env var. It omits error/no-op behavior when no saved login exists and reversibility (whether re-auth is immediate).

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 action and the when-to-use trigger in the first two sentences with zero waste. The trailing update-check block is accurate and discloses a real network side effect, but it is disproportionately long for a deletion tool and reads as boilerplate shared across all tools.

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, so return values need not be explained, and the description covers the major behavioral risk (cookie deletion scope) plus the update-check side effect. Gaps remain around no-saved-login handling and url matching granularity for a tool this simple.

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 0%, so the description must compensate, and it largely does: also_browser is given precise semantics ('also deletes cookies in the user's Firefox or Chrome') and the url param is contextualized as 'one site'. It never specifies the expected url format (domain vs full path/URL) or whether matching is exact.

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: delete searchts's own saved login for one site. It sharply distinguishes this resource from browser cookies ('the user's own Firefox or Chrome') and links its effect to read_url re-prompting, so an agent knows exactly what is removed versus merely re-asked.

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 an explicit trigger: 'Use when a read_url error says the saved login has expired.' That is a clear when-to-use condition. It does not name an alternative path (e.g. login_signin from login_check/login_status) or state when-not to use, which keeps it below 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?

With no annotations, the description carries the full burden and does it: the window opening is the approval, the user must be at the machine, closing the window finishes, timeouts keep nothing, and success/failure return shapes are given. It also discloses a side effect (the update check GET and its env-var opt-out) that an agent would otherwise be surprised by.

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 well, but the final third is an extended update-check disclosure with paths, User-Agent details and an env var, which is tangential to signing in and inflates the text an agent must parse. The core sign-in behavior could be stated in about half 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?

For an interactive login tool with no annotations, everything needed to invoke it safely is present: prerequisites, the human-in-the-loop flow, timeout semantics, and the return JSON. The output schema exists yet the description still names the result fields, so nothing essential is missing.

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

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

Schema coverage is 0%, so the description must compensate. It fully documents wait_seconds (default 180, range 30-900) and its constraint about host call timeouts, but url and browser are never explained beyond what their bare names imply, leaving a gap for a 3-parameter tool.

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?

Opens with a specific verb+resource: sign in once for a site in a browser the tool opens, and keep that login. It explicitly distinguishes itself from the browser-session-copying alternative (grab_site) by stating nothing is copied from the user's own browser, so an agent can route correctly 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?

States exactly when to use it: past a login wall when the user has no session worth copying or refuses to have one read. It also covers the re-run condition (a kept login is not refreshed, so near expiry the user must run login_signin again), which is a rare and useful lifecycle rule.

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

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

With no annotations, the description carries the full behavioral burden and does so extensively: expired cookies are swept offline with no daemon, the response is JSON and never contains cookie values, the update check is a privacy-preserving GitHub GET cached locally, nothing is installed or changed, and SEARCHTS_NO_UPDATE_CHECK=1 disables the check. This is unusually complete behavioral disclosure.

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 content is useful, but the first sentence is an overloaded run-on list, and the update-check explanation is lengthy for a status tool. It is front-loaded with purpose but could be tightened without losing meaning.

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 zero parameters, no annotations, and an output schema, the description covers the missing behavioral and usage context thoroughly: when to call it, what it reports, cookie privacy, expiry semantics, update-check behavior, and the disable flag.

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

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

There are zero parameters, so the baseline is 4. The description correctly focuses on what the tool reports rather than inventing parameter semantics.

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 that this is a status tool reporting kept sites, live cookies, expiries, consent state, copy permissions, copied sites, and scratch folder location. It is specific about the resource and contents, though it does not explicitly differentiate itself from sibling tools such as login_check.

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 gives a clear trigger: 'Call this when a read_url error mentions a login.' It does not state when not to use it or compare it directly to login_check, so it falls short of full alternative 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 behavioral burden and does so thoroughly: it discloses the unlocker ladder, content sanitization, prompt-injection fencing, signed cursors, cookie host-fencing, proxy restrictions, approval requirements for cookie copying, clamping ceilings, and error-string behavior. These are exactly the mechanics an agent needs before calling a complex read tool.

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

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

The first sentence front-loads the core purpose and the content is relevant, but the description is extremely long and repetitive: max_pages and max_items are explained twice, expand is restated, and several operational details such as the update-check mechanics could be tighter. It is information-dense rather than wasteful, but it is not concise.

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 13-parameter tool with no annotations and an output schema, the description is complete enough to invoke correctly: it covers auth/cookie workflows, pagination, limits, safety constraints, and failure behavior. Return-value details are partly covered even though the output schema exists, which is a bonus rather than a gap.

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 0%, so the description must compensate for 13 parameters and it does: it explains cursor/page_items pagination, max_pages vs max_items, expand, max_media, cdp_port, cookies, cookies_from_browser, approve_cookie_copy, proxy, and proxy_trusted. The only parameter not explicitly re-explained is url, whose meaning is obvious from the tool name and first sentence.

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

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

The description states a specific verb and resource — read one web page as clean Markdown — and immediately distinguishes this from a plain fetch and from relying on search snippets. It is unambiguous about what the tool is for.

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 gives explicit when-to-use guidance: call first when the user asks what a URL says, do not start with a plain fetch, and use it when a previous fetch was blocked, JavaScript-rendered, or a web_search snippet was thin or blocked. It also names concrete failure modes such as 403/429, Cloudflare/DataDome/PerimeterX, and login chrome.

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 and does so: subtitles-first via yt-dlp with no API key, Whisper fallback (Groq/OpenAI if configured, else keyless local faster-whisper), return format including the 'Error: ...' string, and a full disclosure of the outbound GitHub update check with its cache path, rate limit, User-Agent, absence of user data, and SEARCHTS_NO_UPDATE_CHECK opt-out. Auth and network side effects are both spelled out.

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 core purpose and routing trigger are correctly front-loaded, but the update-check paragraph occupies a large fraction of the text and is written as an undifferentiated block of detail. Every fact is relevant, yet the dense single paragraph makes the high-value routing and subtitle guidance compete with secondary telemetry disclosure.

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 tool with an output schema, the description covers routing, fallback behavior, auth, and side effects well. Remaining gaps are operational specifics an agent might want before a long job: supported local file formats, size/duration limits, and the provider value set.

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 and largely does: prefer_subtitles gets its default and effect ('set false to force audio'), cookies_from_browser gets opt-in semantics, accepted values (chrome/firefox/…), and the key warning that it uses THIS machine's cookies which read_url does not copy, and source is implied as either a player URL or a local file. The one gap is 'provider', whose accepted values (auto/groq/openai/local?) are never named despite the Whisper/provider discussion.

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 ('Read the spoken words' / 'transcribe a local audio/video file') and enumerates the exact input classes it handles (YouTube watch URL, TikTok, Instagram reel, v.redd.it, X video). It also explicitly distinguishes itself from read_url, so an agent can route between the two without opening either schema.

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

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

Gives an explicit trigger for use: when read_url reports a player page has no captions or returns an error naming this tool. It names the alternative (read_url for captions) and the exact condition that selects this tool, plus the prefer_subtitles default and how to force audio.

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 and does so: keyless DuckDuckGo default with SearXNG/Exa/Brave/Tavily fallback when keys exist, ranked/de-duplicated fusion output, an 'Error: ...' string when all providers fail, and an explicit outbound network disclosure (single GET to GitHub, 24h cache, UA, opt-out env var) with 'Nothing is installed or changed.' That effectively establishes read-only behavior without 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 critical routing guidance is front-loaded correctly, but roughly a third of the text is an update-check digression that repeats 'at most once per 24 hours' twice and details a cache path and User-Agent the agent does not need to select or call the tool. Useful disclosure, but disproportionate to the tool's core job.

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, so return values are already covered, yet the description still explains the return shape and the leading warning line. Behavioral context is thorough for a multi-provider search; the only real gap is the absence of anything about max_results, which matters for cost and result volume.

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 0% across both parameters, so the description must compensate and does not. 'query' is inferable from 'Find URLs', but max_results (default 5) is never mentioned — no upper bound, cost implication, or guidance on when to raise it.

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

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

Opens with a specific verb+resource — 'Find URLs to read' — naming the resource it produces (URLs) rather than a page. This cleanly separates it from siblings like read_url, grab_site, and fetch_asset that consume URLs instead of producing them.

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?

Explicitly routes the agent to the alternative: 'Call read_url on each URL you need, including when a hit is 403/429, a challenge, or thin. Do not answer from the snippet.' It also states the when-not condition (snippets are not the page). This is textbook when/when-not/alternative guidance.

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