Skip to main content
Glama
Sign In
labelixa-mcp

labelixa-mcp

Official
by Labelixa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

zpl_command_help

Look up a ZPL command's syntax, parameter types, ranges, and defaults, and see whether the preview engine renders it. Check commands before building or debugging label templates.

Instructions

Look up one ZPL command in the maintained catalog: name, syntax, parameters (types, ranges, defaults) and whether the preview engine actually renders it — printer-side commands are honestly marked as not rendered.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "command": "<command>"
    },
    "name": "zpl_command_help"
  }
}

Input Schema

NameRequiredDescriptionDefault
localeNoLanguage for the name and descriptions (default English). Command codes, syntax strings, examples and parameter names are protocol and never change.
commandYesCommand code with or without prefix, e.g. ^PO, BC, ~DG

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.2
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed1 schema field changedv0.1.1
    • addedInput schema / properties / locale
      Added value: +{
+  "description": "Language for the name and descriptions (default English). Command codes, syntax strings, examples and parameter names are protocol and never change.",
+  "enum": [
+    "en",
+    "tr",
+    "de"
+  ],
+  "type": "string"
+}
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations exist, so the description carries the full load. It does disclose two real behavioral facts: the catalog is curated/maintained (so results are authoritative) and the tool reports whether the preview engine actually renders a command, flagging printer-side commands as not rendered. It says nothing about not-found behavior, completeness guarantees, or response shape beyond the field list.

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

Conciseness5/5

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

A single sentence, front-loaded with the action and resource, that packs the return contents and one important caveat without a wasted clause. Nothing is repeated from the name or schema.

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

Completeness4/5

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 substitutes by naming the returned fields (name, syntax, parameters with types/ranges/defaults, render status), which is exactly what an agent needs to interpret results. The gaps are minor: unknown-command behavior and whether lookups are exact-match only are unstated.

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

Parameters3/5

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

Schema description coverage is 100% and both parameters are documented in the schema, including the locale enum and the example command formats, so the baseline of 3 applies. The description adds no meaning beyond that — notably it never mentions the locale parameter or the accepted command-prefix forms.

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

Purpose4/5

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

Names a specific verb and resource ("look up one ZPL command in the maintained catalog") and enumerates what the result contains: name, syntax, parameter types/ranges/defaults, and render support. That is far more informative than a tautology. It stops short of explicitly distinguishing itself from the closest sibling, explain_zpl, which an agent would have to reason about on its own.

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

Usage Guidelines3/5

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

Usage is implied by "look up one ZPL command" — a reference lookup for a single command — but the description never says when to choose it over explain_zpl, zpl_validate, or zpl_compatibility, nor when not to. A reader can infer the catalog-lookup case but gets no routing guidance.

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

Deploy Server

Other Tools