AskWatch Google Search Console MCP

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

With no annotations, the description carries the burden of behavioral disclosure. It explains the core behavior (splitting on supplied words) and adds the useful caveat to include the domain, but it doesn't describe output shape, matching rules, or edge cases like queries matching no brand terms.

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?

Two short sentences, front-loaded with the purpose and followed by a single crucial usage tip. There is no filler or redundancy; every sentence 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 an analytics tool with a rich schema, the description covers the key conceptual trap (brand term variants) and leaves parameter details to the schema. It could optionally describe the output format since no output schema exists, but the definition is adequate for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning to brand_terms by advising users to pass every spelling and include the domain, which goes beyond the schema's example list and clarifies expected input breadth.

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, differentiated purpose: splitting search into branded versus non-branded based on user-supplied words. It is clear and actionable, though it doesn't explicitly distinguish itself from siblings like query or top.

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

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

It provides clear operational context and a concrete input rule ('Pass every spelling people use, including the domain'). However, it doesn't mention when to prefer this tool over alternatives or when not to use it, so selection guidance remains implied rather than explicit.

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 it does disclose real behavior: it compares two periods, filters out small rows, and reports both gains and losses. It does not mention side effects or rate limits, but for this read-oriented analytics tool the comparative and filtering behavior is the key transparency signal.

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?

Two short sentences, no filler. The core concept (period-over-period delta) comes first, and the example grounds it in a concrete user question.

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 rich schema covering all seven optional parameters and the no-output-schema constraint, the description provides enough semantic context to invoke the tool: it explains the comparison, the filtering, and a typical use case. A slightly more explicit statement of what counts as 'lost' would make it fully complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'small rows filtered out' loosely reinforces min_impressions, and the 28-day example echoes the default days, but it adds no parameter-level detail beyond what the schema already documents.

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 explains that the tool computes what gained/lost between the current period and the preceding one, and gives a concrete example ('what dropped in the last 28 days'). This clearly differentiates it from sibling tools like top, query, and site_overview, though it does not explicitly name a sibling or use a crisp verb+resource construction.

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

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

It provides a clear call-to-action use case: answer questions about drops in the last 28 days. It does not explicitly list alternatives or exclusions, but the intended scenario is stated concretely enough for an agent to select it for period-over-period comparisons.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state that the tool is read-only, what the output rows represent beyond 'how each page does', whether results are aggregated, or how pagination works. The schema mentions has_more but the description adds no behavioral context.

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

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

The description is a single concise sentence with no filler words. It front-loads the core concept and includes a useful hint about output content, though the phrasing 'with how each page does on them' is slightly awkward.

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

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

With no output schema and no annotations, the description should explain what the returned data looks like for the agent to verify a correct call. It only hints at per-page performance and does not mention row structure, sorting, or other response details. Parameter documentation is strong, but the overall context is incomplete for a tool with 6 parameters and no structured output metadata.

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 each parameter is already documented in the schema. The description adds no extra semantics for the parameters, which is acceptable given complete schema coverage, earning the baseline of 3.

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 names a specific resource (queries with multiple pages shown) and a specific outcome (per-page performance), which distinguishes it from sibling tools like find_opportunities or page_queries. It is a noun-phrase rather than a verb phrase, but the intent is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives like page_queries, find_opportunities, or brand_split. The purpose implies a use case, but no explicit conditions, prerequisites, or exclusion criteria are provided.

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 of behavioral disclosure. It only states the selection criteria and purpose; it does not mention that the tool is read-only, how it handles missing optional parameters, whether it returns metrics like impressions/CTR/position, or any constraints such as data availability. The description adds no behavioral context beyond the core filter logic, which is insufficient for a tool with no annotations.

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

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

The description is a single, efficient sentence that front-loads the core selection criteria (ranking 5-20, high impressions, low CTR) and immediately states the practical value. There is no wasted wording; it is concise and well-structured for quick parsing by an agent.

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

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

The tool has 6 optional parameters with full schema documentation, so parameter handling is covered. The description explains the purpose and selection logic, which is sufficient for an agent to decide when to call it. However, there is no output schema, and the description does not mention what fields are returned (e.g., query, impressions, CTR, position), which could be assumed but is not explicit. This minor gap prevents a perfect score.

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

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

The schema has 100% coverage with detailed descriptions for all six parameters (days, site, limit, end_date, start_date, min_impressions), including defaults and constraints. The tool description does not mention any parameters, so it adds no extra semantic meaning beyond the schema. Baseline 3 is appropriate because the schema already documents the parameters adequately.

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

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

The description clearly states the tool finds queries ranked 5-20 with high impressions but CTR below typical for their position, explicitly framing it as where title/snippet rewrites are most valuable. This is a specific verb (queries/finds), a resource (queries), and a distinct selection criterion that differentiates it from siblings like 'top' or 'page_queries' without needing to inspect 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?

The description gives a clear use case: identifying optimization opportunities for title/snippet rewrites. It implies when to use the tool (when the agent needs queries to improve CTR) but does not explicitly mention alternatives or when not to use it. The context is strong enough for an agent to decide, but it lacks explicit routing to other tools like 'top' or 'page_queries'.

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

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

With no annotations, the description carries the burden of disclosing behavior. It describes the output fields, which is helpful, but it does not mention authentication needs, property access requirements, or error cases such as URLs outside the Search Console property. This is adequate but not comprehensive.

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

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

A single sentence packs the tool's purpose, scope, and expected output with no filler. The key information is front-loaded and every phrase 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 simple two-parameter lookup with no output schema, the description covers the essential return values and the single-URL scope. It could be more complete by noting operational caveats, but nothing critical is missing for basic invocation.

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

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

Schema description coverage is 100%, and the description does not add parameter-level meaning beyond what the schema already provides. The baseline of 3 applies because the schema fully documents both 'url' and 'site'.

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 identifies the resource ('one URL') and the exact information returned: indexed status, last crawl date, and Google-chosen canonical. This unambiguously differentiates it from sibling tools like page_queries or site_overview, despite the lack of an explicit verb.

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 'for one URL' framing gives clear context for when to use the tool: when you need Google's index status for a specific URL. It does not explicitly name alternatives or exclusions, but the scope is clear enough to guide tool selection.

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 burden of behavioral disclosure. It does disclose the read-only nature and that submission is impossible, which is useful. But it does not mention what status values may appear, whether an empty list is returned, or any error behavior, leaving a notable gap for a tool with no output schema.

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

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

The description is two short sentences with no filler. The core purpose is front-loaded, and the read-only caveat is useful. The phrase 'submitting is not possible with read access' is slightly redundant after 'Read-only', but the overall structure is 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?

For a simple one-parameter, read-only list operation, the description combined with the schema provides enough for an agent to call the tool correctly. It could optionally clarify the status vocabulary or return format, but the absence is not a serious gap given the tool's simplicity.

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 site parameter is already documented with exact formats in the schema. The description adds no additional parameter meaning, which is acceptable because the schema does the work; baseline 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?

The description identifies the resource (sitemaps submitted for a property) and the kind of information returned (their status), which distinguishes it from sibling tools like list_sites. It lacks an explicit imperative verb like 'List', relying on the tool name to supply the action, so it is clear but not maximally explicit.

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

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

The description provides a clear boundary: this is read-only and cannot be used to submit sitemaps. However, it does not explicitly state when to prefer this over alternatives or mention any related constraints such as requiring the property to already exist. Usage context is implied rather than 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly says the tool only reads properties, implying a read-only, non-destructive operation, and adds contextual behavior about ordering. It does not detail output shape or pagination, but for a parameterless list tool this is sufficient.

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?

Two short sentences with no filler. The primary purpose is stated first, and the actionable usage guidance follows immediately. Every word 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 simple parameterless list operation with no output schema, the description fully covers what the tool does and how it fits into the workflow. The instruction to call it first when the account has multiple properties is essential context for an agent navigating the toolset.

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

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

The tool has zero parameters, so there is no parameter documentation burden. The schema is trivially covered, and the description does not need to add parameter-level detail. Baseline for zero-parameter tools is 4.

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: 'Search Console properties this connection can read.' This clearly identifies the tool as a discovery/list operation and distinguishes it from sibling tools like list_sitemaps or site_overview.

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 guidance: 'Call it first when the account has more than one.' This tells the agent when it should be used, though it does not name alternatives or explicitly state when not to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says searches are 'shown for' a page; it does not disclose read-only behavior, aggregation, pagination, default date windows, or data-availability caveats. For a query-style tool this is thin.

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

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

The description is short and free of filler, but brevity comes at the cost of clarity and grammar. 'What searches a specific page is shown for' is confusingly worded and under-specified; it is not effective concise communication.

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 7 parameters, no annotations, no output schema, and overlapping sibling tools, a one-clause description is far from complete. It does not describe returned rows, metric fields, default behavior, pagination, or selection criteria, leaving too much for the agent to infer.

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 parameters are already well documented in the schema. The tool description adds no additional parameter meaning: it does not explain how `page`, `match`, `days`, or `end_date` interact beyond what the schema states.

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 'What searches a specific page is shown for' is ungrammatical and lacks an explicit verb like get, list, or return. It gestures at page-level query data but does not clearly say what the tool returns (e.g., query strings, metrics, rankings), and it does not distinguish itself from siblings like `query` or `inspect_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?

There is no guidance on when to use this tool versus alternatives such as `query`, `top`, or `inspect_url`. No context, exclusions, or alternative conditions are provided; an agent can only infer that it might be useful when focusing on a single page.

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 full responsibility for behavioral disclosure. It only says it's a 'query', which implies read-only, but doesn't explicitly state side effects, permissions, or response behavior. The schema does mention has_more/next_start_row, but the description itself doesn't add that.

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?

Two sentences, purpose front-loaded, no filler. Each sentence carries distinct information: the tool's role and the parameter compatibility.

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 8-parameter tool with no output schema and no annotations, the description is too thin. It doesn't describe the response shape, pagination, error behavior, authentication, or any prerequisites. Its only guidance is the 'other tools' scope, which is usage guidance, not completeness.

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 baseline is 3. The description adds meaningful context that parameters are exactly the ones the Google API accepts (same dates, dimensions, filters), which helps an agent with API knowledge. It also reinforces that the tool exposes the raw API surface.

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 operation ('Direct Search Analytics query') and explicitly scopes it as the catch-all for questions the other tools do not shape, which differentiates it from siblings. However, it could be clearer about what 'Direct' means and what the resource is.

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

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

The description gives a clear usage condition: use when other tools do not shape the question. It doesn't name alternatives or list when-not-to-use cases, but the implied rule is strong enough for an agent to decide.

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 of behavioral disclosure. It accurately describes the period-over-period comparison and the metrics included, but it does not explicitly confirm this is a read-only reporting operation or explain how the comparison period is derived when custom dates are used.

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?

Two concise sentences with no filler. The first states the metrics and comparison behavior; the second provides a clear usage cue. Every word 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 tool with no output schema, the description does list the returned metrics, which helps. However, it leaves some ambiguity about how the previous comparison period is computed when start_date overrides days, and it does not describe the result shape or edge cases like empty periods.

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 parameters are already fully documented. The description adds conceptual context about periods and comparison but no technical detail beyond what the schema provides, matching the baseline for high schema coverage.

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 what the tool does: it reports site performance over a period compared with the previous period, covering clicks, impressions, CTR, average position, and their changes. It is identifiable as a site-level overview distinct from page/query-focused siblings, though it lacks an imperative verb and does not explicitly name sibling alternatives.

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

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

The phrase 'Start here for "how is my site doing"' gives an explicit entry-point use case, so an agent knows when to reach for this tool. It does not state when not to use it or point to alternatives for deeper questions, but the intended context is clear.

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

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

No annotations are present, so the description carries the behavioral burden. It communicates a read-style reporting query and shows that filters can be combined in one call, but it does not disclose sorting direction, pagination, default grouping, or explicitly confirm read-only behavior, leaving some traits to schema defaults.

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?

Two short sentences with no filler; the first states the operation and scope, the second gives a concrete example. Every word earns its place and the content is front-loaded.

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 9-parameter tool with no annotations and no output schema, the description is adequate but sparse: it covers overall purpose and an example while the schema covers parameter details. It would be more complete with a pointer to sibling tools and a note on result ordering or pagination, but it is not fatally incomplete.

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

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

Schema description coverage is 89%, so the schema does most of the parameter documentation work. The description adds the useful insight that country and device are optional filters that can be combined in one call, but it does not explain parameter formats or defaults beyond what the schema already provides.

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

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

The description clearly states the tool returns the top queries, pages, countries, or devices over a time period and gives a concrete combined-filter example. It is specific about the resource and ranking mode, though it does not explicitly distinguish it from sibling tools like query or page_queries.

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 conveys the primary use case: retrieving top dimension values for a period, optionally filtered by country/device, and the example 'top pages in Germany on mobile' makes the intended invocation unmistakable. It does not name alternatives or state when not to use it, but the context is clear enough for basic selection.

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