Labelixa

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

With no annotations, the description carries the behavioral transparency burden itself. It discloses that output is a single PNG image, that several symbologies are supported, and that it is not a full-label tool. However, it does not mention error behavior, data validation rules, output delivery details, or size/DPI behavior, which would be useful for a tool with no output schema.

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

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

Two short sentences, no filler. The primary purpose is front-loaded, supported symbologies are compactly listed, and the alternative tool is mentioned in a single useful second sentence.

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 two-parameter tool with no output schema, the description is mostly complete: it states the output format, scope, supported types, and the main alternative. Slightly missing are details about how the PNG is returned or what error cases look like, but these are minor for this tool's simplicity.

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 input schema already documents both `data` and `type`. The description repeats the symbology list but adds no deeper parameter semantics such as constraints, format requirements, or case sensitivity. Baseline 3 is appropriate because the schema carries the parameter-documentation load.

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: generate a single barcode PNG image, and lists the supported symbologies. It also distinguishes itself from zpl_preview by clarifying that zpl_preview is for full labels with text and layout. This leaves no ambiguity about what the tool produces.

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 explicitly tells the agent when to choose zpl_preview instead: when a full label with text and layout is needed. It does not exhaustively compare with every sibling such as barcode_verify or cpcl/epl/tspl previews, but it gives the primary routing guidance clearly.

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. It discloses that decoded results are honest but not authoritative: a 'read' does not guarantee a physical scanner will read it, and a 'not read' does not condemn the label. It could add more detail about error handling or exact response shape, but it covers the key caveat.

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 purposeful sentences, front-loaded with the action and input constraints, followed by an important caveat. There is no filler or redundant 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?

For a one-parameter tool with no output schema, the description adequately covers input formats, purpose, and the interpretation of results. It only sketches the return shape ('report what a software decoder reads back'), but for this simple tool that is sufficient.

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

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

The schema already documents image_base64 as Base64-encoded image bytes with 100% coverage, so the baseline is 3. The description adds meaningful parameter context by requiring photos/scans of printed labels and enumerating supported PNG, JPEG, BMP, and GIF formats, which goes 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 opens with a concrete action ('Decode') and resource ('barcodes from a photo or scan of a PRINTED label'), and clarifies that it reports what a software decoder reads back. This clearly differentiates it from siblings like barcode_png, which likely generate barcodes rather than verify 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 provides clear usage context: use this tool on printed-label photos or scans, and it explicitly lists supported formats (PNG, JPEG, BMP, GIF). It does not explicitly name alternatives or state when not to use it, but the printed-label restriction makes the intended boundary 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, the description bears the full burden of behavior disclosure. It conveys that this is a read-only listing operation, scoped to 'your' jobs, ordered newest first, and containing specific fields. It does not discuss pagination or default limit behavior, but for a simple list tool the essential behavior is disclosed.

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 concise sentences carry the purpose, returned content, ordering, use case, and pointer to an alternative. Every clause earns its place, and the most important information is front-loaded.

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 list tool with one optional parameter and no output schema, the description is complete: it names the returned fields, ordering, a motivating use case, and the sibling to use for more detail. Nothing essential is missing for correct 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 coverage is 100% and the only parameter, limit, is already documented with its meaning and default value. The description adds no additional parameter-level detail, 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 states a specific verb ('List'), the resource ('your recent bulk jobs'), and the key fields returned (id, state, error class, timestamps), with ordering ('newest first'). It clearly differentiates from sibling bulk_status by pointing to it for detailed job info.

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—'Useful to recover a lost job id'—and routes the agent to bulk_status for further details. It does not explicitly state when not to use this tool, but the guidance is clear enough for selection 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, and it does this well. It discloses ownership constraints, state and attempt count, summary contents, per-row failure details, the non-blocking nature of failed rows, and a 7-day retention window via a named REST endpoint.

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 dense but readable, front-loading the core purpose before adding behavioral detail. Every clause adds meaningful information, and it avoids repeating schema or sibling names unnecessarily.

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 tool with no output schema and no annotations, the description explains both what is returned and important behavioral caveats. It covers access scope, timing, failure handling, and retention, so an agent has enough context to call 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?

Schema description coverage is 100%: job_id is already documented as 'Job id from bulk_submit'. The description adds the ownership nuance ('you own') but does not need to elaborate further for a single well-defined 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 identifies the operation as returning status for a single bulk job the caller owns, enumerating specific fields (state, attempt count, summary, failures). This distinguishes it from siblings like bulk_submit or bulk_list by specifying 'one bulk job' rather than submission or listing.

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 clear context: use this when you have a specific job_id from bulk_submit and need status for that one owned job. It does not explicitly name alternatives or say when not to use it, but the single-job scoping and ownership condition are strong enough 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 behavioral burden and does so thoroughly. It discloses authentication requirements, upfront quota charging per row, non-refundable failed rows, plan-based row caps, and the asynchronous nature of the job via bulk_status.

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?

Every sentence earns its place: purpose, input shape, auth requirement, quota/cost warning, row cap, and return behavior. The critical operational warnings are included without fluff, and the core purpose is front-loaded.

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 tells the caller exactly what to expect (job id) and how to follow up (bulk_status). It also covers plan restrictions, quota semantics, and failure costs, making it complete enough for an agent to invoke the tool with appropriate expectations.

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 six parameters. The description adds some framing, such as 'one object per label' and the {{variable}} placeholder pattern, but it does not significantly deepen semantic understanding of dpmm, output, width_in, or height_in 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 names a specific verb and resource: 'Submit a bulk label production job' with one ZPL template and data rows, one object per label. It also distinguishes itself from the sibling status tool by noting it returns a job id and directing the user to bulk_status for checking completion.

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: bulk jobs with a ZPL template and per-label data rows, plus a hard prerequisite that the API key's plan must include bulk jobs. It does not explicitly say when not to use this tool or name alternatives beyond bulk_status, so the exclusion guidance is not fully 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 provided, the description carries the full transparency burden and handles it well. It explicitly discloses that embedded ^GF/~DG image data is NOT scaled and that the response will say so instead of silently passing it through. This is valuable behavioral context beyond a generic rescale promise, though it does not describe the success-response format or other error paths.

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, front-loaded with the main action and supported resolutions, followed by the key caveat. There is no filler and no redundant repetition of schema fields.

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 covers the core operation and the most important exception, making it adequate for basic invocation. However, with no output schema and no annotation support, it leaves the success return value unspecified and does not resolve the 152 DPI discrepancy or same-DPI behavior.

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

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

Schema coverage is only 33%, since source_dpi and target_dpi only have enums and no prose descriptions. The description adds meaning by identifying them as printer resolutions and explaining what gets scaled, but it omits 152 from the parenthetical even though the schema allows it, and it does not clarify same-DPI or invalid-combination behavior.

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: 'Rescale ZPL between printer resolutions', then enumerates exactly what is scaled (coordinates, fonts, barcode module width, label size). This clearly distinguishes it from sibling ZPL tools, which are mostly preview/validate/explain operations.

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 intended use is implied: call this when ZPL needs to be rescaled from one printer DPI to another. However, it does not explicitly state when not to use it, name alternative sibling tools, or address what to do if the requested DPI combination is unsupported.

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 proactively states the 203 dpi assumption, the core-command-subset limitation, the lack of physical printer validation, and the label/warning counts in the response. This is strong transparency for a rendering tool.

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 core function and output are front-loaded, and the caveats are packed into a single efficient second sentence. Every clause adds useful 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?

The description covers the purpose, key rendering assumptions, limitations, and response summary, which is enough for an agent to decide whether and how to call it. It does not specify how the PNG is returned (e.g., base64 versus a URI), but the absence of an output schema makes this a minor gap rather than a blocker.

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% for the single 'cpcl' parameter, and the schema already identifies it as raw CPCL code. The description reinforces the CPCL context but does not add new parameter-level detail such as encoding, size limits, or accepted command syntax, so the baseline 3 applies.

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

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

The description states a specific verb ('Render'), a resource ('CPCL label code'), and a concrete output ('PNG preview'). It is clearly distinguished from sibling tools like cpcl_validate (validation vs. rendering) and epl_preview/zpl_preview/tspl_preview by naming CPCL explicitly.

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

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

The description makes the intended use case clear: when you have raw CPCL code and want a rendered preview as a PNG. It does not explicitly mention alternatives or exclusion conditions, such as 'use cpcl_validate for validation instead,' so it stops short of the full 5.

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 disclosure burden. It does disclose the key behavior: statically linting CPCL input and returning JSON findings with severity and position. However, it does not mention error behavior, response structure nuances, or whether any external calls occur, leaving some behavioral uncertainty.

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 the primary verb front-loaded. Every clause earns its place: the action, the target format, and the output type. No filler or redundancy.

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

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

For a one-parameter, side-effect-light linter, the description provides a usable input/output contract. The main gap is that no output schema exists and the description does not specify the exact shape or field names of the returned JSON findings, so an agent may need to infer how to consume them.

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%; the schema already describes the single parameter as 'Raw CPCL code'. The description's mention of 'CPCL label code' adds no new semantic detail such as encoding, format constraints, or examples.

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 ('Lint'), a specific resource ('CPCL label code'), and the return form ('positioned findings with severity as JSON'). This clearly distinguishes it from render-oriented siblings like cpcl_preview and from validators for other languages such as zpl_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 gives no explicit when-to-use guidance and names no alternatives or exclusions. An agent must infer from the tool name and the word 'CPCL' that this is for validating CPCL code rather than e.g. using zpl_validate or rendering via cpcl_preview.

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 the 203 dpi assumption, the core-command-subset interpretation, the lack of physical printer validation, and the response's label/warning counts. It does not detail error behavior for malformed or unsupported EPL, but the stated interpretation implies such 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?

Two tight sentences with no filler. The primary action is front-loaded, and the most important caveats (dpi, subset interpretation, no physical validation, response counts) are packed in 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 single-parameter, preview-only tool with no annotations and no output schema, this description is complete. It gives the input type, the output format (PNG preview), key rendering assumptions, limitations, and what the response reports.

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 already documents 'epl' as raw EPL/EPL2 code with 100% coverage, so the baseline is 3. The description adds meaningful context by explaining that the input is interpreted under a 203 dpi, core-command-subset model, which helps the agent set expectations for what commands will render correctly.

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: 'Render EPL/EPL2 label code and return a PNG preview.' It clearly distinguishes itself from sibling validation tools by emphasizing previewing rather than physical validation, so an agent can understand its role among epl_validate, cpcl_preview, and 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?

The description clearly implies usage for EPL/EPL2 previews with the caveat that it is not physical printer validation. It does not explicitly name alternative tools such as epl_validate, but the context is sufficiently clear about what this tool is for and its limitation.

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 disclosure burden. It usefully states that the tool returns JSON with positioned findings and severity, and 'Lint' implies a non-mutating analysis operation. Yet it does not clarify what 'positioned' means precisely, possible 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?

A single sentence delivers the core purpose and the key output characteristic with no filler. The action, target, and result are all front-loaded and easy to parse.

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 tool with no output schema and no annotations, the description covers the essential inputs and outputs: raw EPL/EPL2 code in, positioned severity findings as JSON out. It could add a little more detail about finding structure or when validation is useful, but the core information needed to call it 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% because the only parameter, 'epl', is described as 'Raw EPL/EPL2 code'. The tool description adds no extra parameter-level detail beyond confirming the code format, so the schema already carries the semantic weight.

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 identifies a specific verb ('Lint'), a specific resource ('EPL/EPL2 label code'), and the output shape ('positioned findings with severity as JSON'). This distinguishes it from sibling validators and preview tools by language and function.

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 use for EPL/EPL2 validation, which differentiates it from cpcl_validate, tspl_validate, and zpl_validate. However, it does not explicitly state when to choose this tool over alternatives, mention validation before previewing, or note any exclusions.

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. It discloses that the output is sectioned, that a score is produced, that unassessable sections are explicitly flagged, and that they are excluded from the score. This is substantive transparency about output shape and limitations, though it does not explicitly state read-only behavior or potential side effects.

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, dense, front-loaded sentence that delivers the core purpose, output structure, and scoring behavior without wasted words. Every clause carries relevant 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?

Given the absence of an output schema and annotations, the description explains the report structure and scoring policy well. However, it omits any guidance on parameter usage (especially dpmm/width_in/height_in) and does not provide alternative routing, leaving an agent with some ambiguity for a relatively complex tool.

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 only 25% (only 'zpl' is described). The description fails to clarify the meaning or role of dpmm, width_in, and height_in, even though 'size/DPI' hints at them. With such low schema coverage, the description needed to compensate for parameter semantics but does not.

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

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

The description gives a specific verb ('health report') and a clear resource ('ZPL label') and enumerates distinct analysis dimensions (syntax, size/DPI, orientation, barcodes, fonts, graphics memory, job behaviour). This clearly differentiates it from siblings like zpl_validate, zpl_preview, and zpl_command_help, which imply validation, rendering, or command reference rather than a full diagnostic report.

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 tool is for holistic analysis and scoring of ZPL labels, but it never explicitly states when to prefer this over zpl_validate or zpl_preview, nor does it mention exclusions. The use case is inferable from 'Full health report' but not directly guided.

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 disclosure burden and covers the key traits: accepted formats, the 200 KB input ceiling, the output variant (^GF), and the return payload (ZPL plus measured dimensions and physical print size at the chosen density). It does not disclose failure behavior for oversized inputs or whether images are resized, but the essential operational behavior is transparent.

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 zero filler: the first front-loads the core purpose with format and size constraints, the second packs the return contents and the PDF routing exception. Every clause earns its place.

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

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

With no output schema, the description correctly explains what is returned (ZPL, measured dimensions, physical print size). Input formats, the 200 KB limit, and the PDF exclusion are all covered, and the schema handles parameter semantics. Remaining gaps — error behavior on oversize input and resizing behavior — are minor for a converter of this simplicity.

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% — every parameter (image_base64, dpmm, wrap, dither) already has a meaningful schema description, so the baseline is 3. The description adds only marginal semantics by linking 'the chosen density' to the physical print size output, tying dpmm to the return value.

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 ('Convert'), a resource ('an image'), and a precise output ('ZPL ^GF graphic command'), while naming supported formats (PNG, JPEG, BMP or GIF) and a size limit (max 200 KB). This clearly differentiates it from all siblings, none of which convert images to ZPL.

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

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

Provides one explicit exclusion with an alternative: 'PDF input is REST-only (/v1/graphics)', which prevents an agent from sending PDF through this tool and routes it to the right path. However, it gives no broader guidance on when to prefer this tool over related siblings such as convert_zpl_dpi or zpl_preview, so the selection guidance is partial rather than comprehensive.

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 transparency burden. It discloses that the tool is heuristic, returns a confidence tier rather than a probability, and includes signal codes. This is strong behavioral disclosure, though it does not detail ambiguity or failure behavior for unrecognizable input.

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 purpose is front-loaded, and the key caveat about heuristic confidence tiers and signal codes is included without unnecessary detail.

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 simple one-parameter input, no annotations, and no output schema, the description provides enough information to invoke the tool correctly: what input to send and what kind of output to expect. It could specify exact signal codes or fallback behavior, but it is largely complete for a tool of 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?

Schema description coverage is 100%, and the 'code' parameter is already described as 'Raw label code to classify'. The description adds no additional parameter-level semantics, but because the schema fully covers the input, the baseline score 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 states a specific action ('Detect'), a specific resource ('which printer language raw label code is written in'), and enumerates the possible languages (ZPL, EPL, TSPL, CPCL). This clearly distinguishes it from sibling validation and preview tools, which assume or validate a specific language rather than identifying an unknown one.

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 intended use is clear: pass raw label code to determine its language. It does not explicitly name alternatives or exclusion cases, but the context is strong enough that an agent can infer this tool is for classification before language-specific tools like zpl_validate or cpcl_preview are used.

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 behavioral burden and mostly succeeds: it discloses conditional premium behavior, that ZPL requires a qualifying API key, and that metadata is always returned. It doesn't cover error behavior or rate limits, but this is strong for a read-oriented fetch tool.

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 sentence front-loads the operation, target, and expected payload, while the second adds the necessary premium/API-key condition.

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 no output schema and no annotations, the description adequately explains what is returned, under what conditions, and how the output relates to zpl_preview. Nothing critical is missing for an agent to invoke 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?

The input schema already documents the only parameter fully, including that template_id comes from template_list. The description adds no additional parameter-specific meaning, so the schema-coverage baseline of 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?

Description names a specific operation ('Fetch one catalog template') and clearly identifies the resource. It distinguishes itself from sibling template_list by emphasizing a single template and enumerating the returned fields (metadata, preview image URL, ZPL source).

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

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

Provides clear context for when to use the tool: to retrieve a single template's data and feed it into zpl_preview. It also explains the premium-template condition for ZPL access, though it does not explicitly name alternative tools or state when not to use 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 burden, and it does disclose important behavior: 'Read-only product content (no tenant data).' It does not mention pagination or response format, but the read-only safety scope is clearly stated.

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 action and resource are front-loaded, followed by return fields, safety scope, and sibling routing. Every clause adds value.

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, low-complexity listing tool with no annotations and no output schema, the description covers what is returned, that it is read-only, and what to use for related operations. Pagination/limits are not mentioned, but this is not a critical gap for an optional-filter catalog listing.

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 parameters are already well documented. The description adds no detail beyond the schema about search or category filtering, so it earns the baseline score.

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 ('List'), a precise resource ('Labelixa's first-party label template catalog'), and the output fields (id, English name, category, size/density, tags). It also differentiates from siblings by pointing to template_get for fetching one and zpl_preview for rendering.

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

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

Provides clear routing: 'Fetch one with template_get; render its ZPL with zpl_preview.' This tells an agent when template_list is the wrong choice, though it lacks an explicit 'do not use when' clause for the listing itself.

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 and does so well. It openly discloses the 203 dpi assumption, the interpreted/core-subset nature of rendering, the lack of physical printer validation, and the fact that the response reports label and warning counts. These are non-obvious behaviors an agent needs to know before invoking the tool.

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 tight sentences with the core action front-loaded and only high-value caveats following it. Every clause earns its place, with no filler, repetition, or vague language.

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

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

For a single-parameter tool with no annotations and no output schema, the description is complete: it states the input, the output, the rendering assumptions, the limitation scope, and what the response reports. An agent has enough context to use the tool correctly and to set expectations about fidelity and return contents.

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 provides 100% coverage for the sole required tspl parameter. The description echoes 'TSPL/TSPL2 label code' but adds no additional syntax, formatting, size, or constraint guidance beyond what the schema states, so it stays at the baseline rather than adding value.

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 ('Render') and target resource ('TSPL/TSPL2 label code'), and clearly names the output ('PNG preview'). This differentiates it from validation-focused siblings like tspl_validate and from preview tools for other languages like zpl_preview, cpcl_preview, and epl_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?

The description gives clear context for when to use this tool: to produce a visual preview of raw TSPL/TSPL2 code. It also states important limitations—203 dpi assumption, core command subset, and no physical printer validation—which help an agent decide not to use it for exact printer validation. It does not explicitly name an alternative tool like tspl_validate, so it falls just short of 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 must carry the behavioral burden. It does disclose a useful behavior: the tool returns positioned findings with severity as JSON. However, it does not explicitly state that this is read-only analysis or describe behavior when the code passes validation.

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 packs purpose and output into a readable, front-loaded format with no filler. Every clause earns its place.

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

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

For a one-parameter lint tool with no nested schema or annotations, the description covers what to pass and what to expect in return. It could be more explicit about output shape when no issues are found, 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?

The schema already documents the single parameter at 100% coverage. The description's phrase 'label code' adds little beyond the schema's 'Raw TSPL/TSPL2 code,' so the baseline of 3 applies.

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

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

The description names a specific operation ('Lint'), a specific resource ('TSPL/TSPL2 label code'), and states the output ('positioned findings with severity as JSON'). This distinguishes it from sibling validators/preview tools by both language and action.

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 when-to-use guidance or exclusions are given. It does not mention alternatives such as tspl_preview or other language validators, so an agent must infer selection solely from the tool 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, the description carries full burden. It discloses what the tool returns, including parameter types/ranges/options, an example, and renderer support, and identifies the data source. It does not detail side effects, but for a help/explain tool the behavior is adequately transparent.

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 succinct sentences with no filler. The first sentence front-loads the core purpose and expected output, and the second adds only useful provenance information about the data source.

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 has one well-documented parameter, no output schema, and simple informational behavior. The description covers what the tool does, what content it returns, and where the data comes from. Nothing critical is missing for an agent to select and 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 single parameter is fully documented in the schema with a description and examples, so schema coverage is 100%. The description reinforces that this is a single command but does not add additional parameter-level semantics 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 and resource: it explains a single ZPL command, and enumerates the exact content an agent can expect (syntax, parameters, options, example, renderer support). The word 'single' helps distinguish it from the broader sibling explain_zpl.

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 makes the usage context clear: it is for looking up details about one individual ZPL command. It does not explicitly state when not to use it or name alternatives, but the 'single ZPL command' scope is a strong cue for when this tool is appropriate.

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 does meaningful work here. It discloses that the tool performs risk analysis, does not emulate, never makes a definitive 'it works' claim, and reports evidence level and size-rule findings. It does not discuss side effects, rate limits, or failure modes, but the tool's analytical nature makes these less critical.

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 dense sentence that front-loads the core purpose and then adds important boundaries and output expectations. There is no filler, and every clause contributes useful 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?

The description gives a useful high-level summary of what the tool reports, but with no output schema it leaves the exact return structure undefined. Terms like 'language posture' and 'size-rule findings' are not explained, so an agent may need to invoke the tool to discover the precise output format.

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 the two parameters. The description adds an example ('zebra-zd421') and frames the analysis, but it does not add meaningfully new semantic details 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 uses a specific verb and resource: 'Compatibility RISK analysis of ZPL code against a specific printer model.' It also clearly distinguishes itself from an emulator and from validation tools by stating it 'never says it works.' This is more than enough for an agent to identify what the tool does.

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 establishes a clear context for use: assessing compatibility risk against a specific model. It also gives an explicit exclusion ('NOT an emulator') and a boundary ('never says it works'), which helps prevent misuse. However, it does not name alternative sibling tools or explicitly state when to use them instead.

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?

There are no annotations, so the description carries the full burden. It discloses that the tool returns a PNG image, renders one label per call, and supports selecting a label from a multi-label stream via `index`. This gives a solid behavioral picture, though it does not discuss error behavior for invalid ZPL or any limits.

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

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

The description is two sentences with no filler. The core purpose is front-loaded, and the second sentence adds both the practical motivation and the important multi-label indexing behavior. Every clause earns its place.

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

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

The description covers the essential context: what it renders, what it returns, why to use it, and how indexing works. With no output schema, specifying PNG as the return format is especially valuable. It stops short of covering error cases or parameter interactions, but the overall guidance is sufficient for an agent to use 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds a useful mention of `index` for picking from a multi-label stream, but otherwise does not provide semantic details beyond what the schema already states.

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 and return the label as a PNG image.' It clearly states the tool's purpose and output, making it easy to distinguish from validation tools like zpl_validate or other language previews like epl_preview and cpcl_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?

The description gives a clear use case: use when you need to SEE what ZPL output looks like, since LLMs cannot otherwise verify the visual result. It also explains the one-call-per-label behavior with the `index` parameter, but it does not explicitly name sibling alternatives or situations where another tool should be preferred.

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 behavioral burden on its own. It states the tool returns structured diagnostics and lists what those diagnostics cover, making the read-only lint behavior clear. It could add output shape details, but the core behavior is adequately disclosed.

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 sentence front-loads the action and output type, and the second gives actionable workflow guidance. 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 straightforward lint tool with no output schema and no annotations, the description provides selection cues, invocation timing, the required input, and expected output type. The missing parameter semantics and diagnostics shape are weaknesses, but the tool remains callable and appropriately contextualized.

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

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

Schema description coverage is only 25% (only 'zpl' is described). The description does not compensate by explaining dpmm, width_in, or height_in, their units, or how they determine the label boundary. This is a meaningful gap for low schema coverage.

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 ('Lint'), a specific resource ('ZPL code'), and enumerates concrete diagnostic checks (unknown commands, missing ^FS, out-of-range parameters, fields outside label boundary). This clearly distinguishes it from other-language validators and from 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?

The instruction 'Run this before zpl_preview when generating ZPL' gives explicit when-to-use context and positions it in a workflow. It does not mention exclusions or alternatives like zpl_compatibility, so it stops short of full guidance.

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