Skip to main content
Glama

Print Shop by Bottle Your Brand

Upload label artwork

upload_label_artwork

Show an upload panel in the conversation for a label or sticker (wine, beer, water bottle, dropper bottle, square or rectangle sticker) made from a file the customer has — including an image uploaded or generated in this chat, which cannot be passed to a tool directly. The panel resizes it to the label's exact size with bleed, shows a preview with the cut line and any problems, and gives them a button that opens the product page with the print-ready file attached. Use order_label_artwork instead when a public https image URL is available.

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": {
      "product": "<product>"
    },
    "name": "upload_label_artwork"
  }
}

Input Schema

NameRequiredDescriptionDefault
fitNocover (default) fills the label edge to edge and crops the overflow, for full designs and scenes. contain keeps the whole image inside the label and extends its background, for logos and wide water bottle labels.
sizeNoSize in inches, WxH. Defaults to the most popular. wine: 3.5x4; beer: 4x3.5; water: 8.25x1.75 or 8x2.125; dropper: 3x2; square-sticker: 3x3 or 2x2 or 4x4 or 5x5; rectangle-sticker: 3x2 or 4x2 or 4x3 or 6x4
artworkNoSet by the upload panel itself. Never fill this in.
productYesProduct: wine, beer, water (wrap-around water bottle label), dropper, square-sticker or rectangle-sticker (all-purpose square/rectangle stickers and labels for jars, boxes, bags, candles, etc.).
orientationNorectangle-sticker only: auto (default) prints vertical when the image is portrait.

Output Schema

NameRequiredDescriptionDefault
fitYes
sizeYes
readyNoPre-loaded artwork; when present the panel shows it ready to order.
productYesProduct key the upload panel orders for.
label_typeYes
uploadBaseYesOrigin the panel uploads to.
upload_urlYesPage to use if the panel cannot be shown.
orientationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond the annotations by describing the full downstream effect: the panel resizes to the label's exact size with bleed, shows a preview with cut line and detected problems, and produces a button that opens the product page with the print-ready file attached. With readOnlyHint=false and no destructive hint, the description usefully clarifies that the outcome is a prepared file rather than a silent write, though it doesn't state whether anything is persisted server-side or what permissions are needed.

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?

Two sentences, front-loaded with the core action before the sizing/preview behavior and the alternative-tool redirect. Dense but largely earned; the long parenthetical product list slightly front-loads detail that the product enum already carries.

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 tool with a nested artwork object, three enums, and an output schema that covers return values, the description supplies the missing operational story: when this tool is the right one, what the panel does to the image, and where the user ends up. Nothing an agent needs to call it correctly is absent.

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 product, size, fit, orientation and artwork are already fully documented in the schema, including the note that artwork is set by the panel and must not be filled in. The description adds only indirect context (label dimensions, bleed handling) rather than new per-parameter meaning, so the baseline 3 applies.

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?

Opens with a specific verb and mechanism ("Show an upload panel in the conversation") plus the resource scope (label or sticker for wine, beer, water bottle, dropper bottle, square or rectangle sticker). It also names the sibling it is not (order_label_artwork), so an agent can distinguish the two without opening the other 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?

States both the selecting condition (the artwork is a file the customer has, including an image uploaded or generated in this chat that can't be passed to a tool) and the exclusion with the alternative (use order_label_artwork when a public https image URL exists). The routing decision is fully specified.

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