Skip to main content
Glama
Sign In

Labelixa

by com.labelixa
OverviewDiscussionsAdmin

Print label

print_label

Send ZPL to a physical printer through the account's Labelixa DirectPrint agent. Requires an API key whose plan includes printing and a printer from printer_list (or a printer group name). The job is QUEUED, not printed: the response says whether the device is mapped by an agent and when the agent last connected; check print_status for delivery. Always show the user a zpl_preview before printing.

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": {
      "zpl": "<zpl>"
    },
    "name": "print_label"
  }
}

Input Schema

NameRequiredDescriptionDefault
zplYesRaw ZPL code
copiesNoNumber of copies (default 1)
device_idNoPrinter id from printer_list
printer_groupNoPrinter group name, instead of device_id
idempotency_keyNoOptional key; a retry with the same key returns the first job instead of printing again

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only say this is a non-read-only, non-destructive, non-idempotent write, which is minimal. The description adds the genuinely important behaviors: the job is QUEUED rather than printed synchronously, the response reports whether the device is mapped to an agent and when that agent last connected, and delivery must be polled via print_status. It omits any mention of the idempotency_key retry semantics, and that param sits awkwardly against idempotentHint=false.

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?

Four short sentences, each carrying distinct load-bearing information (mechanism, prerequisites, async queuing behavior, pre-print UX rule) with the critical "QUEUED, not printed" warning in the middle where it is not buried. No filler or restatement of the title.

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

Completeness5/5

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

For a 5-parameter mutation tool with no output schema, the description covers what an agent needs: access requirements, correct device sourcing, that success means queued not printed, what the response reveals, and where to confirm delivery. The absence of an output schema is compensated by the description of response contents.

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%, so every parameter including copies and idempotency_key is already documented, making 3 the baseline. The description only adds the sourcing constraint for the device ("from printer_list, or a printer group name") and says nothing about the copies or idempotency_key semantics beyond what the schema states.

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

Purpose5/5

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

States a specific verb and resource ("Send ZPL to a physical printer") and names the delivery mechanism (Labelixa DirectPrint agent), which no sibling shares. It also implicitly separates itself from zpl_preview/zpl_validate (rendering/validation) and print_status (delivery tracking).

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

Usage Guidelines5/5

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

Gives explicit prerequisites (API key on a plan that includes printing, printer obtained from printer_list or a group name) and explicit routing rules: show zpl_preview to the user first, and use print_status to follow delivery. Both the when-to-use and the when-to-use-something-else are named.

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

All Labelixa toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources