Skip to main content
Glama

Print labels

print_labels
Destructive

Requires print.org. Creates a PDF only and never prints on a physical printer. Direct print on a Print Station is separate, and only when the tools list_print_stations, print_to_station, and get_station_print_job are available. Print saved items with a print profile from this org. Pass exactly one of item_ids or all_items. all_items prints every row on the sheet (sheet_number, default 1). Duplicate ids in item_ids are ignored; use copies_per_label for repeats. Optional order: barcode, row_order (item_number ascending), sent (item_ids order), sku, or name. When omitted, the saved organization print_order_default is used. If that value is empty, print uses barcode and the response has needs_preference, order_options, and preference_question. Ask the user that question, then call update_print_preferences (items.write). Digit-only barcodes sort numerically (long GTIN safe); mixed values sort alphabetically. Empty sort values print last and add a warning. If barcode order differs from row order, the response includes a note. Ask which profile after listing them. Order quantity is not copies_per_label. Returns one PDF and the barcode string drawn on each label. Prefer download_url, a signed https link on a cloudlabels.io host. Use print_labels when the label count (items times copies_per_label) is 50 or less. Above 50, call start_print_job and poll get_print_job. A profile with a saved label sheet fills that sheet. start_position is optional and 1-based. It must be a whole number from 1 through the number of labels on the sheet. A roll profile ignores start_position and adds warnings.

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": {
      "profile_id": "<profile_id>"
    },
    "name": "print_labels"
  }
}

Input Schema

NameRequiredDescriptionDefault
orderNo
qualityNo
item_idsNo
all_itemsNo
profile_idYes
sheet_numberNo
start_positionNo
copies_per_labelNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: 'Requires print.org', the PDF-only/no-physical-print behavior, duplicates in item_ids ignored, empty sort values printed last with a warning, and the needs_preference/order_options response fields when no default order exists. Annotations already flag the mutation/destructive profile, so the description's job is context and it delivers it. It does not explain what the destructiveHint implies here, leaving a minor gap.

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

Conciseness4/5

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

Dense and front-loaded, with the critical PDF-only/scoping statement first and the volume-threshold rule prominent. Every sentence carries operational information, though the sort-order and preference-question passages could be tightened into fewer clauses.

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?

There is no output schema, but the description compensates by naming the return payload: one PDF plus the barcode string drawn on each label, download_url as the preferred signed link, and the needs_preference/order_options fields. Only the quality parameter's meaning and the profile selection mechanics remain unexplained.

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 0%, so the description must compensate, and it does for many parameters: the item_ids vs all_items mutual exclusivity, sheet_number default 1, copies_per_label vs order quantity distinction, all five order enum values with sort semantics, and start_position's 1-based bounds. However, it never explains the 'quality' enum or names profile_id explicitly, leaving two parameters undocumented in both places.

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 ('Print saved items with a print profile') and immediately scopes it: 'Creates a PDF only and never prints on a physical printer.' It explicitly separates itself from print_to_station and start_print_job, so an agent can distinguish it from siblings 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.

Usage Guidelines5/5

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

Gives explicit routing rules: use print_labels when label count is ≤50, otherwise start_print_job plus get_print_job polling; direct printing only when the print-station tools are available; ask the user the preference question and then call update_print_preferences. It also says to ask which profile after listing them, covering the pre-call workflow.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources