Thermal label MCP server: render, validate, debug and convert ZPL, EPL, TSPL and CPCL labels.
Scored across 21 tools
Each tool is mostly distinct: preview vs validate vs compatibility vs command help are clearly separated by descriptions, and per-language tools are organized consistently. Minor potential overlap exists between zpl_validate and explain_zpl, and between some preview/validate pairs, but descriptions make the intended use clear.
Names are consistently snake_case and use recognizable domain prefixes, especially the language_preview/validate sets. There are minor deviations in convention: some tools use noun_verb order (barcode_png, template_get, image_to_zpl) while others use verb_noun order (explain_zpl, convert_zpl_dpi).
21 tools is slightly heavy but reasonable for a multi-language label toolkit covering ZPL, EPL, TSPL, and CPCL previews/validation, plus barcodes, templates, bulk jobs, and conversion utilities. The count is justified by the breadth of supported printer languages and workflows.
The surface covers label generation, preview, validation, barcode creation/verification, image conversion, template access, and bulk production with status tracking. Minor gaps exist, such as no bulk job cancellation and no template write operations, but these are defensible for the product scope.
Generate a single barcode as a PNG image (Code 128, QR, DataMatrix, EAN-13, UPC-A, PDF417 and more). For a full label with text and layout, write ZPL and use zpl_preview instead.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data to encode | |
| type | No | Symbology (code128, qr, datamatrix, ean13, upca, pdf417...) | code128 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scope ('single barcode') and the PNG output format, and explicitly contrasts with full-label generation. It does not contradict annotations and adds useful context beyond them.
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 waste. The main purpose is front-loaded, and the alternative guidance is concise and clear. Every sentence 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 two-parameter tool with full schema coverage, annotations covering safety, and a description that states the single-barcode scope and the alternative for full labels, everything an agent needs to call it correctly is present. No output schema is needed since the output is described as a PNG image.
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% – both parameters have descriptions in the schema. The description adds a little by listing symbologies and noting 'and more', but it doesn't provide additional syntax or format details beyond the schema. Baseline 3 is appropriate when the schema carries the parameter documentation.
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 ('Generate') and resource ('single barcode as PNG image'), lists supported symbologies, and distinguishes itself from zpl_preview by naming the alternative. An agent can immediately tell what it does and what it does not do.
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?
Explicitly states when NOT to use this tool ('For a full label with text and layout, write ZPL and use zpl_preview instead') and names the alternative. This is clear routing guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode barcodes from a photo or scan of a PRINTED label (PNG, JPEG, BMP or GIF) and report what a software decoder reads back. Honest by design: 'read' does not guarantee every handheld scanner will read it, and 'not read' does not condemn the label (photo angle/focus matter) — the response says so.
| Name | Required | Description | Default |
|---|---|---|---|
| image_base64 | Yes | Base64-encoded image bytes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond this: it explicitly warns that 'read' doesn't guarantee external scanner compatibility and 'not read' doesn't condemn the label due to photo issues. This honest disclaimer goes beyond the annotations and is the kind of context that helps agents manage expectations.
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 and well-structured. It front-loads the core purpose, specifies formats, and then adds the behavioral disclaimer in a compact, context-rich clause. Every sentence earns its place, and there's 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 tool with one parameter, full schema coverage, and a clear output (readback results), the description covers the essential context. It explains the input type, the purpose, and provides behavioral caveats. It doesn't detail the response structure, but since there's no output schema, it could benefit from a note on what the response includes (e.g., barcode values), but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the schema already documents what image_base64 is. The description mentions that the image should be of a printed label, which aligns with the parameter, but adds little additional semantic detail beyond emphasizing that it's a photo/scan of a printed label. Given high coverage, 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 clearly identifies the tool's purpose: decoding barcodes from printed label images. It specifies supported image formats and emphasizes the 'read back' aspect, which distinguishes it from other tools in the sibling list (e.g., barcode_png, image_to_zpl). The verb 'decode' and resource 'printed label' are specific and unambiguous.
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 when to use this tool (when you have a printed label image and need to know what a decoder reads), but it doesn't explicitly mention alternatives or when NOT to use it. It could be clearer about when to use barcode_png (which might be for generating barcodes) or image_to_zpl (converting images to ZPL), but the user can infer this from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your recent bulk jobs (id, state, error class, timestamps), newest first. Useful to recover a lost job id; details via bulk_status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max jobs to return (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond annotations—'recent', 'newest first', and the returned fields—which helps the agent understand ordering and scope.
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 deliver the action, scope, returned data, ordering, use case, and a pointer to the related tool—all without filler. 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 read-only list with one fully documented optional parameterholzer, the description explains what is returned, the ordering, and when to use it. The absence of an output schema is acceptable because the listed fields give the agent a clear expectation of the response.
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 only parameter 'limit' is fully documented in the schema as 'Max jobs to return (default 50)'. The description adds no parameter detail, but none is needed given the schema already covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List your recent bulk jobs' with specific fields and ordering ('newest first'), making the operation and scope unmistakable. It also differentiates from siblings by noting 'details via bulk_status', so an agent can distinguish list from status detail lookup.
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 ('recover a lost job id') and names the sibling tool for deeper follow-up ('details via bulk_status'). It does not explicitly state when not to use this tool, but the context is clear enough for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status of one bulk job you own: state, attempt count and — when finished — the summary with produced count and per-row failures (row number + reason; failed rows never block the rest). Finished outputs stay downloadable for 7 days via the REST endpoint the response names.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job id from bulk_submit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnly/unmodified behavior, but the description adds valuable behavioral context: per-row failures do not block other rows, finished outputs remain downloadable for 7 days, and the response names the REST endpoint. These details go beyond what annotations alone convey.
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 front-loads the core purpose and then packs in key details (attempt count, summary, failures, retention) without redundancy. No fluff or repetition of the title.
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 and lack of an output schema, the description fully covers what the response contains, how failures are handled, and the retention rule. An agent has everything needed to invoke and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter job_id already has a clear description ('Job id from bulk_submit'). The tool description does not add further parameter-specific semantics, so the baseline score 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 states the exact resource ('one bulk job you own') and the specific information returned: state, attempt count, summary, produced count, and per-row failures. It directly distinguishes from sibling tools like bulk_list (multiple jobs) and bulk_submit (creating jobs) by using 'one' and 'you own'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this for a single job you've submitted (job_id comes from bulk_submit) after it runs. It implicitly contrasts with bulk_list for listing all jobs. However, it does not explicitly name alternative tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a bulk label production job: one ZPL template with {{variable}} placeholders plus data rows (one object per label). Requires an API key whose plan includes bulk jobs. Quota is charged UPFRONT, one operation per row, and failed rows are not refunded; rows per job are capped by plan. Returns the job id — check bulk_status (small jobs usually finish within seconds).
| Name | Required | Description | Default |
|---|---|---|---|
| zpl | Yes | ZPL template with {{name}} placeholders | |
| dpmm | No | Print density (default 8) | |
| rows | Yes | One object per label: placeholder name -> value | |
| output | No | Output format (default zpl) | |
| width_in | No | Label width, inches | |
| height_in | No | Label height, inches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation, and the description adds valuable specifics: upfront quota charge, no refunds for failed rows, and plan caps. This goes beyond the generic annotation flags and informs cost-sensitive decisions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with high information density. Front-loads the core action, then requirements, then consequences, then next step. No redundant phrasing.
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?
Covers the essential workflow: submit, get job id, check bulk_status. Warns about costs and caps. Since output schema is absent, the description compensates by stating the return value. Sufficient for an agent to call 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 covers all parameters with descriptions, so baseline is 3. Description adds meaning by explaining the template placeholder pattern and the one-object-per-label data structure, which clarifies the relationship between zpl and rows. Also notes the per-row quota impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: submitting a bulk label production job with a ZPL template and data rows. Clearly distinguishes from siblings like zpl_preview by describing the batch nature and the one-object-per-label structure.
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 context for when to use: requires an API key with bulk jobs plan and points to bulk_status for follow-up. It doesn't explicitly name alternatives, but the bulk-specific semantics make the use case clear. Could be improved by stating not to use for single-label jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rescale ZPL between printer resolutions (203/300/600 DPI): coordinates, fonts, barcode module width and label size are scaled. Embedded ^GF/~DG image data is NOT scaled; the response says so instead of silently passing it through.
| Name | Required | Description | Default |
|---|---|---|---|
| zpl | Yes | Raw ZPL code | |
| source_dpi | Yes | Resolution the ZPL was written for, in DPI (not dpmm: 203 DPI = 8 dpmm). | |
| target_dpi | Yes | Resolution to rescale to, in DPI. Equal to source_dpi means no scaling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description adds a valuable non-obvious caveat: embedded ^GF/~DG image data is NOT scaled, and the response says so instead of silently passing it through. This is exactly the behavioral context an agent needs beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the action and immediately highlight the most important exception. There is no filler or repetition, and the image-data caveat earns its place by preventing a silent data-loss misunderstanding.
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 adequately covers what is scaled and what is not, but with no output schema it never explicitly states the return format beyond 'the response says so'. The '(203/300/600 DPI)' list also omits 152 even though the schema accepts it, leaving minor ambiguity about supported conversions.
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 input schema already documents 'zpl', 'source_dpi', and 'target_dpi' with enums and meanings. The description adds general behavior but little parameter-specific meaning, so the schema carries the semantic weight and 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 opens with a specific verb and resource: 'Rescale ZPL between printer resolutions', and further lists what gets scaled (coordinates, fonts, barcode module width, label size). This clearly distinguishes the tool from preview/validate/explain siblings, even though the parenthetical DPI list omits 152, which the schema allows.
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 use case is clearly implied: use this tool when ZPL must be rescaled between DPI values. However, there is no explicit guidance about when to prefer this over related ZPL tools, nor any stated exclusions or alternatives, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render CPCL label code and return a PNG preview. The preview assumes 203 dpi and is an interpretation of the CPCL manual covering a core command subset — no physical printer validation. labels in the response is the TOTAL number of labels the stream prints (a stream may contain several, each ended by PRINT); pass index to render a different one.
| Name | Required | Description | Default |
|---|---|---|---|
| cpcl | Yes | Raw CPCL code | |
| index | No | Label index in the stream |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral details: the rendering is an interpretation at 203 dpi, not printer-verified, and it explains how to navigate multi-label streams through the `labels` field and `index` parameter. Nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the primary purpose first, followed by key assumptions and finally the response semantics. Every sentence carries distinct, necessary information—no fluff 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 preview tool without an output schema, the description covers the essential operational aspects: what the tool does, its rendering assumptions, and how to handle multiple labels. It does not discuss error behavior for invalid CPCL, but that might be reasonably delegated to the separate validation tool. Overall, it provides enough for an agent 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?
The schema covers both parameters fully with clear descriptions (100% coverage). The description enhances the `index` parameter by explaining that the response's `labels` field counts total labels and that `index` selects a specific one. This goes beyond the schema, which only says 'Label index in the stream.' The `cpcl` parameter gains no additional meaning, but the overall added value justifies a score above baseline.
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 clear action: 'Render CPCL label code and return a PNG preview.' This specifies the verb, resource, and output format, and it naturally differentiates from validation or other language preview descriptors. The additional DPI and interpretation notes further clarify the scope.
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 provides clear context on how to use the tool: the `index` parameter selects among multiple labels, and the response's `labels` field indicates the total. It notes that there is 'no physical printer validation,' which implicitly separates this from a validation tool, but it does not explicitly name alternatives like `cpcl_validate` or state conditions for choosing one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint CPCL label code and return positioned findings with severity as JSON. Checks the command set Labelixa implements from the CPCL manual — a clean result is not a guarantee that a specific printer accepts the job. Run this before cpcl_preview; if you are not sure which language the code is, call language_detect first.
| Name | Required | Description | Default |
|---|---|---|---|
| cpcl | Yes | Raw CPCL code |
| Name | Required | Description |
|---|---|---|
| ozet | Yes | |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond those annotations: it clarifies the validation is limited to Labelixa's implemented command set and warns that 'a clean result is not a guarantee that a specific printer accepts the job'. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at three sentences with no filler. It front-loads the purpose, then adds a crucial caveat, then gives usage ordering. Every sentence earns its place, and the most important selection information is near the beginning.
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 lint tool, the description covers the purpose, scope, a critical limitation, and when to use it. An output schema exists for the returned JSON, eliminating the need to describe return structure, and the annotations already carry the safety profile. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single `cpcl` parameter as 'Raw CPCL code'. The description's phrase 'CPCL label code' adds no new meaning, and no format, length, or encoding constraints are mentioned. Baseline 3 is appropriate when the schema carries the parameter documentation burden.
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 ('Lint'), resource ('CPCL label code'), and output ('positioned findings with severity as JSON'). It further distinguishes itself from siblings by scoping to 'the command set Labelixa implements from the CPCL manual', making it clearly separate from cpcl_preview and validators for other languages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Run this before cpcl_preview' establishes ordering, and 'if you are not sure which language the code is, call language_detect first' names the alternative and the condition that selects it. This leaves no ambiguity about when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render EPL/EPL2 label code and return a PNG preview. The preview assumes 203 dpi and is an interpretation of the EPL2 manual covering a core command subset — no physical printer validation. labels in the response is the TOTAL number of labels the stream prints (a stream may contain several, each ended by P); pass index to render a different one.
| Name | Required | Description | Default |
|---|---|---|---|
| epl | Yes | Raw EPL/EPL2 code | |
| index | No | Label index in the stream |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations, disclosing the 203 dpi assumption, the core command subset limitation, the lack of physical printer validation, and the meaning of `labels` and `index` in a multi-label stream. This gives the agent important behavioral context that readOnlyHint and idempotentHint do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It opens with the action and output, then packs important assumptions and response semantics into the remaining sentences. Every sentence earns its place and the most decision-relevant details are 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 covers the key return semantics (`PNG preview` and `labels`), the rendering limitations, and the index behavior. For an agent deciding whether and how to invoke this tool, the essential context is present, especially when combined with the parameter descriptions in the schema.
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 both parameters at 100% coverage. The description adds useful semantics for `index` by explaining that streams may contain multiple labels ending in `P`, that `labels` is the total count, and that `index` selects which label to render. This enriches the schema's minimal 'Label index in the stream' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Render') and resource ('EPL/EPL2 label code') and states the exact output ('PNG preview'). It also differentiates itself from validation tools by noting it is an interpretation with no physical printer validation, making its scope clear alongside siblings like epl_validate 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 implies when to use it: when you need a PNG preview of EPL code. It also states what it is not for ('no physical printer validation'), which is an implicit exclusion, but it never explicitly names an alternative tool such as epl_validate or explains when to choose it over other preview tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint EPL/EPL2 label code and return positioned findings with severity as JSON. Checks the command set Labelixa implements from the EPL2 manual — a clean result is not a guarantee that a specific printer accepts the job. Run this before epl_preview; if you are not sure which language the code is, call language_detect first.
| Name | Required | Description | Default |
|---|---|---|---|
| epl | Yes | Raw EPL/EPL2 code |
| Name | Required | Description |
|---|---|---|
| ozet | Yes | |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds a valuable limitation: validation is scoped to Labelixa's EPL2 command set and a clean result is not a guarantee of printer acceptance. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: purpose, limitation, and usage order are each stated once and front-loaded. The most actionable guidance appears before the caveat and disambiguation.
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 an output schema and strong annotations, the description covers purpose, output shape, limitations, and relationship to epl_preview and language_detect. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single `epl` parameter, so the schema already explains the input. The description references EPL/EPL2 code but adds no new detail about format, size limits, or edge cases, which is acceptable for a single fully-documented 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 names a specific verb ('Lint'), a resource ('EPL/EPL2 label code'), and the concrete output ('positioned findings with severity as JSON'). This clearly distinguishes the tool from sibling validators/previewers for other languages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit sequencing guidance: run before epl_preview, and call language_detect first if the language is uncertain. This tells an agent when to use this tool versus closely related siblings without needing further inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full health report for a ZPL label: sectioned findings (syntax, size/DPI, orientation, barcodes, fonts, graphics memory, job behaviour) with an honest score — sections that cannot be assessed say so and are excluded from the score.
| Name | Required | Description | Default |
|---|---|---|---|
| zpl | Yes | Raw ZPL code | |
| dpmm | No | Printer density (8 = 203 dpi). The size/DPI section is scored against it — pass the real value. | |
| width_in | No | Label width in inches; fields outside it are reported. | |
| height_in | No | Label height in inches; same role as width_in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral insight beyond annotations: it explicitly states that sections that cannot be assessed are reported as such and excluded from the score, which is a transparency guarantee about the tool's honesty. This goes beyond mere read-only status and adds value.
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 communicates the core purpose and scope efficiently. It lists the sections but avoids excessive detail. While it is somewhat dense, it is not verbose and contains no filler. It earns a 4 for being concise and well-structured, though a slight break-down could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description does a good job of explaining what the agent will receive: a health report with sectioned findings and a score, including the caveat about unassessed sections. It does not detail the exact score scale or output format, but the description covers the essential information needed to invoke the tool and interpret its result. Given the complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the input schema (coverage 100%), so the schema documents them fully. The description mentions 'size/DPI' which maps to dpmm, width_in, and height_in, but does not elaborate on parameter usage beyond what the schema provides. Thus, it meets the baseline for high schema coverage without adding significant extra semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it produces a full health report for a ZPL label, listing specific sections (syntax, size/DPI, orientation, barcodes, fonts, graphics memory, job behaviour) and an honest score. This distinguishes it from sibling tools like zpl_validate (validation) and zpl_preview (rendering), as it focuses on comprehensive analysis.
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 context for when to use this tool (to get a health report for ZPL code) but does not explicitly mention when not to use it or name alternative tools. Since the purpose is unambiguous and distinct among siblings, it earns a 4 for clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an image (PNG, JPEG, BMP or GIF, max 200 KB) to a ZPL ^GF graphic command. Returns the ZPL plus measured dimensions and the physical print size at the chosen density. PDF input is REST-only (/v1/graphics).
| Name | Required | Description | Default |
|---|---|---|---|
| dpmm | No | Target printer density | |
| wrap | No | Wrap the ^GF in a printable ^XA...^XZ label with ^PW/^LL | |
| dither | No | Dither instead of hard threshold (photos) | |
| image_base64 | Yes | Base64-encoded image bytes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: the 200 KB size limit, the return of measured dimensions and physical print size, and the special PDF handling. These details help the agent anticipate constraints and output format, complementing the annotations without contradiction.
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 with no wasted words. The main action and constraints are front-loaded, and the PDF exception is stated succinctly. The structure is efficient and easy to scan.
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 the description correctly explains the return value (ZPL, dimensions, print size). It also covers input formats, size limit, and the special PDF case. For a conversion tool with this complexity, the description provides all necessary context 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 description coverage is 100%, so all four parameters are already described in the schema. The description adds minimal new parameter-specific detail, though it links 'chosen density' to the dpmm parameter via the output description. Since the schema carries the burden, a 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 clearly states the action (Convert), the input (an image), the output (a ZPL ^GF graphic command), and specific constraints (formats PNG/JPEG/BMP/GIF, max 200 KB). It is unambiguous and distinct from siblings like barcode_png or convert_zpl_dpi, which serve different purposes.
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 excludes PDF input, directing agents to a REST-only endpoint (/v1/graphics) for PDFs. This is a clear 'when-not' condition. For image inputs, no alternative is mentioned, but that is appropriate given no direct sibling exists for this function. The guidance is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect which printer language raw label code is written in (ZPL, EPL, TSPL or CPCL). Heuristic: returns the language plus a confidence TIER (high/medium/low) and signal codes — not a probability.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Raw label code to classify |
| Name | Required | Description |
|---|---|---|
| dil | Yes | Detected printer language |
| guven | Yes | Confidence level |
| karma | No | True when the input mixes languages |
| puanlar | Yes | Per-language score |
| kanitlar | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety traits (readOnly, idempotent, non-destructive), and the description adds meaningful behavioral context: the detection is heuristic, returns a confidence TIER plus signal codes, and explicitly is not a probability. This manages expectations about output semantics beyond structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core action, enumerates target languages, and frames the output model clearly. The heuristic caveat is front-loaded and every sentence earns its place without wasted phrasing.
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, non-destructive tool with an output schema, the description is nearly complete: it names inputs, outputs, and expected uncertainty behavior. The only slight gap is that 'signal codes' are mentioned without explanation, but the output schema is expected to carry that detail.
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 single 'code' parameter as 'Raw label code to classify.' The description reinforces that the code is raw label text and links it to language detection, but it does not add new syntax or formatting 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?
States a specific verb and resource: it detects the printer language of raw label code, enumerating the possible outputs (ZPL, EPL, TSPL, CPCL). This clearly differentiates it from sibling validators and previewers, which assume a language rather than detect 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 description implies the use case—classify an unknown raw label language—but never explicitly says when to use this tool versus alternatives like zpl_validate, tspl_preview, or explain_zpl. There are no when-not or alternative conditions, so usage guidance is only inferred from the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one catalog template: metadata, preview image URL and — for non-premium templates — the ZPL source, ready for zpl_preview. Premium templates return metadata for everyone; their ZPL source requires an API key whose plan includes the premium-template feature (same rule as the website).
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | Template id from template_list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses a key behavioral trait: content is conditional on premium statuscars. It specifies that metadata returns for everyone but ZPL source requires a plan with premium-template feature. This affects whether the agent can actually obtain the ZPL source, adding significant value over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry all necessary information: the first front-loads the core purpose and return contents, the second handles the premium exception. No redundant phrasing or 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?
For a single-parameter, read-only, idempotent fetch with full schema coverage, the description is sufficient. It states what is returned, when ZPL source is unavailable, and the prerequisite for premium access. The absence of an output schema is mitigated by the explicit list of return components.
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 provides 100% coverage for template_id, including the helpful note that it comes from template_list. The description adds no additional parameter-level detail, so the baseline 3 applies because the schema already documents the single 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 uses a specific verb ('Fetch'), a specific resource ('one catalog template'), and enumerates the returned components (metadata, preview image URL, ZPL source). It also distinguishes this tool from zpl_preview by noting the output is 'ready for' that tool, clarifying it fetches rather than renders.
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 situates the tool in a workflow, implying it is used before zpl_preview by producing the ZPL source. It also explains the premium-template access rule. However, it does not explicitly name alternatives or state when not to use this tool, such as pointing to template_list for enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Labelixa's first-party label template catalog: id, English name, category, size/density and tags. Read-only product content (no tenant data). Fetch one with template_get; render its ZPL with zpl_preview.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Substring match on id/tags | |
| category | No | Filter by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond those annotations by clarifying the data is first-party product content with no tenant data, which helps an agent understand access implications without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The main action and scope come first, followed by a read-only clarification and sibling routing, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema, the description lists the returned fields, notes the lack of tenant data, and names the follow-up actions with template_get and zpl_preview. Combined with annotations and full schema coverage, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (substring match on id/tags; category filter with enum). The description does not add significant parameter-level detail beyond this, 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 names a specific verb ('List'), a resource ('first-party label template catalog'), and the key fields returned (id, name, category, size/density, tags). It also differentiates this listing tool from template_get and zpl_preview, so an agent can distinguish it from its siblings.
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 signals this is the tool for browsing the catalog and product content, not tenant data. It explicitly points to template_get for fetching a single template and zpl_preview for rendering, which gives an agent a clear routing cue, though it does not enumerate exhaustive when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render TSPL/TSPL2 label code and return a PNG preview. The preview assumes 203 dpi and is an interpretation of the TSPL manual covering a core command subset — no physical printer validation. labels in the response is the TOTAL number of labels the stream prints (a stream may contain several, each ended by PRINT); pass index to render a different one.
| Name | Required | Description | Default |
|---|---|---|---|
| tspl | Yes | Raw TSPL/TSPL2 code | |
| index | No | Label index in the stream |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds substantial behavioral detail: it assumes 203 dpi, is an interpretation rather than actual printer validation, and explains the semantics of the response field `labels` and the `index` parameter. This gives the agent a clear model of what the tool does and its 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?
Three sentences, each earning its place: the first states the core action and output, the second adds crucial limitations (dpi, interpretation, no physical validation), and the third clarifies the response field and parameter usage. 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?
Given there is no output schema, the description still conveys the return type (PNG preview) and the non-obvious `labels`/`index` semantics. Combined with annotations covering read-only and idempotent behavior, the agent has enough to invoke the tool correctly. The tool is simple enough that error handling details are not required.
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% for the two parameters, giving a baseline of 3. The description adds meaningful extra semantics: it explains that a stream can contain multiple labels ended by `PRINT`, that `labels` reports the total count, and that `index` selects which label to render. This goes beyond the terse schema descriptions.
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-resource pair: 'Render TSPL/TSPL2 label code and return a PNG preview.' It clearly distinguishes from sibling tools by specifying the language (TSPL/TSPL2) and the preview/interpretive nature ('no physical printer validation'), which separates it from tspl_validate and other preview tools like zpl_preview or 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 provides clear context for when to use the tool: to get a visual PNG preview of TSPL code. It also signals exclusions by noting 'no physical printer validation' and 'core command subset', which alerts users against relying on it for validation or full printer behavior. However, it does not explicitly name alternative tools (e.g., tspl_validate) or state 'use this instead of X,' so it stops short of the highest level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint TSPL/TSPL2 label code and return positioned findings with severity as JSON. Checks the command set Labelixa implements from the TSPL2 manual — a clean result is not a guarantee that a specific printer accepts the job. Run this before tspl_preview; if you are not sure which language the code is, call language_detect first.
| Name | Required | Description | Default |
|---|---|---|---|
| tspl | Yes | Raw TSPL/TSPL2 code |
| Name | Required | Description |
|---|---|---|
| ozet | Yes | |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds substantial behavioral context beyond that: the validation only covers Labelixa's implemented command set, and a clean result does not guarantee printer acceptance. It also discloses the return shape ('positioned findings with severity as JSON'), which is not in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the core action, the second adds an important scope caveat, and the third gives sequencing guidance. The primary verb and resource appear immediately, with no filler.
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 lint tool, the description is fully sufficient: it explains what is validated, the limitations of the check, the output nature, and how to order it with related tools. An output schema exists to cover detailed return values, and annotations cover the safety profile, so nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a clear description ('Raw TSPL/TSPL2 code'), so the baseline is 3. The description reiterates that the input is label code and implies language ambiguity, but it does not add details like encoding, size limits, or required formatting that would elevate the 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?
The description starts with a specific verb 'Lint' and a precise resource 'TSPL/TSPL2 label code', and states the output format ('positioned findings with severity as JSON'). It clearly distinguishes this from sibling validators by naming the language family and by framing the command set scope ('what Labelixa implements from the TSPL2 manual').
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?
Explicit workflow guidance is provided: 'Run this before tspl_preview' gives an ordering rule, and 'if you are not sure which language the code is, call language_detect first' routes the agent to the correct alternative. This is direct, actionable usage context beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a single ZPL command: syntax, parameters with types/ranges/options, a fragment example and whether the Labelixa renderer draws it. Data comes from the same catalog that powers the public command reference pages.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for the human-readable fields (name and descriptions). Command codes, syntax strings, examples and parameter names never change. | en |
| command | Yes | ZPL command code, e.g. FO, ^BC, ~DG |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying what the response will contain and by noting the data source for the command reference, going beyond the structured fields.
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 tool's core behavior and output contents, and the second adds provenance concisely. 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 simple read-only lookup tool, the description enumerates all meaningful output categories and the schema fully documents both parameters. No output schema exists, but the description compensates by stating what the agent will receive.
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 both 'command' and 'locale' are already documented with examples and enum values. The description's mention of 'parameters with types/ranges/options' describes the tool's output rather than adding per-parameter meaning, 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 uses a specific verb ('Explain') and object ('a single ZPL command') and enumerates the concrete output: syntax, parameter types/ranges/options, a fragment example, and renderer support. This makes the tool's scope clear and distinguishes it from preview, validation, and broader explanation siblings.
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 single-command scoping implies when the tool should be used, but the description does not explicitly mention alternatives or state when not to use it. Given the existence of 'explain_zpl' among siblings, an explicit routing cue would have strengthened the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compatibility RISK analysis of ZPL code against a specific printer model, given as manufacturer/model (e.g. 'zebra/zd421'). NOT an emulator and never says 'it works': reports the model's language posture with evidence level and size-rule findings.
| Name | Required | Description | Default |
|---|---|---|---|
| zpl | Yes | Raw ZPL code | |
| model | Yes | Printer model slug, manufacturer/model, e.g. zebra/zd421 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds behavioral details beyond that: it never claims 'it works', and it reports 'evidence level and size-rule findings', which clarifies the output nature. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and disclaimers. Every clause adds information without redundancy. Highly efficient and well-structured.
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 two-parameter tool with no output schema, the description adequately covers what the tool does, its constraints, and output highlights. It could elaborate on what 'evidence level' and 'size-rule findings' mean, but given the schema covers inputs, this is sufficient 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%, with descriptions for both parameters. The description adds a concrete example for the 'model' parameter format (manufacturer/model) and clarifies 'zpl' is raw code, but these are marginal additions over the schema. 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 ('Compatibility RISK analysis'), the resource ('ZPL code against a specific printer model'), and provides a concrete example ('zebra/zd421'). It clearly differentiates from sibling tools like zpl_validate and zpl_preview by explicitly disclaiming emulation and 'it works' assertions.
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 when to use it (for compatibility risk assessment) and explicitly says what it is NOT (an emulator). It does not name specific alternative tools, but the 'NOT an emulator' clause guides the agent away from preview/validation use cases, which is a clear usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render ZPL label code and return the label as a PNG image. Use this to SEE what ZPL output looks like — LLMs can write ZPL but cannot otherwise verify the visual result. One call renders one label (use index to pick a label from a multi-label stream). The result also carries an 'Open this label in the Labelixa editor' link the user can click to edit, save or share the label.
| Name | Required | Description | Default |
|---|---|---|---|
| zpl | Yes | ZPL source (^XA...^XZ) | |
| dpmm | No | Printer density (8 = 203 dpi) | |
| index | No | Label index in the stream | |
| width_in | No | Label width, inches | |
| height_in | No | Label height, inches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly=true, idempotent=true, destructive=false, and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the return type (PNG), the one-label-per-call constraint, the use of index for multi-label streams, and the presence of an editor link in the result.
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 action and return value are front-loaded in the first sentence, followed by the motivating use case, the per-call constraint, and the output link. Three tight sentences with no filler; every sentence carries distinct 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?
With no output schema, the description usefully describes the return (a PNG image plus an editor link). For a read-only render tool with full schema coverage and clear annotations, this is near-complete; only minor output details (e.g., error behavior on invalid ZPL) are left implicit.
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 five parameters including the index and dpmm semantics. The description's mention of index for multi-label streams largely restates the schema's 'Label index in the stream', adding minimal new meaning. 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?
States a specific verb (render) and resource (ZPL label code), plus the output form (PNG image). This clearly differentiates it from siblings like zpl_validate or explain_zpl, which inspect rather than render. An agent can tell what it produces without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it: to SEE what ZPL output looks like, since LLMs cannot otherwise verify the visual result. It stops short of naming the alternative tools (e.g., zpl_validate) or stating when NOT to use it, so it's clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint ZPL code and return structured diagnostics: unknown commands, missing ^FS, out-of-range parameters, fields outside the label boundary. Run this before zpl_preview when generating ZPL.
| Name | Required | Description | Default |
|---|---|---|---|
| zpl | Yes | ZPL source | |
| dpmm | No | Printer density (8 = 203 dpi). The boundary check measures against it — pass the real value. | |
| width_in | No | Label width in inches. Fields outside it are reported, so a wrong size makes that finding wrong. | |
| height_in | No | Label height in inches. Same as width_in: the boundary check depends on it. |
| Name | Required | Description |
|---|---|---|
| ozet | Yes | |
| rfid | No | |
| alanlar | No | |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate read-only, idempotent, and non-destructive behaviorikuha. The description adds useful behavioral context by stating that the tool returns 'structured diagnostics' and listing what it validates, including boundary-sensitive checks, which helps set expectations beyond the title.
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. It front-loads the core action and diagnostic types, then adds a single actionable usage instruction.
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 annotations, complete input schema, and presence of an output schema, the description covers the necessary workflow context and expected behavior. Nothing critical is missing for an agent to select and 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?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description does not add parameter-specific meaning beyond what the schema already provides, which matches the baseline score of 3.
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') and resource ('ZPL code'), and enumerates concrete diagnostic categories such as unknown commands, missing ^FS, and boundary checks. It is clearly distinguishable from sibling validators like cpcl_validate 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 description gives explicit workflow guidance: 'Run this before zpl_preview when generating ZPL.' This tells an agent when in the generation pipeline to invoke the tool, though it does not discuss when to choose a non-ZPL validator or other diagnostic tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cpcl_validate1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "diagnostics": {
+ "items": {
+ "properties": {
+ "code": {
+ "description": "Stable diagnostic code, e.g. ZPL0002",
+ "type": "string"
+ },
+ "col": {
+ "type": "integer"
+ },
+ "end_col": {
+ "type": "integer"
+ },
+ "end_line": {
+ "type": "integer"
+ },
+ "line": {
+ "type": "integer"
+ },
+ "mesaj": {
+ "description": "Human-readable message in the requested language",
+ "type": "string"
+ },
+ "message_key": {
+ "description": "i18n key for the message",
+ "type": "string"
+ },
+ "severity": {
+ "enum": [
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "severity",
+ "line",
+ "col"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ozet": {
+ "properties": {
+ "error": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "toplam": {
+ "type": "integer"
+ },
+ "warning": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "toplam",
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "diagnostics",
+ "ozet"
+ ],
+ "type": "object"
+}epl_validate1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "diagnostics": {
+ "items": {
+ "properties": {
+ "code": {
+ "description": "Stable diagnostic code, e.g. ZPL0002",
+ "type": "string"
+ },
+ "col": {
+ "type": "integer"
+ },
+ "end_col": {
+ "type": "integer"
+ },
+ "end_line": {
+ "type": "integer"
+ },
+ "line": {
+ "type": "integer"
+ },
+ "mesaj": {
+ "description": "Human-readable message in the requested language",
+ "type": "string"
+ },
+ "message_key": {
+ "description": "i18n key for the message",
+ "type": "string"
+ },
+ "severity": {
+ "enum": [
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "severity",
+ "line",
+ "col"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ozet": {
+ "properties": {
+ "error": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "toplam": {
+ "type": "integer"
+ },
+ "warning": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "toplam",
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "diagnostics",
+ "ozet"
+ ],
+ "type": "object"
+}language_detect1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "dil": {
+ "description": "Detected printer language",
+ "type": "string"
+ },
+ "guven": {
+ "description": "Confidence level",
+ "type": "string"
+ },
+ "kanitlar": {
+ "items": {
+ "properties": {
+ "kod": {
+ "type": "string"
+ },
+ "satir": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "karma": {
+ "description": "True when the input mixes languages",
+ "type": "boolean"
+ },
+ "puanlar": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "description": "Per-language score",
+ "type": "object"
+ }
+ },
+ "required": [
+ "dil",
+ "guven",
+ "puanlar"
+ ],
+ "type": "object"
+}tspl_validate1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "diagnostics": {
+ "items": {
+ "properties": {
+ "code": {
+ "description": "Stable diagnostic code, e.g. ZPL0002",
+ "type": "string"
+ },
+ "col": {
+ "type": "integer"
+ },
+ "end_col": {
+ "type": "integer"
+ },
+ "end_line": {
+ "type": "integer"
+ },
+ "line": {
+ "type": "integer"
+ },
+ "mesaj": {
+ "description": "Human-readable message in the requested language",
+ "type": "string"
+ },
+ "message_key": {
+ "description": "i18n key for the message",
+ "type": "string"
+ },
+ "severity": {
+ "enum": [
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "severity",
+ "line",
+ "col"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ozet": {
+ "properties": {
+ "error": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "toplam": {
+ "type": "integer"
+ },
+ "warning": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "toplam",
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "diagnostics",
+ "ozet"
+ ],
+ "type": "object"
+}zpl_validate1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "alanlar": {
+ "items": {
+ "properties": {
+ "line": {
+ "type": "integer"
+ },
+ "x": {
+ "type": "integer"
+ },
+ "y": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "diagnostics": {
+ "items": {
+ "properties": {
+ "code": {
+ "description": "Stable diagnostic code, e.g. ZPL0002",
+ "type": "string"
+ },
+ "col": {
+ "type": "integer"
+ },
+ "end_col": {
+ "type": "integer"
+ },
+ "end_line": {
+ "type": "integer"
+ },
+ "line": {
+ "type": "integer"
+ },
+ "mesaj": {
+ "description": "Human-readable message in the requested language",
+ "type": "string"
+ },
+ "message_key": {
+ "description": "i18n key for the message",
+ "type": "string"
+ },
+ "severity": {
+ "enum": [
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "severity",
+ "line",
+ "col"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ozet": {
+ "properties": {
+ "error": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "toplam": {
+ "type": "integer"
+ },
+ "warning": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "toplam",
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "object"
+ },
+ "rfid": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "diagnostics",
+ "ozet"
+ ],
+ "type": "object"
+}zpl_command_help1 field changedInput schema / properties / localeAdded value: +{
+ "default": "en",
+ "description": "Language for the human-readable fields (name and descriptions). Command codes, syntax strings, examples and parameter names never change.",
+ "enum": [
+ "en",
+ "tr",
+ "de"
+ ],
+ "type": "string"
+}convert_zpl_dpi2 fields changedInput schema / properties / source_dpi / descriptionAdded value: +"Resolution the ZPL was written for, in DPI (not dpmm: 203 DPI = 8 dpmm)."Input schema / properties / target_dpi / descriptionAdded value: +"Resolution to rescale to, in DPI. Equal to source_dpi means no scaling."explain_zpl3 fields changedInput schema / properties / dpmm / descriptionAdded value: +"Printer density (8 = 203 dpi). The size/DPI section is scored against it — pass the real value."Input schema / properties / height_in / descriptionAdded value: +"Label height in inches; same role as width_in."Input schema / properties / width_in / descriptionAdded value: +"Label width in inches; fields outside it are reported."zpl_validate3 fields changedInput schema / properties / dpmm / descriptionAdded value: +"Printer density (8 = 203 dpi). The boundary check measures against it — pass the real value."Input schema / properties / height_in / descriptionAdded value: +"Label height in inches. Same as width_in: the boundary check depends on it."Input schema / properties / width_in / descriptionAdded value: +"Label width in inches. Fields outside it are reported, so a wrong size makes that finding wrong."cpcl_preview1 field changedInput schema / properties / indexAdded value: +{
+ "default": 0,
+ "description": "Label index in the stream",
+ "type": "integer"
+}epl_preview1 field changedInput schema / properties / indexAdded value: +{
+ "default": 0,
+ "description": "Label index in the stream",
+ "type": "integer"
+}tspl_preview1 field changedInput schema / properties / indexAdded value: +{
+ "default": 0,
+ "description": "Label index in the stream",
+ "type": "integer"
+}zpl_compatibility1 field changedInput schema / properties / model / descriptionPrevious value: -"Printer model slug, e.g. zebra-zd421"New value: +"Printer model slug, manufacturer/model, e.g. zebra/zd421"barcode_verifybulk_listbulk_statusbulk_submitcpcl_previewepl_previewimage_to_zpltemplate_gettemplate_listtspl_previewbarcode_pngconvert_zpl_dpicpcl_validateepl_validateexplain_zpllanguage_detecttspl_validatezpl_command_helpzpl_compatibilityzpl_previewzpl_validateMCP server for Api2Pdf — generate PDFs & images from HTML, URLs or office files; merge, barcodes.
HTML and CSS to PDF MCP server with page headers, footers and page numbers. No headless browser.
Document conversion MCP server: PDF to Markdown, image OCR, spreadsheet parsing.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Add one secure layer between your agents and this server.
