Loading ToolBench
MCP server for ZPLab, a Zebra ZPL label design tool. Provides tools for creating, validating, editing, and exporting ZPL label designs with support for design files, raw ZPL import/export, and integration with the ZPLab desktop application.
ZPLab MCP server demonstrates solid definition quality with 11 well-named tools following verb_noun conventions (create_draft, validate_draft, export_zpl, import_zpl, etc.). All tools have descriptions ranging 100-300+ characters, exceeding the 10-char minimum. Input schemas are present and typed for all tools. However, several parameters lack descriptions (e.g., 'objects' array in create_draft has minimal guidance on structure), and output schemas are not explicitly documented in the visible code. Error handling descriptions are absent, tools do not guide LLMs on recovery paths. Tool composition is strong: tools chain logically (create_draft → export_zpl → validate_zpl), and parameter naming is consistent (designFile, widthMm, dpmm). Security is adequate for read-only operations but patch_design and edit_design/open_in_app lack explicit permission gates or confirmation patterns.
Build a ZPLab design from a size, a list of objects and optional variables. Returns the parseable design file, preflight warnings, per-object bounds (dots), and bbox overlaps. Declare every value that changes per print as a variable and reference it in content as «name»; it becomes a ^FN slot the user can fill from a data source. Call get_schema for object types.
Change the open design in place with operations. Returns the edited design file plus fresh warnings, bounds and overlaps. Each call is one undo step the user can reverse.
Parse a design file and return its generated ZPL: plain printer bytes, or with ZPLab's ^FX metadata when `metadata` is true (lossless re-import).
Read the open design from the ZPLab desktop app including the user's own edits. Returns the design file, preflight warnings, per-object bounds (dots), and bbox overlaps. Barcodes are re-probed print-true; other measurements make text/images render-exact.
List supported object types and their props for building a draft.
Output schemas not documented. Tools return complex objects (design files, bounds, overlaps, warnings) but LLMs cannot see the structure. This forces agents to guess field names and types, risking failed downstream calls.
Parameter descriptions incomplete. 'objects' array in create_draft lacks guidance on required/optional fields per object type. 'operations' array in patch_design/edit_design has no schema for operation structure. LLMs cannot construct valid payloads without explicit field documentation.
No error recovery guidance. Tools do not describe what errors are retryable, what indicates user input needed, or what recovery steps to take. E.g., validate_zpl may fail on malformed ZPL but does not guide the LLM on correction.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Parse a raw ZPL stream into an editable design file (one page per ^XA block; feed it to export_zpl or open_in_app) plus parser findings (including fields the printer discards for a missing ^FS, which the design omits), per-object bounds (dots), and bbox overlaps. Size falls back to the caller's hints then 100x50mm. Right-justified z=1 1D barcodes (^FO/^FT) are normalised to top-left x (bwip-measured, same as the app import) and enable the label's emit1dZJustify gate.
Push a design file into the running ZPLab desktop app and wait for the app to confirm. This REPLACES whatever the user has open and clears their undo history, so ask before calling it; the reply reports how many objects were displaced. The app keeps the displaced design so the user can restore it. When `replaced.restorable` is false it could not keep it, so tell the user the replace is final.
Change an existing design instead of rebuilding it: update (positions and merged props), remove or add objects by id, and addVariable / updateVariable / removeVariable for the design's variables (a rename rewrites the «markers» that reference it). Ids come from any report's bounds. Adding or removing an object or a variable, or changing a variable's default, drops the affected pages' captured import bytes (a note says so) and the model re-emits them; an update keeps them and replays around the edited field. Returns the edited design file plus fresh warnings, bounds and overlaps.
Turn a data: URL into a placeable 1-bit graphic. Returns an image object ready for create_draft or patch_design.
Parse a design file and return schema errors, preflight warnings, per-object bounds (dots), and bbox overlaps.
Parse a raw ZPL stream (one page per ^XA block) and report it: object/page count, detected label, parser findings (unknown/partial/hardware-bound commands, fields the printer discards for a missing ^FS), preflight warnings, per-object bounds (dots), and bbox overlaps. widthMm/heightMm are fallbacks for streams without ^PW/^LL.
Destructive operations lack confirmation pattern. open_in_app and edit_design modify user state (replace open design, clear undo history) but do not offer dry-run or explicit confirmation. Agents may accidentally overwrite user work.
get_schema returns unknown structure. Description says 'List supported object types and their props' but does not document the response format (is it a flat list, nested object, array of type definitions?). LLMs cannot parse the result.