Skip to main content
Glama
Sign In

streetshirts

by com.streetshirts
OverviewDiscussionsAdmin

Personalise team shirts

create_design_variants
Destructive

Clone the active/base design into personalised designs. Supply areaId and variants with nameText, numberText, size, quantity and optional product/items. This replaces existing name/number text objects: first ensure separate name and number templates exist in the intended print area, adding missing templates with add_text. It does not create those text objects itself. Set append:true to retain existing session designs; otherwise the variants replace that collection. Preserve the common artwork and check each supplied name and number. Pass only the complete intended designs to checkout.

Input Schema

NameRequiredDescriptionDefault
optionsNoExisting arguments; advanced fields/aliases remain accepted. Supplied design patches can overwrite session content; preview/rendering can fetch public image URLs in those designs. Catalogue/session results include the full designArgumentSchema.
subjectYesThe exact subject returned by start_design_session.
requestIdYesGenerate a UUID for a new action. Reuse it only for retrying/polling that same action and payload. A new user edit needs a new UUID.
sessionTokenYesThe private expiring capability returned by start_design_session. Do not publish it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / options / description
      Previous value: -"Existing arguments; advanced fields/aliases remain accepted. Catalogue/session results include the full designArgumentSchema."New value: +"Existing arguments; advanced fields/aliases remain accepted. Supplied design patches can overwrite session content; preview/rendering can fetch public image URLs in those designs. Catalogue/session results include the full designArgumentSchema."
  2. Changed1 schema field changed
    • addedInput schema / properties / options / properties / append
      Added value: +{
+  "description": "Retain existing session designs when adding variants. Defaults false, replacing that collection.",
+  "type": "boolean"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description goes beyond the destructiveHint by specifying exactly what is replaced: existing name/number text objects. It also explains that the tool does not create those objects itself and clarifies append versus replace behavior, which is the key mutation semantics an agent needs.

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?

The description is dense but well front-loaded: purpose first, then prerequisites, then mutation behavior, then checkout guidance. Every sentence carries operational value for this destructive, nested-parameter tool.

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?

For a complex, destructive nested-object tool, the description covers the critical preconditions and replacement behavior. It does not describe return values, but the schema and sibling workflow give partial coverage; the missing return-shape guidance keeps it just below complete.

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 description coverage is high, so parameter meanings are already well documented. The description still adds useful semantic guidance for areaId, variants fields, and append, though it does not add much beyond the schema for subject, sessionToken, or requestId.

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?

The description states a specific verb and resource: cloning the active/base design into personalised designs. It distinguishes the tool from text-creation siblings by explicitly saying it does not create name/number text objects and that add_text is required for missing templates.

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?

It gives clear prerequisites and alternatives: ensure separate name and number templates exist, use add_text for missing templates, set append:true to retain existing session designs, and pass only complete intended designs to checkout. This is explicit when-to-use and how-to-prepare guidance.

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

All streetshirts toolsInspect
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