Labelixa

Submit bulk label job

bulk_submit

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).

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>",
      "rows": "<rows>"
    },
    "name": "bulk_submit"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 25, 2026

addedInput schema / properties / dpmm / default
```
Added value: +8
```
addedInput schema / properties / output / default
```
Added value: +"zpl"
```

changedInput schema / properties / rows / description

Previous value: -"One object per label: placeholder name -> value"New value: +"One object per label: placeholder name -> value, e.g. [{\"name\": \"Ada\", \"sku\": \"A-1\"}]"

AddedSep 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Labelixa tools Inspect

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.