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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing what the response contains (version, snapshot date, counts, legend, citation), which is meaningful context 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?

A single compact sentence that front-loads the resource and lists the returned content items with no filler. Every phrase maps to something the agent would actually retrieve.

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, the description carries the return-value burden and adequately enumerates the payload. Minor gap: it doesn't state the response format or whether the legend is embedded versus linked, but for a zero-parameter informational tool this is close to sufficient.

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

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

The tool takes zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly spends no words on parameter semantics.

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

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

The description names the specific resource and enumerates its contents: dataset version, corpus snapshot date, counts, evidence-code legend, and citation guidance. That clearly separates it from the data-lookup siblings (get_study, search_entities, etc.), though it is phrased as a noun list rather than 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?

Usage is only implied: an agent can infer this is the tool to call when it needs citation metadata or the evidence-code legend. There is no explicit when-to-use statement, no exclusion, and no named alternative among the eleven siblings.

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=true, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds that results include 'full cards for supporting and conflicting studies,' which is useful return-shape context. However, it doesn't disclose directionality semantics beyond 'either direction,' pagination, or limits, so it adds only moderate value over 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, no filler, and the core behavior is front-loaded. The example question slightly pads the length but illustrates usage usefully, so it mostly 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 read-only relation-lookup with sparse parameter docs and no output schema, the description covers the basic purpose and return nature (supporting/conflicting studies) but omits identifier expectations, directionality details, and any limits. It is adequate but not 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 0% for the two parameters a and b, so the description must compensate. It only implicitly maps A and B to entities via the example question, without defining accepted identifier formats, entity types, or direction semantics for each parameter. This meets the minimum but leaves notable gaps.

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 clear verb+resource: 'Direct curated relations between two entities' with 'full cards for supporting and conflicting studies.' It implies a specific evidence-lookup operation, but it doesn't explicitly distinguish itself from siblings like find_relations or get_relation, so it stops just short of 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 example question 'what is the evidence that A acts on B?' implies when to use the tool, but there is no explicit guidance on when to prefer it over get_relation, find_relations, or find_contradictions. Usage 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds that results include both sides of the evidence, which is useful output-content context, but says nothing about pagination, result size, or what happens when no contested relations exist.

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 dense sentence with the contested-relations scope front-loaded and the optional filter appended. No filler, though the trailing 'Optionally limited to one entity' reads slightly tacked-on.

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 discovery tool with no output schema the description conveys what is returned (relations plus both sides of evidence), which is the key missing piece. It remains incomplete on how to identify the entity argument and on the limit/pagination behavior.

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 carry the parameter burden. It only loosely characterizes the `entity` parameter as an optional limiter and never states its format (ID vs name), and the `limit` parameter (default 20, max 50) is not mentioned at all.

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: relations the Atlas marks as contested or that carry conflicting studies, plus the notable scope detail that both sides of the evidence are returned. It implicitly separates itself from find_relations by scoping to contested claims, though it never names the sibling explicitly.

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

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

'Optionally limited to one entity' hints at when to narrow the query, but there is no explicit guidance on when to prefer this over find_relations or evidence_between, and no stated prerequisites. Usage is implied rather than directed.

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 non-destructive, so the safety profile is covered. The description adds domain-meaningful context ('signed, evidence-linked', filterable by contested status), but says nothing about result volume, pagination behavior, or what an empty result means.

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 nature of the resource front-loaded before the filtering options. The parenthetical example earns its place by disambiguating 'signed relation'.

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, zero-required search tool with no output schema, the description covers filtering but not result shape or paging (offset/next_offset only appear in the schema). It also gives no help decoding the strength codes, which are ambiguous in the schema itself (enum includes R/PP/RT while the ordering note stops at M).

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 only 50%, so the description must compensate, and it does: entity, source/target, effect, contested status, and strength threshold are all named in prose. It omits limit/offset semantics, but offset is documented in the schema itself.

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

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

States a concrete verb and resource ('Find pathway relations') and clarifies what a relation actually is with an example ('Rheb activates mTORC1'), plus the qualifier 'signed, evidence-linked'. This clearly separates it from a single-record lookup like get_relation, though no sibling is named explicitly.

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

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

The second sentence enumerates the available filter dimensions, which implies how to narrow a query, but it never says when to use this tool versus get_relation, evidence_between, or find_contradictions. Usage is inferable 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine return-behavior context beyond that: studies come back as short cards truncated to the first studies_limit, and pathway relations as one-line claims. It does not mention pagination beyond the limit or error behavior for unresolved names.

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 tight sentences with no filler; the core resource is front-loaded and the return shape follows. The parenthetical entity-type list is slightly bulky but earns its place by telling the agent what counts as an entity.

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, the description carries the burden of describing returns and does so adequately (short cards for studies, one-line claims for pathways). The only gap is what happens when the name is ambiguous or unmatched, which an agent resolving identifiers would want to know.

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 50%: the entity param has example values but studies_limit has only default/min/max and no prose. The description compensates by clarifying that studies_limit caps which studies are returned ('first studies_limit') and by stating that entity accepts an id, a name, or a synonym, which the schema does not say.

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 (one entity) and enumerates the entity kinds it covers (gene/protein, complex, drug, disease, process), plus what comes back: linked studies and pathway relations. It is clearly distinguishable from search_entities by the singular scope, though it never names the sibling explicitly.

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

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

The description notes that the tool accepts an id, a name, or a synonym, which hints at input flexibility, but it gives no when-to-use versus when-not guidance and never points to search_entities or find_relations as alternatives. An agent must infer the retrieval-vs-search split on its own.

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=true, idempotentHint=true, and openWorldHint=false, making the safety profile clear. The description adds useful content about what the question object contains, but doesn't describe authentication, error behavior, 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?

The description is a compact single sentence that front-loads the resource and ID examples, with no wasted words. It could be slightly more structured with a clear when-to-use phrase.

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 tool with one parameter and no output schema, the description covers the content well. However, given 0% schema description coverage, it should specify the expected ID format or describe return behavior more completely.

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 sole 'id' parameter is completely undocumented. The description provides example IDs ('H1', 'F2') which add some semantics beyond the raw string type, but doesn't state format requirements or whether 'open' vs 'frontier' IDs differ.

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 gives a specific verb+resource combination: retrieve 'One open or frontier question by ID', with example IDs, which clearly separates it from list_questions and search tools. However, it doesn't explicitly name alternatives or clarify the open/frontier distinction beyond context.

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 context is implied by 'by ID' and the sibling tools list, but the description does not say when to use this versus list_questions or search_entities.

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 this a safe, idempotent, read-only, closed-world lookup, so the safety profile is covered. The description usefully adds the shape of the returned content, but says nothing about failure behavior (e.g. unknown ID), which is the main remaining behavioral gap.

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 dense sentence with the resource and lookup key front-loaded and the returned fields trailing as a list. No filler, though its telegraphic fragment style slightly reduces readability.

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, the description correctly compensates by enumerating the fields returned (mechanism, boundary conditions, confidence, supporting/conflicting studies). The only material omission is error/miss behavior for a bad ID.

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 carries the burden, and the inline example 'RHEB-MTORC1' communicates the expected ID format, which is more than the bare 'string' schema provides. It stops short of stating whether the ID is case-sensitive or how it is obtained.

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?

Names the specific resource ('one pathway relation') and the lookup key ('by ID'), and enumerates the returned fields (mechanism, boundary conditions, confidence, studies). It implicitly separates itself from the plural sibling find_relations, though it never states that distinction explicitly.

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

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

The ID example ('RHEB-MTORC1') implies you need a pre-known relation identifier, which hints at when to use it, but there is no explicit when/when-not guidance and no mention of find_relations as the discovery alternative for agents that lack an ID.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds valuable disclosure the annotations lack: there is no output schema, and the enumeration of returned content (abstract excerpt, findings, linked entities, supporting/contradicting relations, open questions) tells the agent exactly what a call yields. It stops short of noting error behavior for an invalid ID.

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 with zero filler, front-loading the resource and key before a colon-delimited list of contents. Every clause 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 one-parameter read tool, the description compensates well for the absent output schema by listing the record's components. Minor gaps remain: no note on invalid-ID handling or whether relations are summarized or full, but nothing essential to invoking the 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 coverage is 100% and the single parameter is documented with an example, so the schema carries the semantics. The description only restates the key and repeats the same example, adding nothing new (no case-sensitivity or ID-format guidance). 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 specific verb+resource ('Full record for one study'), identifies the lookup key ('by Atlas ID'), and enumerates the record's contents. It is clearly separable from siblings like search_studies (plural lookup) and get_entity/get_question (different resources).

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?

Requiring an 'Atlas ID' implies you must already have an identifier, which indirectly routes the agent to search_studies when it only has a topic. However, no sibling is named and there is no explicit when-to-use/when-not statement.

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 destructiveHint=false, so the safety profile is covered. The description adds only a conceptual gloss of one category and says nothing about ordering, limits, pagination, or result volume — the behavioral gaps that annotations do not cover.

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 tight sentence with the primary category front-loaded and no filler. It is efficient, though the brevity edges into under-specification rather than pure conciseness.

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, annotation-covered list tool with no output schema, the safety side is fine and return values needn't be explained. But the domain terms ('Atlas', 'frontier questions') and the filter's behavior are never elaborated, leaving an agent to guess at what a frontier question is or how results are organized.

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 carry the parameter burden. It partially explains 'open-question' (evidence gaps with testable hypotheses) but leaves 'frontier' completely undefined, so half the enum is unexplained in both the schema and the description.

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 the resource (the Atlas's open and frontier questions) and glosses one category ('evidence gaps with testable hypotheses'), so an agent understands what comes back. However, it omits an explicit verb and does not distinguish this tool from the sibling get_question or the various find_*/search_* tools.

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

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

There is no statement of when to use this tool, when to prefer get_question or search_entities instead, or what the 'kind' filter is for. The presence of an enum parameter implies filtering but nothing tells the agent which value to pick or when to omit 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, destructiveHint=false and a closed-world scope, so safety is covered. The description adds the useful fact that matching is against names and synonyms across a broad entity taxonomy, but says nothing about result ordering, ambiguity handling, or pagination.

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 front-loaded sentence naming the verb, the resources, and the match basis, with zero filler. Nothing is repeated or 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?

For a moderate-complexity search tool with no output schema, the description omits what a result looks like, whether matches include IDs/scores, and how aggregation or limits behave. It is adequate to identify the tool but leaves the agent to infer the response shape.

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 67%: query and type are documented with examples, and limit is self-describing via default/min/max. The description's entity list effectively expands the valid values for the type filter, but it adds no format or matching-syntax guidance beyond the schema.

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

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

States a specific verb (Find) and resource (entities), and enumerates the searchable entity categories (genes/proteins, drugs, diseases, etc.) plus the matching basis (name or synonym). This is enough to distinguish it from most siblings like search_studies and find_relations, though it never explicitly contrasts with get_entity.

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 only implied: you reach for this when you have a name or synonym and want to locate an entity. There is no statement of when not to use it, no routing to get_entity for ID-based lookup, and no mention of the type/limit filters as tuning options.

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 non-destructive behavior, so the safety profile is covered. The description adds useful context by stating the return shape ('summary records with evidence codes and URLs') and pagination-relevant fields, but doesn't disclose result limits or pagination behavior beyond what the schema shows.

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 well-structured sentences: first describes the search scope and filters, second describes the return format. Front-loaded with the core purpose and no wasted words.

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 7-parameter search tool with no output schema, the description covers the main searchable fields and return type, but lacks detail on pagination behavior, result limits, and how evidence_code enum values map to meanings. With annotations covering safety, the main gaps are operational rather than safety-related.

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 57%. The description mentions keyword fields, evidence code, linked entity, and year range, which maps to most parameters and adds the important note that query can be omitted for filter-only listing. However, limit and offset semantics are left to the schema, and no enum values are explained.

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 resource (curated studies), and enumerates which fields are searched. It does not explicitly differentiate from siblings like get_study, though the 'search' vs 'get' distinction is reasonably clear.

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?

Implies usage context via 'search by keywords... optionally filtered,' and the schema notes that query can be omitted to list by filters only. But there is no explicit guidance on when to use this vs get_study, search_entities, or find_relations.

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