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. It discloses that only assessable sections count and others are marked 'not assessed', and that findings depend on the label size. This gives the agent a clear picture of the tool's behavior and limitations, though it doesn't mention error handling or the exact return structure.

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. The purpose is front-loaded, and the key usage tip is placed at the end. Every word earns its place.

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

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

For a complex tool with no output schema, the description explains the report's scope and scoring honesty. It covers the main concerns an agent would have, but could arguably mention that the report might be lengthy or that it returns a structured result. Still, it's sufficiently complete for an agent to decide to call 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by emphasizing the critical role of width_in and height_in ('Pass the real label size') and implicitly tying them to the size/DPI section. This goes beyond the schema's basic type/description info.

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 produces a 'Full sectioned health report for a ZPL label' and enumerates specific aspects (syntax, size/DPI, orientation, barcodes, fonts, memory). It distinguishes itself from siblings like zpl_validate (which likely only validates) and zpl_preview (rendering) by emphasizing a comprehensive diagnostic report with an honest scoring mechanism.

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 an important usage hint ('Pass the real label size — findings depend on it') but does not explicitly state when to use this tool versus alternatives like zpl_validate or zpl_compatibility. It implies it's for a detailed health assessment, but lacks explicit exclusions or alternative routing.

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?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that this is a server-side render via an external API and warns that output is not a guarantee of physical printer output. However, it does not describe return format, error behavior, or external-API implications such as latency or failures.

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 with no filler: the first states the core action, and the second delivers a relevant caveat. It is appropriately front-loaded and every phrase earns its place.

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

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

For a moderate external rendering tool with all parameters documented and no output schema, the description provides the essential selection and invocation context: what it renders, how, and a key limitation. It is slightly light on post-call behavior (how the PNG is returned or errors surface), but the core context is present.

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

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

Schema description coverage is 100%, with each parameter already documented including defaults and constraints. The description adds no parameter-level nuance beyond identifying the input as ZPL label code, so the baseline 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 opens with a specific verb and resource: 'Render ZPL label code to a PNG image via the Labelixa API.' It adds a clear differentiating qualifier ('SERVER-SIDE render for inspection'), which makes it easy to tell apart from validation/explanation siblings like zpl_validate and explain_zpl even without naming them.

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

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

The description gives clear usage context ('for inspection') and an explicit exclusion: it is 'not a guarantee of how a specific physical printer will output the label.' It does not name sibling alternatives or state when to prefer zpl_validate, but the intended use case is reasonably clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns a structured diagnostics report as JSON and lists the categories of checks performed (unknown commands, parameter range errors, layout overflow). It also hints that results depend on label size. It does not explicitly declare read-only behavior, but the nature of a validator and the mention of returning a report strongly imply a non-destructive operation. This is adequate for a validation tool, though it could mention whether it modifies anything or requires authentication.

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 fluff. The first sentence front-loads the purpose and output, and the second adds a critical usage tip. Every word earns its place, and the structure is efficient and clear.

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

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

Given the tool's moderate complexity (4 parameters, no output schema), the description is complete enough for an agent to call it correctly. It states the input (ZPL), the output (JSON report), and the dependency on size parameters. It does not describe the exact JSON structure, but that is not strictly required since the description says 'structured diagnostics report' and lists common error types. It also implicitly distinguishes from other validators via the tool name. Minor omissions like behavior on success are easily inferred.

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% as all four parameters have descriptions in the schema, providing the baseline of 3. The description adds value by explicitly emphasizing the importance of the size parameters ('Pass the real label size — checks depend on it.'), which goes beyond the schema's terse descriptions of width_in and height_in. It informs the agent that these parameters materially affect the tool's behavior, making it more than a bare restatement.

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 verb 'Lint/validate' and the resource 'ZPL', and specifies the output as a structured diagnostics report in JSON with examples of error types. It differentiates from sibling validators by explicitly naming ZPL, making it unambiguous which language it handles.

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

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

The description provides a clear, actionable usage instruction: 'Pass the real label size — checks depend on it.' This gives context on how to use the tool effectively, but it does not explicitly mention when to use this tool over sibling validators like epl_validate or tspl_validate, nor does it state exclusions. It implies usage for ZPL validation via the name and content, so it earns a 4 for clear context without explicit alternatives.

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