Design custom t-shirts, hoodies, caps, mugs and totes, price an order, and link to order it.
Scored across 5 tools
Each tool targets a distinct action: design_item creates, revise_design modifies an existing design, list_items enumerates catalog data, quote_order prices an order, and open_in_studio hands off to the external designer. The design_item vs revise_design boundary is explicitly clarified (fresh artwork vs change to existing piece), leaving no meaningful overlap.
All five names follow a uniform snake_case verb_noun pattern (design_item, list_items, open_in_studio, quote_order, revise_design). The verbs are apt and the convention is applied without deviation.
Five tools is well-scoped to a focused design-to-quote workflow with no redundant or filler entries. Every tool covers a distinct step and earns its place.
The surface covers the full pre-checkout lifecycle (browse items, create/revise a design, quote, hand off to checkout) and order placement is intentionally external. Minor gaps exist—no way to list or reopen prior designs beyond a returned design_id, and no explicit design deletion—but core workflows are covered.
Make a print-ready design from a short description, for one item in one color. Returns a watermarked preview of the design on the item, a design_id for revise_design and open_in_studio, and how many free designs are left. Describe the ARTWORK only ("a snarling wolf head, two colors"), not the garment: the garment is chosen with item and color. Each call makes one design and spends one from the allowance (10 as a visitor, then 25 a day on an aipromodesign.com account). Pass back the visitor value from the previous answer so the allowance follows the customer.
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | Item key or the word a customer would use (tee, hoodie, mug, tote, cap, polo, long sleeve, crewneck, performance tee, women's tee, youth hoodie, notebook, tumbler). Use list_items for the full set. Defaults to the adult tee. | |
| brief | Yes | What the artwork shows, in the customer's words. The artwork alone - no shirt, no mug. | |
| color | No | The item's color by name (Navy, Black, White, Forest Green, Sport Gray, Red, Royal, Maroon...). Defaults to White. | |
| surface | No | Which print area: front (default), back, left_sleeve, right_sleeve. The design is sized for it. | |
| visitor | No | The visitor value from an earlier answer in this conversation, if there was one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the cost model (one design per call, 10 as a visitor, 25/day on an account), the return shape (watermarked preview, design_id, remaining free designs), and the stateful visitor handoff. The non-idempotent hint is confirmed by 'each call makes one design and spends one from the allowance'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action, then the return values, then the usage constraint and cost/visitor rule. Every sentence carries operational information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description names what comes back (preview, design_id, remaining allowance), states the consumption rule, and ties the tool to its siblings. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning for `visitor` (why it must be echoed back to keep the allowance with the customer) and clarifies the brief/item/color division of responsibility beyond the schema's own wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Make a print-ready design... for one item in one color') and immediately scopes the input to artwork rather than garment. This clearly separates it from revise_design (which takes an existing design_id) and list_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit guidance on what to pass ('Describe the ARTWORK only... the garment is chosen with `item` and `color`') and instructs passing back `visitor` so the allowance follows the customer. It implies but does not explicitly state when to prefer revise_design over a fresh design call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The items a design can go on: key, name, the blank it is printed on, price per piece, colors, sizes, and the print areas with their sizes in inches. Call this before quoting or when the customer asks what is available. Prices are per piece in US dollars; the first print area is in the price and each further area adds a per-piece charge shown here. Designing is free; nothing is charged until the customer orders on aipromodesign.com.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral/business context beyond that: prices are per piece in USD, the first print area is included while each additional area adds a per-piece charge, and nothing is charged until the customer orders. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core answer (what items include) followed by usage timing and then pricing semantics. The three sentences are dense but each carries information; the pricing sentence is the longest and slightly heavy, keeping it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, no output schema, and full annotation coverage, the description carries the remaining burden of explaining what is returned and how pricing works — and it does both. An agent has everything needed to call it and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4. The description usefully enumerates the fields the returned items carry (key, name, blank, price, colors, sizes, print areas with inch dimensions), which compensates for the absence of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states concretely what the tool returns — the items a design can go on (key, name, blank, price per piece, colors, sizes, print areas) — which is more than a restatement of the name. It is distinguishable from siblings like quote_order and design_item through the 'call this before quoting' framing, though it never explicitly contrasts itself with design_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger and sequencing: 'Call this before quoting or when the customer asks what is available,' which routes the agent relative to quote_order. It stops short of naming alternatives or stating exclusions, so it is clear context without full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A link that opens the aipromodesign.com designer with the design already on the item in that color and, when sizes are given, the order lines filled in. The customer finishes there: more edits with the designer's own tools, other print areas, names and numbers, sizes collected from a group, and checkout. Use it when the customer is ready to order or wants to keep working. Nothing is charged by opening it.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | ||
| visitor | No | The visitor value from an earlier answer, if there was one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (destructiveHint=false, idempotentHint=true), and the description adds genuine context beyond them: nothing is charged by opening it, and the customer completes edits, additional print areas, group size collection, and checkout on the destination site. It never says what the tool actually returns (a URL string) or whether the link expires.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the tool's effect and followed by what happens downstream and the no-charge caveat. The middle sentence is a long list of destination capabilities, which is informative but slightly overstuffed; overall little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by explaining that the result is a link that opens the designer, so the agent knows what it gets back. The unaddressed 'visitor' parameter and the absence of any lifetime/idempotency detail about the generated link are the remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the nested item, color, sizes, and design_id fields are well documented in the schema, but neither the description nor the schema explains the top-level 'lines' and 'visitor' parameters. The phrase 'when sizes are given, the order lines filled in' loosely maps to the lines structure and the defaults are covered by the schema, so baseline 3 is right.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete outcome: a link that opens the aipromodesign.com designer with the design pre-loaded on the item/color, and order lines filled when sizes are supplied. That is specific enough to separate it from design_item, quote_order, and revise_design, though it never names those siblings to draw the contrast explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger — 'use it when the customer is ready to order or wants to keep working' — and clarifies the boundary that opening charges nothing. It stops short of stating when not to use it versus revise_design or quote_order, so there is no routing rule if the customer only wants edits or pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What an order would cost: per piece by size, the pieces, any volume discount, shipping, and the total before sales tax (tax is added at checkout where it applies). Nothing is charged. Use the sizes the customer named; a line is one item in one color with a count per size.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the bar is lower. The description still adds value by disclosing the returned composition (per-piece by size, pieces, volume discount, shipping, total before tax) and the important tax exclusion at checkout. It does not cover rounding, currency, or handling of unknown items, but the key behavioral facts are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first front-loads what the tool returns, the second front-loads how to shape input. Every clause earns its place, including the tax and no-charge caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by describing the pricing breakdown and the tax treatment, and annotations already cover the safety profile. Gaps remain on currency, rounding, quantity minimums, and behavior for unrecognized items, but nothing an agent needs to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single top-level 'lines' parameter carries no schema description, but its nested properties do describe item, color, sizes, and surfaces in detail. The description's 'a line is one item in one color with a count per size' largely restates that structure and never mentions the surfaces parameter or its default. Useful clarification, but not enough to fully compensate for the low top-level coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (quote/what it would cost) and resource (an order) and enumerates the pricing breakdown it produces. It is unambiguous against siblings like list_items and design_item, none of which price anything. The added 'Nothing is charged' line sharpens the intent further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real input-shaping guidance ('use the sizes the customer named', 'a line is one item in one color with a count per size'), which tells the agent how to construct lines. However it names no alternative tool and gives no when-to-use or when-not-to-use conditions relative to siblings such as list_items or design_item. Routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redo an existing design with a change: a different color scheme, fewer details, bolder lines, a different pose, words added or removed. Works from the design, so the result stays recognizably the same piece. Spends one from the allowance like design_item. Returns a new design_id; the old one still exists.
| Name | Required | Description | Default |
|---|---|---|---|
| visitor | No | The visitor value from an earlier answer, if there was one. | |
| design_id | No | The design_id from that design's earlier result. If that result is no longer in the conversation, leave this out to use the customer's most recent design. | |
| instruction | Yes | What to change, in a sentence. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds genuinely new context: it costs 'one from the allowance,' returns a new design_id, and confirms the source design 'still exists.' The cost and non-destructive persistence behavior go beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action, then the semantic guarantee, then cost/return facts. Every sentence carries distinct information with no repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and no output schema, the description supplies the return value, the allowance cost, and the persistence guarantee an agent needs. Nothing critical is missing, though the visitor/design_id fallback semantics live only in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so design_id fallback behavior, visitor, and instruction are already fully documented. The description's only parameter-adjacent detail is the return-value note, not new per-parameter meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Redo an existing design') with concrete change examples (color scheme, detail level, lines, pose, words). It contrasts with the sibling design_item by noting they both 'spend one from the allowance' while this one operates on an existing piece, so an agent can tell them apart without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly frames usage (revise a design that already exists, expected to stay 'recognizably the same piece') and references design_item as the parallel case. It stops short of an explicit when-not or a named alternative for creating a fresh design, so it is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
design_itemlist_itemsopen_in_studioquote_orderrevise_designPut any picture on a shirt, hoodie, cap, tumbler or tote; get the link where the person buys it.
Design custom T-shirts, preview artwork, personalize team shirts and prepare a checkout link.
Design custom apparel from chat: AI art on tees and hoodies, then a checkout link to buy.
Print on demand for AI agents. No sign-up. Picture, words or logo on a tee, hoodie or tote.
Add one secure layer between your agents and this server.
