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 step in the workflow: listing items, creating a design, revising an existing design, quoting an order, and opening the external studio. The design_item vs. revise_design boundary is explicitly clarified by descriptions (new vs. redo existing). No tools appear to do the same thing.
All tool names follow a consistent snake_case verb_noun pattern: design_item, list_items, open_in_studio, quote_order, revise_design. There are no mixed conventions or vague verbs.
Five tools is well-scoped for this design-and-order workflow, with each tool earning its place. No unnecessary tools and no obvious missing step among the core operations.
The surface covers the main lifecycle: list options, create and revise designs, quote costs, and hand off to the external studio for final editing and checkout. Minor gaps exist, such as no tool to retrieve or list existing designs by design_id, but agents can work around this via the provided design_id and studio link.
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 non-destructive behavior. The description adds useful behavioral context: nothing is charged, sales tax is excluded and added at checkout, and the quote components are enumerated. It does not cover auth or rate limits, but for a read-only quote this is strong.
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 efficient sentences: front-loaded return components, then the no-charge caveat, then the input rule. Every sentence adds distinct value with no wasted wording.
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 carries the return burden and does so by listing per-piece cost, pieces, volume discount, shipping, and pre-tax total. Annotations cover safety; schema covers nested parameters. A minor omission is that item-key lookup via list_items appears only in the schema, not the description.
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 top-level 'lines' parameter lacks a schema description, but the tool description clarifies that a line is one item in one color with a count per size and says to use the sizes the customer named. The schema documents nested fields, and the description adds important line-grouping semantics beyond the structured data.
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 specifically what the tool does: calculates what an order would cost, including per-piece pricing, volume discount, shipping, and pre-tax total. 'Nothing is charged' distinguishes it from an actual checkout, but it does not explicitly differentiate from siblings, so 4 rather than 5.
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?
Implies pre-purchase quoting through 'Nothing is charged' and 'tax is added at checkout,' but gives no explicit when/when-not guidance or alternatives. The sibling list_items is only referenced in the schema, not in the tool description.
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.
quote_order1 field changedInput schema / properties / lines / items / properties / design_idAdded value: +{
+ "description": "The design_id this line prints, when one has been made. Omit on a price with no design yet.",
+ "type": "string"
+}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.
Custom t-shirts and apparel, printed and shipped in the US on your deadline.
Design custom apparel from chat: AI art on tees and hoodies, then a checkout link to buy.
Add one secure layer between your agents and this server.