Cloudlabels

Describe label design

describe_label_design

Read-onlyIdempotent

Rules and live data for designing a label: column names with value_kind, currency_code, and a sample value, which barcode types that sample fits, thermal media ids (Dymo, Brother, Zebra, continuous tape), the Design Center fonts, and the element fields create_label_design accepts. Label width and height are 10 to 500 mm. font_size is 1 to 120 pt. An unknown font fails with UNKNOWN_FONT and lists the valid names. Text can set date_stamp. The date is calculated at print time from the organization time zone in Settings, User defaults, Regional. Do not send time_zone. Use offset_days (0 to 3650), offset_months (0 to 120), or offset_column (a whole number in a sheet column). unit is days or months. format includes DD/MM/YYYY. An empty or non-integer cell stops the print with DATE_STAMP_CELL. A missing organization time zone stops the print with DATE_STAMP_TIME_ZONE. Code 128 and Code 39 use the element height in millimetres. The default is 14 mm when height is omitted. EAN and UPC set the box height from the width so the digits stay on the label. Optional bar_height_mm is the rendered 1D bar height, from 0.423 to 16.933 mm. PDF, PNG, and ZPL use that same height. For Code 128 and Code 39 the box height becomes the natural content height, and a narrow box widens to the bars, so the bars are not scaled. Omit it and a new design uses the standard bar height. profile_id rebuilds the label, so an omitted bar_height_mm does not keep a height from the saved profile. Optional rotation is degrees from -180 to 180. A rotated element must stay inside the label. font_weight bold is drawn as regular for Bebas Neue, Pacifico, Righteous, Great Vibes, Satisfy, Anton, and Bungee, which only include weight 400. A barcode value that does not fit the type fails with BARCODE_TYPE_MISMATCH. The server does not switch that barcode to Code 128. Text on a currency column can set currency_format, prefix, suffix, and show_currency. QR join_mode is listed: space, none, or gs1_digital_link. QR can also use content (fixed text, no column) or wifi {ssid, password, security WPA|WEP|nopass, optional hidden}. static_text without a column is not enough. A Wi-Fi password is stored in plaintext in the label design and is visible in the QR. Do not log the password. Call this before designing. Does not return designState or another customer's layout.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "describe_label_design"
  }
}

Input Schema

Name	Required	Description	Default
`sheet_number`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already establish readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so safety is covered. The description adds genuinely new behavioral facts: it does not return designState or another customer's layout, and it surfaces error codes (UNKNOWN_FONT, BARCODE_TYPE_MISMATCH, DATE_STAMP_CELL) the caller will encounter downstream. However, most of the text describes constraints of create_label_design rather than the behavior of this lookup itself, so the added value is partial.

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

Conciseness2/5

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

The text is a long, unstructured run of facts that jumps between fonts, barcode heights, date stamps, currency formatting, QR/Wi-Fi content and error codes with no grouping or headings. The single most actionable instruction ('Call this before designing') is buried at the very end, and much of the material duplicates rules that belong with create_label_design.

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

Completeness3/5

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

Because there is no output schema, the description does useful work enumerating the returned reference data, which is appropriate for a read-only lookup. But it is simultaneously over-detailed on downstream design rules and silent on its own only parameter, leaving an agent unable to reason about how to scope the call.

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

Parameters2/5

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

Schema description coverage is 0% and the single parameter sheet_number is never mentioned in the description, so nothing explains what selecting a sheet number does (presumably scoping column/value data to that sheet). The description mentions 'a sheet column' only in the context of offset_column for date stamps, which does not help the caller populate this parameter.

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?

The opening sentence enumerates what the tool returns: column names with value_kind/currency_code/sample values, matching barcode types, thermal media ids, Design Center fonts, and the element fields create_label_design accepts. That is a specific, checkable purpose that an agent can distinguish from create_label_design or list_label_templates. It stops short of a crisp one-line 'this is a reference lookup for label design' statement, and the bulk of the text is about other tools' constraints rather than this tool's output.

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?

The sentence 'Call this before designing' gives an explicit ordering relative to create_label_design, which is the main decision an agent faces. There are no explicit exclusions (e.g., 'do not call for print-profile data, use list_print_profiles'), but the when-to-use context is unambiguous.

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

All Cloudlabels tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?