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

With no annotations, the description carries the behavioral burden and does well: it enumerates every status transition, clarifies that ready is true only when fully active with SSL, and notes failure_reason appears only on failure. It does not mention auth requirements or polling rate limits, which keeps it short of a 5.

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 a numbered lifecycle, then Args and Returns. Every line carries information the agent needs, and the return enumeration substitutes for the absent output schema rather than padding.

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?

No output schema exists, so the description must document returns — and it lists status, dns_status, ssl_status, payment_status, ready, and failure_reason with their value domains. Combined with the lifecycle flow, nothing needed to call and interpret this tool 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 0%, so the description must explain the single parameter, and it does — provision_id is the value returned by provision_domain, which is exactly the provenance an agent needs. It stops short of format details but the one param is fully disambiguated.

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 ('Check the current provisioning status of a domain') that is clearly distinct from siblings like provision_domain, list_domains, or release_domain. An agent can pick this tool without opening any 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?

Explicitly says 'Call this to poll whether a domain is ready' and lays out the full four-step lifecycle from pending_payment to active, so the agent knows exactly when this tool is the right one and what to expect between calls.

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 provided, so the description carries the burden. It does add useful behavioral context through the Returns block (paginated results with total/has_more, default and max limits) and enumerates status values. However, it does not disclose auth requirements, rate limits, or anything about the side-effect profile beyond implying it is a read.

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 usage, then Args and Returns sections. Every line earns its place, though the 'Args:'/'Returns:' convention is slightly verbose. No wasted 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?

For a read-only list tool with no output schema, the description covers status values, pagination behavior, and return fields (id, hostname, status, ready) plus total/has_more. It is nearly complete; missing only auth/rate-limit context, which is minor for a listing 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?

Schema description coverage is 0%, so the description must compensate. It does: enumerates all six valid status_filter values (pending_payment, pending_dns, pending_ssl, active, failed, released) and documents limit's default (50) and max (100), which the bare schema does not.

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 ('List all domains provisioned through your platform account') with scope (account-level). It is clearly distinguishable from check_domain_status and list_websites.

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 states when to use it ('build dashboards or check the state of all domains'), which is clear context, but does not name alternatives like check_domain_status for single-domain checks or state when-not to use this.

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. It discloses the ordering (newest first) and the return content shape (sites with live URLs), but says nothing about permissions, read-only nature, or whether results are paginated beyond the limit.

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 single-sentence summary followed by a compact Args block; no filler text. The Args formatting is slightly redundant for a one-parameter tool but not wasteful.

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-only list tool with one optional parameter and no output schema, the description covers what is returned (websites with live URLs) and ordering. It is nearly complete, with pagination behavior the one notable omission.

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% and the lone limit parameter has no schema description, so the description must compensate. It does: it supplies both the default (50) and the maximum (100), which the schema does not provide, giving the agent actionable bounds.

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

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

States a specific verb (List) and resource (account's hosted websites) plus distinguishing detail (live URLs, newest-first ordering). It doesn't explicitly contrast with the sibling list_domains, but an agent can still tell the two resources apart from the wording.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_domains or any filter-based lookup. The listing intent is implied by the verb, but nothing is spelled out.

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 provided, so the description carries the full burden, and it delivers a rich behavioral picture: it creates a mapping, is NOT immediately active, requires a post-step (claim_url visit), involves payment ($8/mo), and DNS setup. It also surfaces idempotency behavior. This is well beyond safe-read/write signaling.

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 trigger, then Args and Returns. Every sentence earns its place: no restatement of schema titles, and the behavioral constraint is stated once, early, and clearly.

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-param, no-annotation, no-output-schema mutation tool, this definition is complete: arguments, return fields (including status enum values and dns_instructions shape), completion-time expectation, and the mandatory claim_url step. Nothing an agent needs to call it 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 0%, so the description must compensate fully, and it does: domain (e.g., 'mysite.com'), origin_url (e.g., a deployed URL), user_email (billing/notifications purpose), and idempotency_key (retry-safety purpose) are all explained with examples and intent.

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 ('Provision a new custom domain for an AI-generated site or app') with the scope clearly bounded. Distinguishes itself from siblings like check_domain_status and release_domain by being the creation step in the lifecycle.

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 trigger stated: 'Call this when a user wants their deployed site accessible at a custom domain.' The description also clarifies the workflow boundary (must visit claim_url first) and routes the agent to the sibling check_domain_status for tracking. Nothing left 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?

With no annotations, the description carries the full burden and does so well: it discloses the API-key account-linking requirement and the account_not_linked error, the slug_taken collision behavior, the baseUrl mismatch warning, ignored unsupported files, and that large builds are chunked into several requests.

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 purpose and then organized into Args/Returns sections with no filler sentences. The Docusaurus baseUrl paragraph is long and tutorial-like, but it earns its place by preventing a real misconfiguration, so the size is close to appropriate though slightly heavy.

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?

There is no output schema, so the Returns block is necessary and present, covering url, id/slug, counts, framework/base_url, warning, and skipped_files. Combined with the error-code guidance, an agent has everything needed to call this correctly 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?

Schema coverage is 0%, so the description must compensate, and it documents all three parameters: source_path (absolute path to file/dir/zip), title (shown in dashboard and emails), and slug (optional, auto-generated, /s/<slug>/ URL form, slug_taken error). This goes well beyond the bare schema types.

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 (publish) and resource (local HTML file, directory, ZIP, or static build folder) and names the target host. The word 'local' plus source_path detail cleanly separates it from the sibling publish_website_from_url, so an agent can route between them 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 clear triggering context ('use this right after generating a site') and concrete supported inputs (Docusaurus build/, Astro dist/, Vite dist/, Next out/). It never explicitly names publish_website_from_url as the alternative for URL-sourced publishing, so the exclusion is implied rather than stated.

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 SSRF-style refusals for private, loopback, and cloud-metadata addresses, a 150MB size cap, and that Docusaurus baseUrl detection can emit a warning. It omits auth/permission requirements, whether publishing overwrites or replaces an existing site, and idempotency, which matter for a mutation 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?

Front-loaded with the one-line purpose, then the workflow rationale, then structured Args/Returns blocks. Every sentence carries information; the workflow sentence about zipping and hosting the archive is slightly verbose but earns its place given the unusual constraint.

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 3-param mutation tool with no annotations and no output schema, the description covers publishing path, security limits, size cap, and parameter meanings. The remaining gap is the return value, which is delegated to 'Same shape as publish_website' — useful but requiring the agent to consult the sibling.

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 does for all three parameters: source_url (public http(s) URL to a .zip or .html, ≤150MB), title (human-readable site title), and slug (optional, with the concrete URL pattern /s/<slug>/). This adds format and placement meaning well beyond the schema's bare titles.

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 ('Publish a site from a URL') and immediately narrows the scope: a .zip of the build folder or a single HTML page. It explicitly frames itself as the URL-based counterpart to publish_website, so an agent can distinguish it from that sibling 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 a clear triggering condition ('The hosted thin.host MCP endpoint cannot read your disk, so this is its publish path') and names the alternative path by stating that mapping/batching/warning behavior 'matches publish_website'. It stops short of an explicit when-not statement (e.g. 'use publish_website when you have local file access'), but the routing intent is unmistakable.

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 explicitly: it destroys the domain mapping and SSL certificate, cancels billing, frees the domain for re-provisioning, and is not reversible. That is exactly the destructive side-effect disclosure an agent needs before calling a mutation 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?

Front-loaded with the action and impact, and the Returns block is valuable given there is no output schema. The Args section mildly restates the single schema property, a small redundancy, but overall tight.

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?

No annotations or output schema exist, and the description covers the destructive effects, irreversibility, and return values well. It omits permission/auth requirements and how to source the provision_id, which for an irreversible operation would be useful.

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% for the single provision_id parameter, so the description must compensate. It only restates 'the provision_id of the domain to release' without saying where to obtain it (e.g., from list_domains), leaving a meaningful gap.

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 ('Release a provisioned domain') plus the concrete effect ('removing it from thin.host'), which cleanly separates it from siblings like provision_domain, check_domain_status, and list_domains.

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?

Usage is implied by the destructive teardown description, but the description never says when to prefer this over alternatives (e.g., check_domain_status first to confirm state) or what preconditions exist. Suitable context is present, but no explicit when/when-not routing.

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: approval requirements, verified sender domain constraints, specific error codes, retryability, and recipient_suppressed non-retry behavior. It also describes the success and failure return shapes.

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 definition is long but well structured and front-loaded: purpose, precondition, arguments, returns, and common errors. Every section adds actionable information for correct invocation, and there is little 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?

For a six-parameter mutation tool with no annotations and no output schema, the description is complete. It covers prerequisites, parameter semantics, return values, failure modes, and retry guidance.

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 all six parameters, and it does. It documents each argument, explains the text/html requirement, the verified-domain constraint on from_address, and the recommended default-sender omission.

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: send a single transactional notification email, with examples. It also explicitly excludes marketing or bulk sends, making the intended use unmistakable.

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 preconditions, when the tool will fail, and what to do instead of retrying blindly. It also specifies the recommended way to omit from_address and requires at least one of text or html.

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 whole burden. It discloses the mutation target and the returned fields (status, updated_at), but says nothing about required auth/ownership of the provision, whether the change is reversible, propagation delay, or impact on live traffic. Adequate but notably thin for a write 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?

Well front-loaded: purpose first, then usage context, then args and returns in a scannable layout. Every sentence earns its place; the Returns block is genuinely additive given there is no output 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?

For a two-parameter mutation with no annotations and no output schema, the description covers params and return fields but omits permission requirements, error conditions, and reversibility. It is workable but leaves real gaps an agent would want before invoking a write.

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 does: it explains provision_id identifies the domain to update and gives a concrete example format for new_origin_url. Both required parameters gain meaning beyond the bare string types, though valid-scheme/trailing-slash rules are not covered.

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 first sentence gives a clear verb+resource pair ('Change the origin/target URL for an existing domain'), which an agent can map to a distinct operation. It does not explicitly name how it differs from close siblings like update_website or update_website_from_url, leaving that separation to inference.

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 when the user redeploys their site to a new URL and wants the custom domain to point to the new location' gives a concrete triggering scenario. There is no explicit when-not guidance or named alternative (e.g. re-provisioning vs. updating), so it stops short of full routing 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?

No annotations are provided, so the description carries the full burden. It clearly discloses destructive behavior with sync=true (deletes files not in upload), default behavior, and an exception (dashboard-authored redirect pages are kept). This is critical contextual information for a mutation 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?

Information is well-organized with clear sections for Args and Returns. However, the behavioral paragraph is somewhat lengthy and could be tightened, though every sentence adds necessary context for this destructive operation.

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 complex mutation tool without annotations or output schema, the description covers purpose, usage, destructive behavior, parameter meanings, return values, and alternative tools. It is complete enough for an agent to invoke correctly and safely.

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 explain parameters. It does so thoroughly: defines website as id/slug/URL, source_path as .html/directory/.zip, and explains sync's effect. This compensates fully for the schema gap.

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 ('Push updated pages/assets'), names the resource ('existing hosted website'), and clarifies the upsert-by-path semantics. It explicitly distinguishes itself from publish_website ('Use publish_website for a brand-new site').

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 when-to-use guidance for sync=true vs sync=false, including concrete frameworks (Docusaurus, Astro, Vite, Next export), and explains the risk of not using sync. It also names the alternative tool for new sites.

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 and discharges most of it: it discloses the destructive consequence of the default ('after upload, files the archive does not contain are deleted (dashboard-authored redirect pages are kept)'), the 150MB size cap, and the public-URL requirement. Auth/permission requirements and true idempotency are not stated.

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

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

Front-loaded purpose sentence, then rationale, then structured Args/Returns. Slightly redundant in restating the sync default, but every section earns its place and nothing is padded.

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?

A destructive, no-annotation, no-output-schema mutation tool is mostly covered: destructive semantics, size limit, param meanings, and a pointer for the return shape ('Same shape as update_website'). Missing only auth/permission and error-behavior context.

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 Args block documents all four parameters with meaningful semantics: website accepts id, slug, or live URL; source_url must be a public http(s) URL of a .zip or a single .html ≤150MB; sync's default and effect are explained. This fully compensates for 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?

States a specific verb+resource ('Redeploy an existing site from a URL') with the accepted source formats in parentheses, and explicitly positions itself as 'the URL form of update_website', distinguishing it from that sibling and from publish_website_from_url.

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 clear context ('for the hosted endpoint or any agent that has the build as a downloadable archive') and a conditional on the key flag: sync default true, pass sync=false to upsert only. It does not spell out when to prefer the sibling update_website instead, so it stops short of full routing guidance.

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