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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions output formats (SVG/PNG) but omits critical behavior such as data validation constraints (e.g., EAN-13 requires specific digit lengths), error handling, whether the tool is synchronous, or any side effects. The absence of such information leaves the agent underinformed about potential failures or limitations.

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

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

The description is a single, well-structured sentence that leads with the core action and output, followed by the supported types. There is no superfluous content, and the information is front-loaded, making it easy for an agent to quickly understand the tool's purpose and capabilities.

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

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

For a tool with 3 parameters, no output schema, and no annotations, the description covers the primary purpose and output format but lacks details on data constraints per barcode type, return value specifics, and error behavior. While an agent can infer basic usage, the absence of these details makes the tool only minimally complete for reliable invocation.

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

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

Schema description coverage is 67% (data and type have descriptions, format does not). The description adds value by listing all supported barcode types, which goes beyond the type parameter's generic example, and by clarifying the 'format' parameter with 'SVG text or PNG image'. This compensates for the missing format description and provides essential context for parameter selection.

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

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

The description clearly states the tool's function: 'Generate a standalone barcode' with explicit output formats (SVG text or PNG image) and a comprehensive list of supported barcode types. This verb+resource combination makes the tool's purpose unambiguous and distinct from the sibling tools, which are all focused on label language validation and preview rather than barcode generation.

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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any conditions, exclusions, or references to sibling tools (like validation or preview tools). An agent must infer that this tool is for generating standalone barcodes, but there is no explicit 'use when' or 'instead of' directive.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the critical non-obvious behavior that embedded ^GF/~DG bitmap data is NOT rescaled and that a Warnings block is emitted instead of silent passing. It does not fully specify the output structure, but it covers the most important behavioral edge case.

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

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

The description is two sentences with no filler. The core action is front-loaded, and the critical caveat about bitmap data follows immediately with a clear behavioral consequence.

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 stateless conversion tool, the description is nearly complete: it states the conversion purpose and the important warning behavior. The only gap is that it doesn't explicitly state the returned value is the converted ZPL string, but that is strongly implied by 'output' and the conversion 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 documentation coverage is 100%, so the baseline is 3; the description adds no additional parameter semantics beyond what the schema already states. The dpi values listed in the description overlap with the schema's allowed values, though it omits 152 dpi, which is minor.

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 ('Rescale') and resource ('ZPL coordinates between printer resolutions'), immediately distinguishing it from sibling validation and preview tools. The mention of 203/300/600 dpi, plus the bitmap-data caveat, makes the tool's scope precise.

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 clearly implies when to use the tool: when ZPL coordinates need conversion between printer resolutions. It doesn't explicitly list when not to use it or name alternative tools, but the context is unambiguous enough for an agent to select it correctly among 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions 'lint/validate' and 'return the structured diagnostics report (findings with positions and severity) as JSON', it does not explain what happens on invalid input (e.g., error messages, exit codes), whether it mutates anything (it shouldn't, but it's not stated), or if there are any side effects. For a read-only validation tool, the lack of explicit non-destructive confirmation is a 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?

The description is a single, complete sentence that is front-loaded with the core action ('Lint/validate CPCL label code') and then details the output. It has no filler words and every part earns its place.

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

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

For a tool with a single parameter and no output schema, the description covers the main purpose and return type. However, it lacks important context such as example input/output, error handling, or limitations. Given the simplicity, it is adequate but not exhaustive.

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 describes the parameter ('cpcl') with a description 'Raw CPCL code'. The tool description adds the context that this code is 'label code' to be validated, but it doesn't add syntax or format details (e.g., encoding, maximum length). Since schema coverage is 100%, the baseline is 3, and the description adds only marginal value by clarifying the purpose of the parameter.

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

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

The description clearly states what the tool does: 'Lint/validate CPCL label code' and specifies the resource (CPCL label code). It distinguishes itself from siblings like zpl_validate by explicitly focusing on CPCL, which is a different label language. The verb 'Lint/validate' is specific and action-oriented.

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 does not provide any guidance on when to use this tool versus alternatives. It doesn't mention scenarios where CPCL validation is preferred over other validation tools (e.g., zpl_validate, epl_validate, tspl_validate). There are no explicit exclusions or conditions, leaving the agent to infer usage from the language name.

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

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

With no annotations provided, the description carries the full burden and discloses the core behavior: it returns a structured diagnostic report with findings, positions, and severity as JSON. This goes beyond merely restating the tool name and informs the agent of the return format, though it does not explicitly address side effects 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 a single sentence with no filler, front-loading the action and resource and immediately stating the output format. Every part earns its place.

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

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

For a simple one-parameter lint/validate tool with a fully documented input and no output schema, the description is complete: it names the input, the operation, and the structured JSON output. An agent has enough information to invoke it 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?

The schema fully documents the single parameter ('Raw EPL/EPL2 code') with 100% coverage, so the description does not need to add much. The description does not repeat or add parameter details, but the schema already provides sufficient meaning.

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 uses a specific verb pair ('Lint/validate') and clearly identifies the resource ('EPL/EPL2 label code') and the deliverable (a structured diagnostics report as JSON). It differentiates from sibling tools like zpl_validate and tspl_validate by naming the exact language family.

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 clearly establishes the context for use: validating EPL/EPL2 label code and receiving structured diagnostics. It does not explicitly name alternatives, but the language-specific resource makes the appropriate selection unambiguous.

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 disclose meaningful behavior: the report is sectioned, only assessable sections count, and unassessable ones say 'not assessed'. It also explains that findings depend on the supplied label size. It stops short of covering auth, side effects, or rate limits, but for an analysis/report tool the core behavioral traits are well communicated.

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

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

The definition is front-loaded with the key purpose and score, then routes to the alternative, then adds the important parameter caveat. It is dense but every sentence carries useful information, though the parenthetical section list makes it slightly packed.

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 usefully explains the return shape: a sectioned health report with a 0-100 score and explicit 'not assessed' sections. Combined with the parameter guidance, it is complete enough for correct invocation, with only minor gaps around edge cases such as invalid ZPL.

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 already 100%, so the baseline is 3, but the description adds operational meaning beyond the schema by stressing that the real label size must be passed because findings depend on it. The mention of optional model-driven compatibility is already in the schema, but the emphasis on size parameters is useful guidance.

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: a human-readable health report for a finished ZPL label with a 0-100 score and named sections. It explicitly distinguishes itself from the sibling zpl_validate by contrasting review/explanation with a quick pass/fail check.

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 an explicit use case (review or explain a label to a person) and names the alternative tool for the adjacent use case (zpl_validate for quick pass/fail while editing). It also adds a concrete prerequisite: 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 provided, the description carries the full burden. It discloses that the tool is heuristic, returns a confidence tier (high/medium/low) and signal codes, and explicitly states it does not return a probability. This gives the agent important expectations about output quality and format, though it doesn't elaborate on error handling or edge cases.

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 concise, with the core purpose front-loaded in the first sentence and a supplementary detail in the second. There is no fluff, and every word earns its place.

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

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

Given there is no output schema, the description appropriately explains the return structure (language, confidence tier, signal codes) and clarifies the heuristic nature. It covers the essential information an agent needs to interpret results, though it could mention how to handle ambiguous inputs or what signal codes mean in practice.

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% since the single parameter 'code' is well-documented as 'Raw label code to classify'. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is 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?

The description clearly states the tool's purpose: detecting the printer language (ZPL, EPL, TSPL, CPCL) from raw label code. It uses a specific verb ('detect') and enumerates the exact resource types, which distinguishes it from language-specific validators like zpl_validate or epl_validate.

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 implies the use case: when you need to identify the language of raw label code. However, it does not explicitly mention alternatives or provide conditions for when to use this tool versus the sibling validation/preview tools. The guidance is implied rather than explicit.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It does state that the tool returns a structured diagnostics report as JSON, which is a useful behavioral detail. However, it does not disclose side effects (e.g., read-only, no modification) or error handling behavior, leaving some uncertainty for a mutation-averse agent.

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 that front-loads the purpose and immediately states the output format. No filler, no redundancy. It earns its place efficiently.

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 single-parameter validator, the description covers the input (TSPL/TSPL2 code) and the output (structured JSON report with positions and severity). It does not describe edge cases or failure modes, but those are minor for a lint tool. The description is adequate for an agent to invoke the 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?

The schema covers the single parameter fully (100% coverage) with a description ('Raw TSPL/TSPL2 code') that matches the tool description. The description adds no additional meaning beyond the schema; it only repeats the language type. Baseline of 3 applies because schema already documents the parameter adequately.

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

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

The description clearly states a specific verb ('Lint/validate') and resource ('TSPL/TSPL2 label code'), and specifies the output as a structured JSON diagnostics report. It differentiates from sibling validators (zpl_validate, epl_validate, cpcl_validate) by naming the target language explicitly, so an agent can select it without confusion.

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 implies it is for TSPL/TSPL2 code but does not explicitly state when to use this tool versus alternatives (e.g., 'use zpl_validate for ZPL'). There are no exclusions or conditions, so usage context is implied rather than explicit.

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

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

With no annotations present, the description carries the full transparency burden. It does more than describe the action by revealing a behavioral nuance: preview-engine render support is reported honestly, and printer-side commands are explicitly marked as not rendered. It does not cover edge behavior like unknown command codes, but it offers meaningful context beyond the schema.

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

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

The description is a single front-loaded sentence that starts with the action and resource, then packs the returned fields and the rendering caveat into a colon-separated list. There is 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?

No output schema exists, so it is important that the description summarizes the returned data: name, syntax, parameter types/ranges/defaults, and renderability. It provides enough context for a straightforward lookup tool, though exact output formatting and error behavior are not described.

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 schema already documents the command code format and locale semantics. The description only says it returns parameter metadata and does not add new meaning to the tool's own input parameters.

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 opens with a specific action ('Look up one ZPL command') and a clear resource ('maintained catalog'), then enumerates the returned content. It does not explicitly distinguish itself from the similar-looking explain_zpl sibling, so it misses the highest bar for sibling differentiation.

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 'Look up one ZPL command' implies the intended use case, but there is no explicit statement of when to prefer this over siblings such as explain_zpl, zpl_validate, or zpl_preview. No exclusion or conditional guidance is provided, so usage is only implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states what the tool reports (language posture, evidence level, size-rule findings, scope of preview) and what it never claims ('it works'). This gives the agent a clear understanding of the tool's output and limitations, which is more than most descriptions 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?

The description is two sentences with zero fluff. It front-loads the purpose and immediately disambiguates from an emulator, then enumerates the output components. Every clause earns its place, and the structure is easy to parse quickly.

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?

Despite having no output schema, the description lists the key elements the tool returns (language posture, evidence level, size-rule findings, scope of preview), which gives the agent a reasonable expectation of the response. It also covers the model format. It doesn't go into exhaustive detail on output structure, but for a risk-analysis tool this is sufficient for an agent to decide whether to invoke it.

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 input schema already describes both parameters with 100% coverage. The description adds value by giving a concrete example for the model parameter ('zebra/zd421') and clarifies the expected format (manufacturer/model). This goes beyond the schema's generic description and helps the agent construct valid input.

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

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

The description clearly states a specific verb and resource: 'Compatibility RISK analysis of ZPL code against a specific printer model'. It also distinguishes itself from an emulator and explicitly states it never says 'it works', which sets it apart from sibling tools like zpl_preview and zpl_validate. The example manufacturer/model format further anchors the purpose.

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

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

The description gives clear context: it is for compatibility risk analysis, not emulation, and it explicitly says 'NOT an emulator'. It also implies its role by mentioning 'reports the model's language posture', which signals it is for assessment, not validation or preview. However, it does not explicitly name sibling tools as alternatives (e.g., 'use zpl_validate for syntax checking'), leaving the agent to infer the distinction from 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?

With no annotations, the description carries the full burden. It usefully discloses that rendering happens server-side via an external API and that the output is not a guarantee of physical printer behavior, but it omits whether the call is read-only/non-destructive, whether authentication is required, and how errors are surfaced.

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, both earning their place: the first states the core action and output, the second front-loads the key limitation. There is no redundant or filler text.

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 five-parameter render tool with full schema coverage and no output schema, the description covers the essential return type (PNG image) and the most important behavioral caveat (printer fidelity). It leaves minor gaps around error handling and multi-label behavior, but the schema covers the latter via the 'index' parameter.

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 are already documented in the input schema. The description adds no additional meaning about the 'zpl', 'dpmm', 'index', 'width_in', or 'height_in' parameters, so the baseline of 3 is 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 ('Render ZPL label code to a PNG image') and names the backend API. It is clearly distinct from validation or help siblings, but it does not explicitly name or contrast with alternatives like zpl_validate or barcode_generate.

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 the tool is for previewing output before printing, and the caveat about physical printers hints at when not to treat the result as authoritative. However, there is no explicit when-to-use or when-not-to-use guidance, and no sibling tools are named as alternatives.

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 behavioral burden and does well: it discloses that diagnostics are machine-readable with line/column, code, and severity, covers diagnostic categories, and notes the tool is fast. It does not explicitly state that validation is read-only or whether it stops at the first error, but the core behavior is clear.

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 compact and front-loaded with the core validation purpose and output shape. Each sentence adds useful routing, prerequisite, or parameter guidance 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?

For a four-parameter validation tool with a fully documented schema and no output schema or annotations, the description supplies enough: purpose, diagnostic format, usage sequencing, alternative tool, and the important label-size dependency. No critical information for correct invocation appears 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%, so the parameter details are already documented. The description adds useful semantic guidance by stressing that the real label size should be passed because validation checks 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 names a specific operation, 'Pass/fail lint for ZPL,' and explains the diagnostics it returns. It clearly distinguishes this validation tool from zpl_preview and explain_zpl, so an agent can select it without opening sibling schemas.

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 run it before zpl_preview whenever generating or editing ZPL, and routes human-readable reporting to explain_zpl. It also states that the real label size must be passed because checks depend on it.

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