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

No annotations are supplied, so the description carries the full burden. It does add real behavioral signal with "standalone" plus "SVG text or PNG image," implying the artifact is returned inline rather than written to disk or embedded in a ZPL job. It says nothing about errors for invalid data/type combinations, size limits, or encoding constraints, which matter because barcode types have strict data-length rules.

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 action and output forms, with the supported-type list appended as scannable detail. Nothing is redundant and nothing wastes space.

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 three-parameter tool with no annotations and no output schema, the definition should say more about what comes back — an SVG string versus base64/binary PNG — and about failure modes. As written it is adequate to call correctly but leaves the return shape to inference.

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 covers 67% of parameters and leaves the `format` enum undocumented; the description compensates by explaining that output is "SVG text or PNG image," giving each enum value concrete meaning. The full list of supported `type` values likewise extends beyond the schema's terse "Barcode type, e.g. code128." Only per-type data constraints remain unaddressed.

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 ("Generate a standalone barcode") and enumerates the supported symbologies, so an agent knows exactly what it produces. It does not explicitly distinguish itself from the ZPL-validation siblings, but those are clearly a different operation, so confusion risk is low.

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 for rendering a barcode when a label preview/validation sibling is not what you want. There is no explicit "use this when..." statement nor any named alternative or precondition.

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 the most important trait: embedded ^GF/~DG bitmaps are NOT rescaled and a Warnings block is emitted rather than silently passing. That is genuine, non-obvious behavioral context. It stops short of covering error behavior on invalid ZPL or the output shape.

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 waste, with the core operation front-loaded and the caveat immediately after. Every clause carries 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?

For a 3-param transform tool with no output schema, the description tells the agent what is transformed, what is left alone, and that a Warnings block may precede output. Error/failure behavior and the return type are the only notable gaps.

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 zpl/source/target and their defaults are already documented. The description adds the resolution set (203/300/600) but actually omits 152, which the schema lists, so it adds little and is slightly narrower than 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 and resource (rescale ZPL coordinates) plus the dimension being scaled (printer resolution), which no sibling tool covers. It never names an alternative, but the purpose is unmistakable and non-overlapping with zpl_validate/zpl_preview.

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

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

Usage is implied by the purpose — you call it when moving a label between 203/300/600 dpi printers. There is no explicit when-to-use/when-not guidance, no instruction to validate with zpl_validate first, and no note about what happens if source equals target or the source is mis-declared.

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

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

No annotations exist, so the description carries the full burden, and it does disclose the important behavioral trait: the return is a structured diagnostics report with positions and severity, in JSON. 'Lint/validate' implies a non-mutating check with no side effects on the input, though the description does not say so explicitly or cover limits on input size.

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 the action front-loaded, followed immediately by what is returned. No filler, no restatement of the tool name.

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 simple (one required string parameter), and since no output schema exists, the description usefully compensates by describing the return shape (findings with positions and severity, JSON). An agent has everything needed to call it and interpret the result.

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

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

There is a single parameter at 100% schema description coverage ("Raw CPCL code"), so the schema already covers it and baseline 3 applies. The description's phrase "CPCL label code" adds no format, encoding, or size 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?

The description states a specific verb pair ("Lint/validate") and resource ("CPCL label code"), which cleanly separates it from the zpl_validate, epl_validate, and tspl_validate siblings by language. It stops short of explicitly routing callers who don't yet know the label language (e.g., toward language_detect), so it falls just 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?

Usage is only implied: the tool is for checking CPCL code. There is no statement of when to prefer it over siblings, no mention of what to do with the diagnostics (e.g., fix-and-revalidate), and no exclusion or prerequisite guidance.

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

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

With no annotations, the description carries the full burden. It does useful work by disclosing the return shape (findings with positions and severity, as JSON) and implying a non-mutating check, but it says nothing about what happens with clean code, whether diagnostics above a severity are surfaced as errors, or any size 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?

A single front-loaded sentence with no wasted words; the verb, resource, and return contract all land in one pass.

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, non-mutating lint tool with no output schema, the description covers purpose and return shape adequately. The only real gap is edge-case behavior for valid input and error signaling, which is minor at this complexity.

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?

One required parameter at 100% schema coverage, so the schema already documents it. The description adds only a mild clarification that both EPL and EPL2 are accepted; no format examples or constraints beyond the schema's minLength 1.

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 (lint/validate) plus the resource (EPL/EPL2 label code) and the result shape (structured diagnostics report). The language naming implicitly separates it from zpl_validate, tspl_validate and cpcl_validate, but 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?

Usage is only implied by the EPL/EPL2 scope in the description; there is no explicit 'use this when' or 'use zpl_validate instead' routing. An agent must infer the choice from the language name alone.

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 disclosure burden and does well by explaining the report structure, scoring, and the 'not assessed' behavior for non-assessable sections. It implies a read-only review operation but does not explicitly state side effects, permissions, or error behavior.

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

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

The description is front-loaded with the report purpose and scoring, then routes between this tool and zpl_validate, then adds the key size caveat. Every sentence contributes useful information without waste.

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

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

There is no output schema, so the description appropriately explains the return format as a sectioned 0-100 health report and notes that only assessable sections are counted. Given full schema coverage and the sibling alternative named, an agent has enough context to call this tool correctly.

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

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

Schema coverage is 100%, so the schema already documents all five parameters. The description adds meaningful semantic emphasis by warning that the real label size must be passed because findings depend on it.

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

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

The description states a specific output, a human-readable health report for a finished ZPL label, including the 0-100 score and the sections it covers. It clearly distinguishes this from zpl_validate by positioning zpl_validate for quick pass/fail checks while editing.

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

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

It explicitly says to use this tool to review or explain a label to a person and names zpl_validate as the alternative for quick pass/fail validation. It also tells the caller to pass the real label size because findings depend on 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?

With no annotations, the description carries the full burden and does meaningful work: it discloses the method is a 'Heuristic' and explicitly warns that the result is a confidence TIER plus signal codes, 'not a probability' — setting correct expectations about reliability. It stops short of stating determinism, whether empty/garbage input errors, or performance characteristics.

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 dense sentences with zero filler: the purpose and the candidate set come first, the return-shape caveat second. Every clause carries information the agent needs.

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, no-annotation tool with no output schema, the description covers the essential ground by explaining the return shape (language + tier + signal codes) and the heuristic nature. Only the routing guidance to the sibling validators 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?

One parameter with 100% schema description coverage ('Raw label code to classify'), so the schema already documents it fully. The description adds nothing about input format, size limits, or how mixed-language code is handled, so 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 ('Detect') and resource ('which printer language raw label code is written in') and enumerates the candidate languages (ZPL, EPL, TSPL, CPCL), so the agent knows exactly what comes back. It never names the sibling validators (zpl_validate, epl_validate, etc.) or positions itself relative to them, so sibling differentiation is only inferable.

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 is purely definitional: no statement of when to call this versus the four *_validate tools, no prerequisites, and no guidance on what to do with a 'low' tier result. An agent must infer the triage role from the sibling names alone.

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 burden. It does disclose the return shape (findings with positions and severity, JSON), which usefully signals a non-destructive lint operation, but it says nothing about whether any code is modified, error vs warning handling, or limits on input size.

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?

One sentence, front-loaded with the action and ending with the return contract. Nothing redundant 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 one-parameter lint tool with no annotations and no output schema, the description covers what it does and what comes back well enough to invoke it correctly. Minor gaps remain around whether it is purely read-only and how severe findings are represented.

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?

Single parameter with 100% schema description coverage ('Raw TSPL/TSPL2 code'), so the schema already does the work. The description only reinforces that the input is TSPL/TSPL2 source; it adds no format, encoding, or size 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 (lint/validate) and resource (TSPL/TSPL2 label code), plus what it returns (structured diagnostics with positions and severity). The language naming implicitly separates it from epl_validate, cpcl_validate and zpl_validate, but it never explicitly says 'use the other validator for other languages'.

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

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

Usage is implied by the verb 'validate' — an agent can infer it is called before printing or after generating TSPL. There is no explicit when-to-use, no preconditions, and no mention of the sibling validators as alternatives for other languages.

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

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

No annotations exist, so the description carries the full load. It does disclose two real behavioral facts: the catalog is curated/maintained (so results are authoritative) and the tool reports whether the preview engine actually renders a command, flagging printer-side commands as not rendered. It says nothing about not-found behavior, completeness guarantees, or response shape beyond the field list.

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

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

A single sentence, front-loaded with the action and resource, that packs the return contents and one important caveat without a wasted clause. Nothing is repeated from the name 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?

With no output schema, the description usefully substitutes by naming the returned fields (name, syntax, parameters with types/ranges/defaults, render status), which is exactly what an agent needs to interpret results. The gaps are minor: unknown-command behavior and whether lookups are exact-match only are unstated.

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 are documented in the schema, including the locale enum and the example command formats, so the baseline of 3 applies. The description adds no meaning beyond that — notably it never mentions the locale parameter or the accepted command-prefix forms.

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 a specific verb and resource ("look up one ZPL command in the maintained catalog") and enumerates what the result contains: name, syntax, parameter types/ranges/defaults, and render support. That is far more informative than a tautology. It stops short of explicitly distinguishing itself from the closest sibling, explain_zpl, which an agent would have to reason about on its own.

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

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

Usage is implied by "look up one ZPL command" — a reference lookup for a single command — but the description never says when to choose it over explain_zpl, zpl_validate, or zpl_compatibility, nor when not to. A reader can infer the catalog-lookup case but gets no routing guidance.

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

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

No annotations exist, so the description carries the burden and does well: it discloses the epistemic posture ('never says it works'), the evidence-level reporting, the size-rule findings, and the preview scope. It doesn't cover determinism, cost, or whether the analysis is static vs simulated beyond the emulator disclaimer, leaving a small 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?

Purpose is front-loaded in the first clause with the model-format hint immediately after, and the negative framing follows as a guardrail. Dense but essentially waste-free; slightly overpacked into long clauses.

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 two fully documented params, no output schema, and no annotations, an agent needs to know what comes back and what the result does not claim — the description covers both (language posture with evidence level, size-rule findings, preview scope, no 'it works' verdict). Minor gaps remain around output shape and whether unsupported models produce an error.

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 both parameters are already documented, including the manufacturer/model example. The description repeats the 'manufacturer/model (e.g. zebra/zd421)' format rather than adding new semantics, so 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 ('Compatibility RISK analysis of ZPL code against a specific printer model') with the exact input format expected. It also pre-emptively separates itself from the emulation/preview siblings by saying 'NOT an emulator' and referencing 'the scope of our preview', so an agent can distinguish it from zpl_preview and zpl_validate without opening a 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?

Clear about the context of use (risk assessment for a given model, not a pass/fail guarantee) and explicitly excludes the emulator interpretation, which is the most likely misread against zpl_preview. It stops short of naming siblings like zpl_validate or stating when to prefer those, so it isn't full routing guidance.

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

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

With no annotations, the description carries the full burden and adds a genuinely valuable behavioral caveat: this is server-side rendering and does not guarantee physical printer output. It does not cover auth requirements, rate limits, or how the resulting PNG is delivered, which keeps it below a 5.

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

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

Two tight sentences with the core action front-loaded and the caveat immediately following. Nothing is wasted or redundant.

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 description names the output format (PNG), which is important since no output schema exists. It leaves open how the image is returned (URL vs. binary/base64) and whether multi-label streams yield multiple images, a minor but real 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 coverage is 100% and every parameter (zpl, dpmm, index, width_in, height_in) is documented inline, so the baseline of 3 applies. The description adds no syntax or semantic detail 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 and resource ("Render ZPL label code to a PNG image") and names the underlying service, so the agent knows exactly what it produces. It does not explicitly contrast with siblings like zpl_validate, but the render-vs-validate distinction is inferable from the 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 phrase "for inspection" implies a visualization use case, but there is no explicit when-to-use guidance or routing to alternatives such as zpl_validate (to check syntax) or zpl_compatibility. The agent must infer the workflow position.

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

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

With no annotations, the description carries the full burden and does well: it discloses machine-readable diagnostics, line/column, code, severity, the error categories checked, speed, and the dependency on real label dimensions. It does not explicitly say the tool is read-only or describe failure behavior, but 'lint' and 'pass/fail' make the safety profile clear enough for a validator.

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

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

The description is front-loaded and compact. Each sentence adds a distinct piece of value: purpose and outputs, usage sequencing, sibling alternative, and parameter importance.

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 four-parameter validator with no output schema and no annotations, the definition supplies the key missing context: diagnostic structure, failure categories, when to call it, when not to call it, and the importance of correct label dimensions. Nothing essential for correct invocation 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%, so the baseline is 3. The description adds meaningful rationale beyond the schema: 'Pass the real label size — checks depend on it,' explaining why the width/height/density parameters matter rather than merely restating their defaults.

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

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

The description states a specific verb and resource: 'Pass/fail lint for ZPL.' It also names the diagnostic categories and distinguishes the tool from zpl_preview and explain_zpl, so an agent can select 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?

It gives explicit sequencing guidance ('run it before zpl_preview whenever you generate or edit ZPL') and an explicit alternative ('For a human-readable report with a score use explain_zpl instead'). This is a strong routing definition.

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