Skip to main content
Glama
ApparelHub-AI

apparelhub-mcp

Official

upload_design

Turn owned artwork, logos, or photos into a design_uuid for building products, without regenerating the mark. Supports URL fetch, presigned upload, or inline bytes with SVG for vector logos.

Instructions

Upload artwork the merchant ALREADY OWNS and turn it into a design_uuid usable by create_product / ship_product. This is the way to build products from a client's own files — a logo, a brand mark, a cleared cover, a photograph — instead of generating something new. If a client says their mark must not be redrawn, use this; never regenerate or approximate a mark to work around a missing file.

Three ways to supply the file, pick the cheapest one available:

  1. source_url — an https URL the server can fetch. One call, no context cost. Best when the asset is already hosted or reachable by link (the link must not require sign-in).

  2. no source at all — returns a presigned upload_url you PUT the bytes to yourself, then call this tool again with the returned image_uuid to finish. No context cost, full resolution, and the right choice whenever you can make an HTTP request (curl, fetch, requests).

  3. image_base64 — inline bytes. Works anywhere, but costs roughly 350k tokens per megabyte of file, so reserve it for small files when neither of the above is possible.

Accepts PNG, JPEG, WEBP and SVG. SVG is the BEST input for a logo or mark: it is rendered server-side at print resolution, so it stays crisp at any size. Two things must be true of the SVG first — text converted to outlines, and any linked image embedded — otherwise the upload is refused with instructions rather than silently losing that part of the artwork. For pixel art, or any hard-edge raster mark that must stay crisp, pass upscale="pixel" so a small file is enlarged without being smoothed.

[#85542c]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoDisplay title for the design. Defaults to the filename stem.
upscaleNoHow to resample if the file is below the 512px print minimum. "pixel" = nearest-neighbour, keeps pixel art and hard-edge marks crisp. "smooth" = for photographic art. "auto" (default) detects. Pass "pixel" for a client mark that must not be approximated.
filenameNoOriginal filename. Used for the default title.
workspaceNoWorkspace uuid (agency accounts).
image_uuidNoFinish a presigned upload: pass the image_uuid from a previous upload_design call after you have PUT the bytes. Also use this to resume polling if processing was still running.
source_urlNoPublic https URL of the artwork. The server fetches it. Must not require sign-in.
content_typeNoDeclared MIME type. Detected from the file when the bytes are supplied, so it is only needed for the presigned mode (defaults to image/png). Use image/svg+xml to upload vector.
image_base64NoBase64-encoded file bytes (a data: URI is accepted). Expensive in context — prefer source_url or the presigned mode. Capped at 4MB decoded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.2

TDQS

A4.9/5.0
Behavior5/5

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

With only openWorldHint in the annotations, the description carries the behavioral burden well: it discloses the two-step presigned-upload finish flow, the server-side SVG rendering at print resolution, the refusal-with-instructions behavior for non-outlined/unembedded SVGs, the ~350k tokens/MB cost of base64, and the 4MB decoded cap. These are real behavioral traits not present in any structured field.

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?

Front-loads the purpose in the first sentence before the three numbered supply modes, each of which ends with a decision rule. The length is justified by the multi-modal input handling; no sentence is redundant filler.

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 an 8-parameter, zero-required tool with no output schema, the description still names the returned artifacts (design_uuid, upload_url, image_uuid) inline, covers supported formats, failure modes, and cost tradeoffs. An agent has everything required to choose a mode and drive the multi-step flow.

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

Parameters4/5

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

Schema coverage is 100%, so most parameter meaning is already documented (baseline 3). The description nonetheless adds value the schema does not: the preference ordering among source_url / presigned mode / image_base64, and the reuse of image_uuid both to finish an upload and to resume polling. It does not explain content_type or workspace beyond the schema, so it is not a full 5.

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 ('Upload artwork the merchant ALREADY OWNS and turn it into a design_uuid') and names the downstream consumers (create_product / ship_product). It explicitly separates itself from generate_image by contrasting client-owned files against 'generating something new'.

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 an explicit when-to-use trigger ('If a client says their mark must not be redrawn, use this') plus an explicit prohibition ('never regenerate or approximate a mark'). It ranks the three input modes by cost and names the conditions that select each, which is exactly the routing guidance an agent needs.

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

Deploy Server

Other Tools