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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds the data source and format (opendata.swiss CSV/JSON), which is modest extra context, but says nothing about refresh cadence, coverage limits, or rate/auth behavior. With annotations carrying the safety burden, this is adequate but not rich.

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 resource and followed by the use case. No padding, though the second sentence is thin enough that it borders on filler.

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

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

An output schema exists, so return values need not be explained, and annotations cover the mutation profile. The remaining gap is sibling differentiation and any note on data scope/cadence, which an agent in a crowded blv_* toolset would need.

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

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

Schema description coverage is 100% and the single 'year' parameter is fully documented in-schema ('None returns all available years'). The description adds no parameter detail beyond that, so the 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?

States a specific resource ('annual animal health statistics from BLV') with a clear source attribution. However, it does not distinguish itself from several sibling tools that also return animal-health data (blv_get_avian_influenza, blv_get_meat_inspection_stats, blv_get_antibiotic_usage_vet), so an agent cannot tell from the description alone whether this is the aggregate overview or a subtopic.

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 'Use case: track year-over-year animal health indicators across Switzerland' line implies when the tool is useful, but it gives no explicit when-not and names no alternative sibling for narrower topics. Selection guidance is 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?

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description contributes provenance (Swiss ISABV monitoring system), which helps the agent judge data trustworthiness, but says nothing about filtering behavior, pagination, or data freshness.

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 that are front-loaded with the data source and immediately followed by the use case. No filler, no repetition of the schema, and nothing that could be trimmed without losing information.

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 no explanation, and the schema documents both filters fully. What the description supplies (source, use case) plus annotations is nearly sufficient; only the lack of routing guidance among sibling BLV tools leaves 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 100% with only two optional filters (year, animal_species), so the schema already carries full parameter meaning, including the empty/None = all semantics. The description adds nothing beyond the schema, making the baseline 3 correct.

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 resource (veterinary antibiotic usage data) and its provenance (Swiss ISABV monitoring system), which is a clear verb+resource statement. It does not explicitly distinguish itself from siblings such as blv_get_animal_health_stats, but the resource is narrow enough that an agent can identify it.

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 use case (analysing antibiotic consumption trends by livestock species for AMR reporting), which implies when to reach for it. However, it names no alternatives and offers no when-not guidance, so selection against the ten sibling BLV tools is 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?

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds useful domain context (H5N1/HPAI surveillance, geodata, canton scope), but says nothing about freshness, coverage windows, or pagination; a 3 is appropriate given annotations carry most of the burden.

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, front-loaded lines: the resource is stated first, then the use case. Every sentence 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?

With an output schema present, the description need not explain return values, and the two filter params are fully documented. Annotations cover safety; the only mild gap is the absence of sibling routing or data-freshness 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 description coverage is 100%, so both parameters (year, canton) are fully documented in the schema with defaults and examples. The description adds no parameter-level syntax or format detail beyond that, so the 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 states a specific verb (locate/date) and resource (wild bird avian influenza H5N1/HPAI surveillance data), and adds the geodata dimension that distinguishes it from generic disease-search siblings. It does not explicitly name which sibling to use instead, so it falls short of a 5.

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 'Use case' line clearly states when to reach for this tool and notes the optional canton narrowing. There is no guidance on when NOT to use it or which sibling (e.g. blv_search_animal_diseases) to prefer for other disease lookups.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely useful content context by naming what comes back (concrete download URLs, formats, open-data licence), which goes beyond what the annotations convey, though it says nothing about auth or rate limits.

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 the use case. No filler or redundancy.

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

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

For a single-parameter read tool with an output schema and full annotations, the description supplies purpose, workflow placement, and return-content expectations. Nothing essential is missing, though a note on identifier format expectations from the list tool would fully close the loop.

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

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

Schema coverage is 100% and the single parameter is fully documented as a CKAN slug sourced from blv_list_datasets. The description's 'specific BLV dataset' phrasing adds no syntax or format detail beyond the schema, so the 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?

States a specific verb+resource (retrieves detailed metadata and resource URLs for a specific BLV dataset) and explicitly names the sibling blv_list_datasets as the discovery path. An agent can distinguish it from the other blv_* tools without opening the schema.

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

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

The 'Use case' line explicitly frames the tool as the follow-up to blv_list_datasets for obtaining download URLs, formats, and licence. It clearly conveys when to reach for it, though it does not spell out when-not to use it or name any competing alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safe-read profile is covered by structured data. The description adds no behavioral context beyond that — nothing about row caps, result completeness, or what the openWorld external dependency implies.

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, no filler, with the resource identified first and the use case second. 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?

An output schema exists, so return-value description is unnecessary, and all three optional parameters are documented in the schema. The remaining gap is sibling differentiation against the other BLV statistics tools, which the description never addresses.

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%: year, limit and canton each carry their own description including default semantics ('None = all available', 'Empty = all'). The description adds no syntax or filtering detail beyond the schema, so the 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 names a concrete resource — cantonal food inspection results and violation rates (Lebensmittelkontrolle) — so the agent knows exactly what domain data it returns. It does not, however, distinguish itself from the closest sibling blv_get_meat_inspection_stats, leaving the agent to infer the boundary from the names alone.

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 explicit 'Use case: compare inspection volumes and violation rates between cantons or across years' sentence tells the agent when this tool is the right pick. It offers no exclusions or named alternatives, so the redirection burden falls entirely on the sibling names.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered by structured data. The description adds the subject matter (slaughter counts and condemnation rates) but says nothing about data source, freshness, or aggregation behavior beyond what annotations provide.

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

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

Two short sentences, front-loaded with the resource and followed by the use case; no filler. Slightly thin rather than verbose, so a 4 rather than a 5.

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 only two optional, fully-documented params, an output schema present, and annotations covering the read-only behavior, the description supplies enough to call the tool correctly. Only usage routing against siblings is left unaddressed.

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% with clear param docs (year, animal_type, both defaulting to 'all'), so the baseline is 3. The phrase 'by animal type and year' mirrors the schema without adding syntax or format detail.

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 ('meat inspection statistics' / Fleischuntersuchung) and names the concrete metrics (slaughter counts, condemnation rates), which differentiates it from generic siblings like blv_get_animal_health_stats. It does not explicitly contrast with any sibling, so it falls short of a 5.

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 'Use case' sentence gives implied guidance about when to reach for this tool, but offers no when-not conditions, prerequisites, or named alternatives among the many sibling stat tools.

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

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

Annotations only cover safety (read-only, idempotent, open-world); the description adds the operational trap that a non-matching filter like 'Eisen' silently returns an empty list indistinguishable from 'no data for this age group', and enumerates the actual returned columns. That is exactly the kind of failure-mode disclosure annotations cannot carry.

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 is well front-loaded, but a large share of the text is meta-commentary arguing with a docstring ('The docstring here promised...', 'inventing a mapping would be worse than the missing feature') rather than operational guidance for the agent. Useful content, but not every sentence earns its place for a two-optional-filter read 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?

An output schema exists so return values need no explanation, yet the description still names the returned fields, and it flags the misleading name and the empty-result ambiguity. The only gap is that it never points to the sibling tools for discovering or cross-referencing other BLV datasets.

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 both parameters carry examples ('10bis13', 'c09B_12'), so the schema already does the heavy lifting. The description only illustrates filter behavior via the 'Eisen' anecdote and adds no syntax or format detail beyond the schema. 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 opening line states the specific resource and scope ('Swiss national children's nutrition survey — questionnaire tallies (menuCH-Kids)') and explicitly corrects what the name/title wrongly implies by ruling out nutrient intake. It stops short of distinguishing itself from the ten sibling blv_* dataset tools (e.g. blv_list_datasets, blv_get_dataset_info) that an agent might otherwise pick for discovery.

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

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

Gives a concrete use case ('how often each answer was given, broken down by sex, language region and age group') and rules out the adjacent case by noting that adult nutrient intake lives in a separate dataset this tool does not cover. It does not, however, name which sibling to call instead or state the condition for choosing 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one useful trait beyond them: the data is a live RSS feed, implying freshness and no server-side filtering. No information on ordering, pagination, or update frequency though.

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 statement, followed by a compact use case. Both sentences earn their place, though the use-case sentence slightly restates the purpose already implied by the first.

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-value explanation is not needed, and the description covers source and scope adequately for a one-parameter read tool. Minor gaps (result ordering, whether the feed can be empty) remain but are not critical.

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

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

Schema coverage is 100% and the single 'limit' parameter is fully documented in the schema (default 20, max 50). The description adds nothing about the parameter, so the 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?

States a specific resource (BLV food recalls and public health warnings) and an explicit currency qualifier (current, live RSS feed). It is clear what the tool retrieves, though it does not explicitly distinguish itself from other food/health-data siblings like blv_get_food_control_results or blv_search_animal_diseases.

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 'Use case' line gives a clear triggering scenario with a concrete example question ('which products have been recalled recently?'), which is enough to route the agent here for food-safety-alert questions. It stops short of naming when NOT to use it or pointing to an alternative sibling.

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

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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds the CKAN backend detail, which is mildly useful for anticipating response shape, but says nothing about pagination, response volume, or rate limits. Adequate but not rich beyond the 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?

Two sentences, tightly front-loaded: what it does first, then the routing use case. Every clause earns its place with no redundancy.

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

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

An output schema exists, so return values need not be explained, and the description covers purpose and routing for a simple two-param listing tool. It could still note that the default limit returns the full BLV set, but 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 description coverage is 100% and both parameters (limit, search) are fully documented in the schema. The description adds no parameter syntax or semantics beyond that, so the 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?

States a specific verb ('Browse') and resource ('all BLV open datasets on opendata.swiss'), plus the backing API (CKAN). It is immediately distinguishable from blv_get_dataset_info, which is the drill-in sibling.

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 frames the use case: discover datasets before drilling into one with blv_get_dataset_info, or map a topic to a dataset slug. The alternative is named along with the condition that selects 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?

Annotations already establish readOnly, idempotent and open-world behavior, so the safety profile is covered. The description adds genuine data-provenance context (InfoSM source, coverage back to 1991), but says nothing about pagination, result limits, or return shape beyond what the output schema presumably carries.

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, front-loaded with the core purpose and then a single illustrative use case. No filler or redundancy.

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

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

With annotations, full schema coverage and an existing output schema, the definition supplies what an agent needs: scope, source, and a usage example. The only gap is sibling differentiation, which is minor given the descriptive name and the adequate surrounding 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 description coverage is 100%, so all five parameters (limit, canton, disease, year_from, year_to) are fully documented in the schema itself. The description adds no parameter-level meaning beyond that, making the baseline 3 appropriate.

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

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

States a specific verb and resource ("Search notifiable animal disease cases") plus scope (Switzerland, since 1991, InfoSM). Clear, but it never distinguishes itself from plausible siblings like blv_get_avian_influenza, which an agent might reasonably reach for instead.

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

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

Provides a concrete use case (reporting disease occurrence by canton and year) with a worked example, which gives clear invocation context. It stops short of naming alternatives or stating when not to use this tool over sibling disease/avian-influenza tools.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety and repeatability profile is covered elsewhere. The description adds the useful detail that results can include revoked as well as approved products, but says nothing about pagination, ordering, or rate limits. With annotations carrying the main burden, this is adequate but 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?

Two sentences, zero filler, with the resource identity front-loaded and the use case immediately after. Nothing is repeated from the title or 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?

The tool is a simple read-only filtered search with a fully documented schema and an output schema, so return values need not be explained. Purpose and use case are covered; only minor operational detail (result ordering, whether status "" means all statuses) is left implicit.

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 all four parameters (limit, status, product_name, active_ingredient) are already documented in the schema, including the enum-like status values and the German examples. The description mentions active ingredients and approval status conceptually but adds no syntax or format meaning beyond the schema. 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?

States a specific verb (Search) and a precisely named resource (the Swiss approved pesticide register / Pflanzenschutzmittelverzeichnis), plus the domain use case of approval checking. This is unmistakably distinct from every sibling tool (animal diseases, food control, avian influenza, etc.), so an agent can route to it without opening the schema.

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

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

The "Use case" line tells the agent exactly which question this tool answers: whether a plant-protection product or active ingredient is approved or revoked in Switzerland. It does not name any alternative tool or state exclusions, so it stops short of the 5-level bar, 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.