Thermal label MCP server: render, validate, debug and convert ZPL, EPL, TSPL and CPCL labels.
Scored across 23 tools
Tools are cleanly partitioned by resource and action: per-language preview/validate pairs, conversions, barcode, bulk, and templates are each clearly distinct, and descriptions actively cross-reference each other (e.g. zpl_validate vs explain_zpl vs zpl_compatibility). The only soft spot is three ZPL quality/assessment tools plus eight near-identical per-language preview/validate entries, which an agent must disambiguate mainly by language prefix rather than purpose.
The dominant convention is resource-prefix + action (zpl_preview, zpl_validate, cpcl_preview, bulk_submit, template_list, barcode_png), which is predictable and groups tools by domain. A minority break the pattern with verb-first names (convert_zpl_dpi, explain_zpl, image_to_zpl, language_detect, printer_language_to_zpl, save_label), but all use snake_case and remain immediately readable.
23 tools is on the heavy side of the 16-25 band and a substantial share is structural duplication: four languages × preview + validate accounts for eight near-identical tools that could be a single parameterized call. Each tool is defensible individually, but the surface is broader than the workflow strictly requires.
The core lifecycle — write code, detect language, convert DPI/foreign languages, validate, preview, verify barcodes, then save — is well covered, along with bulk jobs and templates. The notable gap is that save_label implies management of saved labels (list/get/update/print later) yet no tool exposes that side, forcing agents to fall back to the web editor.
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. A data:image/...;base64, prefix and line breaks are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds real behavioral context beyond them: the decode is performed by a software decoder, results are indicative and influenced by photo angle/focus, and the response itself carries that caveat. That is meaningful disclosure about what the output means.
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 compact sentences, front-loaded with the operation and input types, followed by the interpretive caveat. Nothing is redundant, though the caveat sentence is slightly long relative to the operation description.
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 tool this is largely sufficient, but with no output schema the description should hint at the shape of the result (e.g., decoded values plus a status per symbology). The phrase 'the response says so' gestures at this without informing the agent what it will actually 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?
One parameter at 100% schema coverage sets a baseline of 4; the description slightly extends it by enumerating accepted formats (PNG, JPEG, BMP, GIF). No syntax details beyond what the schema already documents.
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?
Specific verb ('Decode barcodes'), specific resource ('a photo or scan of a PRINTED label'), plus supported formats. It does not differentiate from the sibling barcode_png, which reads as a closely related tool, so an agent cannot fully disambiguate from the name alone.
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 frames the use case (verifying printed labels via software decode) and its interpretive limits, but never states explicitly when to pick this over barcode_png or the validate/preview siblings. Usage is implied rather than prescribed.
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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. Beyond that the description adds real behavior: results are newest-first and scoped to 'recent' jobs only, implying the listing is truncated rather than exhaustive. It doesn't spell out how far back 'recent' reaches, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the core action and field set come first, then the recovery use case and the sibling handoff. 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 list tool with rich annotations, a fully documented lone parameter, and a pointer to the detail sibling, the description covers what an agent needs to call it correctly. The only unresolved point is how many/which 'recent' jobs are visible, which is minor.
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?
Only one optional parameter at 100% schema description coverage, so the schema already fully documents 'limit'. The description adds no format, range, or paging guidance beyond the implicit notion of recency, making this the baseline case where the schema does the work.
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 ('List your recent bulk jobs'), names the fields returned (id, state, error class, timestamps) and the sort order, and explicitly distinguishes itself from bulk_status. An agent can choose between the two sibling tools without reading either 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?
Gives a concrete motivating use case ('recover a lost job id') and routes to bulk_status for details, which is a clear use-this-not-that signal. It doesn't state an explicit exclusion case, so it falls short of a 5.
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 (32 hex characters; the dashed UUID form is accepted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: attempt count is exposed, partial-failure semantics are explicit ('failed rows never block the rest'), and the 7-day output retention plus where to download ('the REST endpoint the response names') are disclosed. This is exactly the extra context the safety annotations cannot 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?
A single front-loaded sentence that states the resource first, then the payload, then the failure and retention semantics. Every clause carries distinct information (state, attempts, produced count, per-row failures, 7-day window); nothing is padding.
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 carries the return-shape burden and does so: it names the fields returned, explains partial failures and their non-blocking nature, and covers output retention and retrieval path. Nothing an agent needs in order to interpret the result 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?
With 100% schema description coverage, the schema already documents job_id's format (32 hex, dashed UUID accepted) and its origin in bulk_submit. The description only adds the ownership qualifier ('you own'), which is a marginal semantic addition, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Status of one bulk job you own', immediately scoped to a single job versus the plural sibling bulk_list. It then enumerates exactly what is returned (state, attempt count, summary), so an agent knows precisely what this call yields 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?
'One bulk job you own' implies the single-job case as opposed to bulk_list, and the schema ties job_id back to bulk_submit, so the usage context is inferable. However the description itself never names bulk_list or bulk_submit, nor states when-not to use it (e.g., before submission, or for enumerating jobs).
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, e.g. [{"name": "Ada", "sku": "A-1"}] | |
| output | No | Output format (default zpl) | 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 only declare the safety profile (not read-only, not idempotent, not destructive, closed-world); the description adds the behavior an agent actually needs: quota charged UPFRONT, one operation per row, failed rows are not refunded, and rows per job are capped by plan. This is exactly the non-obvious cost/irreversibility context that annotations cannot 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?
Two dense sentences, front-loaded with the operation and inputs, then the cost/limit caveats, then the return value and next step. Every clause (upfront charge, no refunds, plan cap, status check) carries information an agent would otherwise have to discover.
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 mutating, quota-consuming job submission with no output schema, the description covers prerequisites, billing semantics, failure behavior, size limits, and the return value (job id) plus the follow-up tool. Nothing material 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%, so zpl, rows, dpmm, output, width_in and height_in are all documented in the schema itself; that sets the baseline at 3. The description reinforces the template-to-row placeholder relationship but adds no syntax, defaults, or constraints beyond what the schema already states, and says nothing about dpmm/output/dimensions.
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 ('Submit a bulk label production job') and immediately defines the two core inputs: a ZPL template with {{variable}} placeholders plus one data object per label. The closing pointer to bulk_status distinguishes it cleanly from that sibling and from bulk_list.
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?
Gives the prerequisite (an API key whose plan includes bulk jobs), the cost model, and the follow-up call ('check bulk_status, small jobs usually finish within seconds'). It does not explicitly say when to choose this over looping single-label submissions or point to a non-bulk alternative, so it stops short of full when/when-not guidance.
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 |
|---|---|---|
| summary | Yes | |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description adds genuine behavioral context the annotations lack: it validates only the subset of commands Labelixa implements, and a clean result does not guarantee a specific printer accepts the job. It also notes findings carry position and severity, though the output schema already carries return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, then the limitation, then the workflow ordering. Every sentence earns its place and none repeats structured data.
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 with a full annotations block and an output schema, the description supplies everything else an agent needs: what is checked, the limits of a clean result, and the prerequisite tool. 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?
Only one parameter ('cpcl': 'Raw CPCL code') with 100% schema coverage, so the schema already documents the input fully. The description adds no format, encoding, or size guidance beyond what the schema provides, making a baseline 3 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+resource ('Lint CPCL label code') and immediately scopes it to the command set Labelixa implements. An agent can distinguish it from the sibling epl_validate/tspl_validate/zpl_validate family without opening any 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?
Explicit sequencing advice: 'Run this before cpcl_preview' and 'if you are not sure which language the code is, call language_detect first.' Both the when-to-use and the fallback alternative are named, leaving nothing to inference.
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 |
|---|---|---|
| summary | Yes | |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive). The description adds a genuinely non-obvious scope caveat — validation only covers the command set Labelixa implements from the EPL2 manual, so a clean result does not guarantee printer acceptance. It does not cover error behavior or severity levels in depth, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what the tool does, then the scope limitation, then the workflow guidance. Every sentence earns its place with no restatement of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description still briefly characterizes the output (positioned findings with severity). For a one-parameter read-only linter, everything an agent needs to call it and interpret the result 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?
There is a single parameter with 100% schema description coverage ('Raw EPL/EPL2 code'), so the schema already carries the parameter meaning. The description adds no format, encoding, or size guidance beyond it, which is the expected baseline when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (lint/validate) and resource (EPL/EPL2 label code) and names the output form (positioned findings with severity as JSON). It clearly distinguishes itself from the sibling validators (zpl_validate, cpcl_validate, tspl_validate) by language 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?
Explicit sequencing guidance: 'Run this before epl_preview' and a routing rule 'if you are not sure which language the code is, call language_detect first.' Both the when-to-use and the alternative path are named, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Human-readable health REPORT for a finished ZPL label, with a 0-100 score: sectioned findings (syntax, size/DPI, orientation, barcodes, fonts, graphics memory, job behaviour); sections that cannot be assessed say so and are excluded from the score. Use it to review or explain a label to a person; for a quick pass/fail check while editing, use zpl_validate instead.
| 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add behavior beyond that — and it does, disclosing that unassessable sections self-report and are excluded from the score, which shapes how an agent should interpret the result. It stops short of rate limits or failure modes, so a 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the tool produces and followed by the disambiguation clause. The parenthetical section list is dense but every item informs interpretation of the score.
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 carries the return-value burden and does so: score range, sectioned findings, and the exclusion rule for unassessable sections. An agent knows before calling what it will get back and how to explain it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already explains each parameter including dpmm's scoring role and the width/height reporting role. The description echoes 'size/DPI' and 'orientation' but adds no syntax or format detail beyond the schema, 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?
States a specific verb and resource — a human-readable health report for a ZPL label — plus the concrete output (0-100 score, sectioned findings). It clearly separates itself from the validation siblings by naming zpl_validate as the different tool.
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 when-to-use ('review or explain a label to a person') and when-not ('for a quick pass/fail check while editing, use zpl_validate instead'), naming the alternative tool directly. Nothing is left to inference.
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. A data:image/...;base64, prefix and line breaks are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond them: the 200 KB input cap, that the return includes ZPL plus measured dimensions and physical print size, and the dither-vs-threshold guidance for photos.
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 dense sentences, front-loaded with the core conversion, then constraints, then the return payload and the PDF exclusion. 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?
With no output schema, the description usefully summarizes the return (ZPL, dimensions, physical size at chosen density). It leaves error behavior (e.g., oversize file, unsupported encoding) unstated, a minor gap for an otherwise complete definition.
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 all four parameters including defaults and enum values, so the schema carries the parameter burden. The description only echoes the density-driven print-size output and adds no syntax beyond that, fitting the baseline 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?
States a specific verb and resource ('Convert an image ... to a ZPL ^GF graphic command') and names accepted formats plus a size cap. The final sentence carves out PDF input as REST-only, which separates it from sibling converters like printer_language_to_zpl or barcode_png.
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?
Gives clear context: accepted formats, 200 KB limit, and the exclusion that PDFs must go through the REST endpoint. It does not explicitly say when to prefer this over zpl_preview or convert_zpl_dpi, but the input-type framing makes the intended use clear.
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 |
|---|---|---|
| mixed | No | True when the input mixes languages |
| scores | Yes | Per-language score |
| evidence | No | |
| language | Yes | Detected printer language |
| confidence | Yes | Confidence level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it is a heuristic classifier, it returns a confidence TIER rather than a probability, and it returns signal codes — setting correct expectations about output reliability.
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 compact sentences, front-loaded with the core action, followed by one clarifying sentence about the output shape. No filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-input classifier with an output schema present, everything an agent needs is covered: what it classifies, the possible languages, and the nature of the result (tier + signal codes, not a probability). 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?
There is a single required parameter with 100% schema description coverage ('Raw label code to classify'), so the schema carries the semantics. The description adds nothing specific about the input format or size, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('detect which printer language raw label code is written in') and enumerates the candidate outputs (ZPL, EPL, TSPL, CPCL). This clearly separates it from the language-specific validators/previewers among its siblings, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the classification step to run before choosing a language-specific validate/preview tool, but the description gives no explicit when-to-use or when-not-to-use guidance and names no alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a SATO SBPL, Honeywell (Datamax) DPL or Honeywell (Intermec) IPL label stream to ZPL, so it can be checked with zpl_validate and rendered with zpl_preview. You must name the source language: language_detect does not recognise these three. Real control characters and the manuals' readable notation (, ) are both accepted. Commands outside the supported subset (printer settings, RFID, job management, some 2D symbologies) are skipped with a warning, never silently: non-empty warnings mean the conversion is not 1:1 and one_to_one is false — show the warnings to the user. The output follows each manufacturer's command reference and is not verified on physical printers; check a preview and a test print before production.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Raw SBPL, DPL or IPL label stream | |
| dpmm | No | Target printer density in dots per mm (8 = 203 dpi) | |
| label_length_mm | No | DPL only: label length in mm. DPL measures rows from the bottom edge, ZPL from the top; without it (or <STX>c in the stream) 6 inches is assumed and a warning is added. | |
| source_language | Yes | Language of `code`: sbpl (SATO), dpl (Datamax / Honeywell) or ipl (Intermec / Honeywell) |
| Name | Required | Description |
|---|---|---|
| zpl | Yes | Converted ZPL, one ^XA...^XZ block per label |
| note | No | |
| warnings | Yes | Everything not carried over, with the manual page |
| one_to_one | Yes | True only when warnings is empty |
| source_language | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, idempotent profile, and the description adds substantial non-obvious behavior: unsupported commands (printer settings, RFID, job management, some 2D symbologies) are skipped with warnings rather than silently, non-empty warnings imply one_to_one is false, and the output is not validated against physical printers. This is exactly the caveat context annotations cannot carry.
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?
Front-loads the conversion purpose, then layers constraints, warning semantics, and the production caveat in a logical order. It is on the longer side but nearly every clause carries actionable information; the workflow references and warning-handling rule justify their space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and rich annotations, the description supplies the missing pieces: supported/unsupported command scope, warning semantics, the one_to_one flag, and the recommendation to preview and test print. Nothing an agent needs to invoke or interpret the result is absent.
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 each parameter already documents itself (including the DPL label_length_mm bottom-vs-top edge and the 6-inch fallback). The description only reinforces that source_language is mandatory and that readable notation like <STX>/<ESC> is accepted in `code`, adding marginal value over 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 ('Convert a SATO SBPL, Honeywell DPL or IPL label stream to ZPL') and enumerates exactly which source languages qualify. It also differentiates itself from the sibling language_detect by explaining that detect does not cover these three 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?
Explicitly names the downstream tools (zpl_validate, zpl_preview) and the workflow order, and calls out the sibling alternative (language_detect) with the condition under which it fails. The instruction that the source language must be named is also given as a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a ZPL label to a Labelixa account so it can be edited, versioned and printed later. With an API key the label is saved immediately and the saved label id is returned. Without a key the label is held for 24 hours and a one-time link is returned: the user opens it, signs in (free account is enough) and the label lands in their account. Nothing else is stored for anonymous calls.
| Name | Required | Description | Default |
|---|---|---|---|
| zpl | Yes | Raw ZPL code | |
| dpmm | No | Print density in dots per mm: 6, 8, 12 or 24 (8 = 203 dpi) | |
| name | No | Label name (default: 'Label from assistant') | |
| width_in | No | Label width in inches | |
| height_in | No | Label height in inches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: the API-key path returns a saved label id immediately, while the anonymous path returns a one-time link and stores nothing else. This tells the agent what happens on success and what data retention applies per auth mode, which annotations alone 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?
Three tight sentences, with the core purpose front-loaded before the authenticated and anonymous behavior. Every sentence adds distinct information; no repetition or 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 mutation tool with no output schema, the description covers the essential missing pieces: what is returned in each auth mode, that anonymous submissions expire, and that nothing else is stored. Combined with complete schema coverage and annotations, an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters including defaults and constraints. The description adds no parameter-specific meaning beyond what the schema provides, 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?
States a specific verb and resource ('Save a ZPL label') and the exact target ('a Labelixa account'), with a clear downstream purpose ('edited, versioned and printed later'). The persistence action is distinct from all sibling preview/validate/convert tools.
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 distinguishes two calling paths: authenticated saves happen immediately, while anonymous saves are held for 24 hours behind a one-time sign-in link. It does not name sibling alternatives or say when not to use the tool, but the conditional guidance for the two modes is clear.
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 (the id, not the display name) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe-read profile; the description goes further by disclosing the authorization model — premium templates return metadata to everyone, but ZPL requires an API key whose plan includes the premium-template feature. That conditional-content behavior is exactly what an agent needs and is not derivable from 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 sentences, front-loaded with the verb and resource, with the premium caveat following. The nested em-dash parentheticals make it denser than necessary, but no sentence is 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?
There is no output schema, so the description carries the return-value burden and does so at the level of the three payload pieces. The internal structure of 'metadata' is left unspecified, a minor gap for a read-only single-record fetch.
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 single parameter is already documented as 'Template id from template_list (the id, not the display name)'. The description adds no additional semantics about the id, 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?
States a specific verb ('Fetch') and a scoped resource ('one catalog template') and enumerates what comes back: metadata, preview image URL, and conditionally the ZPL source. The premium/non-premium split further narrows what a given call actually returns, so an agent knows exactly what it is asking for.
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?
Implies downstream use ('ready for zpl_preview') and states the access precondition for premium templates. It does not explicitly say when to use this instead of template_list, but that routing is covered by the schema note pointing at template_list as the id source.
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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new context beyond them: the catalog is first-party product content and contains no tenant data, which tells an agent why the scope is limited and what it can never return.
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 compact clauses in two sentences: what it lists, its data scope, and where to go next. The core purpose is front-loaded and no sentence is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by enumerating the fields returned. Combined with annotations covering the safety profile and full schema coverage of the two filters, an agent has everything needed to call this 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%, with 'search' documented as a substring match on id/tags and 'category' carrying a five-value enum, so the schema does the heavy lifting. The description's 'size/density and tags' refers to output fields, not the search/category parameters, adding essentially nothing to parameter understanding beyond the 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?
States a specific verb and resource ('List ... label template catalog') and enumerates the returned fields (id, English name, category, size/density, tags). It explicitly distinguishes itself from template_get, the sibling that retrieves a single template.
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?
Gives explicit routing to alternatives: 'Fetch one with template_get; render its ZPL with zpl_preview,' establishing the list-then-fetch-then-render workflow. It stops short of stating when this tool should not be used (e.g., for tenant/custom templates), so it is clear context rather than full when/when-not coverage.
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 |
|---|---|---|
| summary | Yes | |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: validation is limited to Labelixa's implemented command subset, and 'a clean result is not a guarantee that a specific printer accepts the job' — an important scope caveat. It stops short of elaborating finding severity levels or any limits, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, no filler. Front-loads what the tool does, then the scope caveat, then the workflow ordering — a sensible information hierarchy.
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?
Output schema exists so return values need not be re-explained, and annotations cover the safety profile. The description still supplies the non-obvious bits an agent needs — validation scope limits and the tspl_preview/language_detect workflow — making it complete for this tool's 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?
Single parameter with 100% schema description coverage ('Raw TSPL/TSPL2 code'), so the schema already carries the semantics. The description mentions 'TSPL/TSPL2 code' but adds no format, encoding, or size guidance beyond 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?
States a specific verb and resource — 'Lint TSPL/TSPL2 label code' — plus the output shape ('positioned findings with severity as JSON'). The scoping phrase 'Checks the command set Labelixa implements from the TSPL2 manual' cleanly separates it from zpl_validate/cpcl_validate/epl_validate 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?
Gives explicit ordering ('Run this before tspl_preview') and a conditional routing rule ('if you are not sure which language the code is, call language_detect first'), naming the exact sibling by name. No inference required.
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, non-empty, from ^XA to ^XZ. Send real line breaks, not the two characters \n. | |
| 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?
The annotations already cover the safety profile: readOnly, idempotent and non-destructive. The definition adds real behavioral context beyond them: the return is a PNG image, each call renders exactly one label from a stream and index selects which label, and the response includes an editor link the user can act on. It does not mention behavior on invalid ZPL, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is four sentences, with the core action front-loaded and the parameter and output notes following in a logical order. Every sentence carries information, though the em-dash rationale sentence is slightly longer than needed.
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 definition must describe the return value, and it does mention both the PNG image and the editor link. For a five-parameter, read-only rendering tool, the definition leaves little ambiguous, with only error responses and rendering fidelity left unspecified.
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 coverage is 100%, so a baseline of 3 applies. The definition earns a 4 by explaining that index picks one label from a multi-label stream, so the parameter becomes meaningful even though the schema only describes it as 'Label index in the stream'. The other four parameters are left entirely to the schema, which is adequate.
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 definition opens with a specific verb and resource ('Render ZPL label code and return the label as a PNG image'), which cleanly separates it from the validating and explaining siblings such as zpl_validate and explain_zpl. The reason for the call — to visually verify the label — is stated up front.
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 definition explains clearly when to use this tool: an LLM can write ZPL but cannot otherwise see the rendered result. It also notes the one-call-per-label rule and explains how to traverse multi-label streams. It never names an alternative such as zpl_validate for syntax-only checks, so it does not give explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pass/fail lint for ZPL — machine-readable diagnostics with line/column, code and severity: unknown commands, missing ^FS, out-of-range parameters, fields outside the label. Fast; run it before zpl_preview whenever you generate or edit ZPL. For a human-readable report with a score, use explain_zpl instead.
| Name | Required | Description | Default |
|---|---|---|---|
| zpl | Yes | ZPL source, non-empty (^XA...^XZ) | |
| dpmm | No | Printer density in dots per mm: 6, 8, 12 or 24 (8 = 203 dpi, 12 = 300 dpi, 24 = 600 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 |
|---|---|---|
| rfid | No | |
| fields | No | |
| summary | Yes | |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds real value on top by describing the output shape (line/column, code, severity) and the speed characteristic. It stops short of saying what it does not check (e.g., no auto-fix, no rendering preview), which would complete the picture.
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 tight clauses with zero padding: what it returns, why to run it, and the alternative. The valuable routing information is front-loaded and the trailing alternative 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?
With an output schema present and full schema coverage, the description need not explain return values or parameter formats; it covers the remaining gaps (purpose, placement in the workflow, sibling choice) completely.
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 schema already explains dpmm, width_in and height_in in detail, including defaults and the boundary-check dependency. The description adds nothing about parameters, 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?
States a specific verb+resource ('Pass/fail lint for ZPL') and enumerates the diagnostic classes it produces (unknown commands, missing ^FS, out-of-range params, fields outside the label). It explicitly distinguishes itself from explain_zpl, so an agent can tell the two apart without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit sequencing rule ('run it before zpl_preview whenever you generate or edit ZPL') and names the alternative for the human-readable case ('use explain_zpl instead'). Both the when-to-use and the when-not-to-use are covered.
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.
barcode_verify1 field changedInput schema / properties / image_base64 / descriptionPrevious value: -"Base64-encoded image bytes"New value: +"Base64-encoded image bytes. A data:image/...;base64, prefix and line breaks are accepted."bulk_list1 field changedInput schema / properties / limit / defaultAdded value: +50bulk_status1 field changedInput schema / properties / job_id / descriptionPrevious value: -"Job id from bulk_submit"New value: +"Job id from bulk_submit (32 hex characters; the dashed UUID form is accepted)"bulk_submit3 fields changedInput schema / properties / dpmm / defaultAdded value: +8Input schema / properties / output / defaultAdded value: +"zpl"Input schema / properties / rows / descriptionPrevious value: -"One object per label: placeholder name -> value"New value: +"One object per label: placeholder name -> value, e.g. [{\"name\": \"Ada\", \"sku\": \"A-1\"}]"image_to_zpl1 field changedInput schema / properties / image_base64 / descriptionPrevious value: -"Base64-encoded image bytes"New value: +"Base64-encoded image bytes. A data:image/...;base64, prefix and line breaks are accepted."save_label1 field changedInput schema / properties / dpmm / descriptionPrevious value: -"Print density: 6, 8, 12 or 24"New value: +"Print density in dots per mm: 6, 8, 12 or 24 (8 = 203 dpi)"template_get1 field changedInput schema / properties / template_id / descriptionPrevious value: -"Template id from template_list"New value: +"Template `id` from template_list (the id, not the display name)"zpl_preview1 field changedInput schema / properties / zpl / descriptionPrevious value: -"ZPL source (^XA...^XZ)"New value: +"ZPL source, non-empty, from ^XA to ^XZ. Send real line breaks, not the two characters \\n."zpl_validate2 fields changedInput schema / properties / dpmm / descriptionPrevious value: -"Printer density (8 = 203 dpi). The boundary check measures against it — pass the real value."New value: +"Printer density in dots per mm: 6, 8, 12 or 24 (8 = 203 dpi, 12 = 300 dpi, 24 = 600 dpi). The boundary check measures against it — pass the real value."Input schema / properties / zpl / descriptionPrevious value: -"ZPL source"New value: +"ZPL source, non-empty (^XA...^XZ)"printer_language_to_zplcpcl_validate5 fields changedOutput schema / properties / diagnostics / items / properties / mesajRemoved value: -{
- "description": "Human-readable message in the requested language",
- "type": "string"
-}Output schema / properties / diagnostics / items / properties / messageAdded value: +{
+ "description": "Human-readable message in the requested language",
+ "type": "string"
+}Output schema / properties / ozetRemoved value: -{
- "properties": {
- "error": {
- "type": "integer"
- },
- "info": {
- "type": "integer"
- },
- "toplam": {
- "type": "integer"
- },
- "warning": {
- "type": "integer"
- }
- },
- "required": [
- "toplam",
- "error",
- "warning",
- "info"
- ],
- "type": "object"
-}Output schema / properties / summaryAdded value: +{
+ "properties": {
+ "error": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "total": {
+ "type": "integer"
+ },
+ "warning": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "diagnostics",
- "ozet"
-]New value: +[
+ "diagnostics",
+ "summary"
+]epl_validate5 fields changedOutput schema / properties / diagnostics / items / properties / mesajRemoved value: -{
- "description": "Human-readable message in the requested language",
- "type": "string"
-}Output schema / properties / diagnostics / items / properties / messageAdded value: +{
+ "description": "Human-readable message in the requested language",
+ "type": "string"
+}Output schema / properties / ozetRemoved value: -{
- "properties": {
- "error": {
- "type": "integer"
- },
- "info": {
- "type": "integer"
- },
- "toplam": {
- "type": "integer"
- },
- "warning": {
- "type": "integer"
- }
- },
- "required": [
- "toplam",
- "error",
- "warning",
- "info"
- ],
- "type": "object"
-}Output schema / properties / summaryAdded value: +{
+ "properties": {
+ "error": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "total": {
+ "type": "integer"
+ },
+ "warning": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "diagnostics",
- "ozet"
-]New value: +[
+ "diagnostics",
+ "summary"
+]language_detect11 fields changedOutput schema / properties / confidenceAdded value: +{
+ "description": "Confidence level",
+ "type": "string"
+}Output schema / properties / dilRemoved value: -{
- "description": "Detected printer language",
- "type": "string"
-}Output schema / properties / evidenceAdded value: +{
+ "items": {
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "line": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / guvenRemoved value: -{
- "description": "Confidence level",
- "type": "string"
-}Output schema / properties / kanitlarRemoved value: -{
- "items": {
- "properties": {
- "kod": {
- "type": "string"
- },
- "satir": {
- "type": "integer"
- }
- },
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / karmaRemoved value: -{
- "description": "True when the input mixes languages",
- "type": "boolean"
-}Output schema / properties / languageAdded value: +{
+ "description": "Detected printer language",
+ "type": "string"
+}Output schema / properties / mixedAdded value: +{
+ "description": "True when the input mixes languages",
+ "type": "boolean"
+}Output schema / properties / puanlarRemoved value: -{
- "additionalProperties": {
- "type": "integer"
- },
- "description": "Per-language score",
- "type": "object"
-}Output schema / properties / scoresAdded value: +{
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "description": "Per-language score",
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "dil",
- "guven",
- "puanlar"
-]New value: +[
+ "language",
+ "confidence",
+ "scores"
+]template_list1 field changedInput schema / properties / category / enumPrevious value: -[
- "kargo",
- "urun",
- "raf",
- "palet",
- "qr"
-]New value: +[
+ "shipping",
+ "product",
+ "shelf",
+ "pallet",
+ "qr"
+]tspl_validate5 fields changedOutput schema / properties / diagnostics / items / properties / mesajRemoved value: -{
- "description": "Human-readable message in the requested language",
- "type": "string"
-}Output schema / properties / diagnostics / items / properties / messageAdded value: +{
+ "description": "Human-readable message in the requested language",
+ "type": "string"
+}Output schema / properties / ozetRemoved value: -{
- "properties": {
- "error": {
- "type": "integer"
- },
- "info": {
- "type": "integer"
- },
- "toplam": {
- "type": "integer"
- },
- "warning": {
- "type": "integer"
- }
- },
- "required": [
- "toplam",
- "error",
- "warning",
- "info"
- ],
- "type": "object"
-}Output schema / properties / summaryAdded value: +{
+ "properties": {
+ "error": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "total": {
+ "type": "integer"
+ },
+ "warning": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "diagnostics",
- "ozet"
-]New value: +[
+ "diagnostics",
+ "summary"
+]zpl_validate7 fields changedOutput schema / properties / alanlarRemoved value: -{
- "items": {
- "properties": {
- "line": {
- "type": "integer"
- },
- "x": {
- "type": "integer"
- },
- "y": {
- "type": "integer"
- }
- },
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / diagnostics / items / properties / mesajRemoved value: -{
- "description": "Human-readable message in the requested language",
- "type": "string"
-}Output schema / properties / diagnostics / items / properties / messageAdded value: +{
+ "description": "Human-readable message in the requested language",
+ "type": "string"
+}Output schema / properties / fieldsAdded value: +{
+ "items": {
+ "properties": {
+ "line": {
+ "type": "integer"
+ },
+ "x": {
+ "type": "integer"
+ },
+ "y": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / ozetRemoved value: -{
- "properties": {
- "error": {
- "type": "integer"
- },
- "info": {
- "type": "integer"
- },
- "toplam": {
- "type": "integer"
- },
- "warning": {
- "type": "integer"
- }
- },
- "required": [
- "toplam",
- "error",
- "warning",
- "info"
- ],
- "type": "object"
-}Output schema / properties / summaryAdded value: +{
+ "properties": {
+ "error": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "total": {
+ "type": "integer"
+ },
+ "warning": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "diagnostics",
- "ozet"
-]New value: +[
+ "diagnostics",
+ "summary"
+]save_labelcpcl_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.
