Design custom embroidered, woven, chenille, printed and PVC patches, price them, and link to order.
Scored across 5 tools
Each tool maps to a distinct step in the patch workflow: create (design_patch), revise (edit_patch), price (quote_patch), purchase (order_link), and account connection (sign_in_link). Descriptions explicitly cross-reference each other (design_patch points to edit_patch for changes; quote_patch vs order_link are separated by 'price question' vs 'buy/quote-by-email'), leaving little room for misselection.
Three action tools follow a clean verb_noun pattern (design_patch, edit_patch, quote_patch), while the two link-returning tools use noun_link (order_link, sign_in_link). The split is readable and semantically motivated (returns a link), but it is a deviation from a single uniform convention.
Five tools is a tight, well-scoped surface that exactly covers the stated purpose: generate, iterate, price, order, and authenticate. No tool looks redundant or like a thin wrapper, and nothing essential is obviously padded in.
The core lifecycle (create → edit → quote → order → sign in) is fully covered, with sensible handling of free-tier limits and busy-service retries. Minor gaps exist: no way to list or re-fetch prior designs by id, no order status/retrieval, and no delete, though the chat-scoped design id model makes most of these workable.
Generate a production-ready custom patch design from a description (and optionally a reference image URL). Takes about 15 to 30 seconds and returns the design as an image plus a design id for edits and an order link. Previews carry a light PatchDesign.AI watermark; the clean file comes with an order. Say what the patch shows and any text on it, spelled exactly. To change a design already made in this chat, use edit_patch with its id. A chat gets 10 free designs, then the user signs in with the link from sign_in_link. If the result says the service was busy, call it once more with the same input.
| Name | Required | Description | Default |
|---|---|---|---|
| widthIn | No | Width in inches, 1 to 12.5. Default 3. | |
| heightIn | No | Height in inches, 1 to 12.5. Default 3. | |
| patchType | No | Patch type: embroidered (default), woven, chenille, printed, pvc-2d or pvc-3d. Iron-on, velcro and sew-on are backings on an embroidered patch, so use embroidered for those. | |
| description | Yes | What the patch should show: subject, colors, mood, and any lettering spelled exactly as it should appear. 3 to 1500 characters. | |
| referenceImageUrl | No | Optional https URL of a logo, sketch or photo to base the patch on. With a reference, the description is guidance about how to adapt it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose openWorldHint=true, non-idempotent, non-destructive behavior, and the description adds substantial extra context: 15–30s latency, the watermark on previews, the free-design quota, and the retry-on-busy rule. That is genuinely useful, but the safety profile is largely carried by annotations, so a solid 3 rather than top marks.
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 action and return shape, then progressively adds latency, watermark, quota, and fallback instructions. Every sentence carries an operational fact; there is 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?
No output schema exists, and the description fully covers the return value (image, design id, order link). Latency, quota, retry, and edit routing are all present, leaving nothing an agent needs to call it correctly.
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 parameters are fully documented structurally and the baseline is 3. The description reinforces how to write the 'description' field ('say what the patch shows and any text on it, spelled exactly'), but adds no new facts about widthIn, heightIn, patchType, or referenceImageUrl beyond the 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?
States a specific verb and resource — 'Generate a production-ready custom patch design from a description' — and names the optional reference image input. It also explicitly distinguishes itself from edit_patch, so the agent can separate the two without opening a 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?
Gives explicit routing rules: use edit_patch with a design id to modify an existing design, retry once on a 'service busy' response, and sign in via sign_in_link after 10 free designs. Each alternative and condition is named rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a change to a design from this chat: pass its design id (d_...) and the change in plain words ("make the border gold", "change TROOP 42 to TROOP 24"). Use it for a change the user asks for later in the chat too, so the original artwork is kept. Returns a new design with its own id; the original stays. Counts as one design.
| Name | Required | Description | Default |
|---|---|---|---|
| designId | Yes | The design id from the design_patch or edit_patch result for that design, e.g. d_1a2b3c4d5e6f7a8b, not its D- number. It works in any later turn of the chat. | |
| instruction | Yes | The change, in plain words. 2 to 800 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=false). The description adds copy-on-write semantics that the annotations cannot convey — a new design with its own id is returned and the original stays — plus a billing detail ('counts as one design'). This is meaningful context beyond structured fields.
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 action and required inputs, then examples, then return semantics. Slightly redundant — 'so the original artwork is kept' and 'the original stays' say the same thing — but every sentence still earns its place.
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 carries the return-value burden: a new design with its own id, original preserved, one design counted. Both parameters are required and documented, and the design-id lifetime ('works in any later turn of the chat') is clarified in the schema. Nothing an agent needs to call this 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 both parameters are already fully documented, and the description mostly restates them (design id format d_..., change in plain words). The added example phrasings ('make the border gold') are marginally useful but do not extend beyond what the schema and usage text already cover, so the 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?
States a specific verb and resource ('Make a change to a design from this chat') and names the required inputs, so an agent knows this edits an existing design rather than creating one. It does not explicitly name the sibling design_patch to draw the boundary, but the 'from this chat' scope implies the create-vs-edit distinction.
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 clear context for use: a change the user asks for later in the chat, with the note that the original artwork is kept. It does not name alternatives (e.g., design_patch) or state exclusions, so the routing guidance is strong but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The link where the user orders a design from this chat, with the type, size and quantity set, plus the price for that quantity. Nothing is ordered or charged by this call; the user reviews and pays on patchdesign.ai. Use it when the user wants to buy, get a quote by email, or adjust size and quantity on the site.
| Name | Required | Description | Default |
|---|---|---|---|
| designId | Yes | The design id (d_...) from the result of that design, not its D- number. | |
| quantity | No | How many patches they want. There is no minimum order. Default: the first price break for the type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds real value beyond annotations: it explicitly states nothing is ordered or charged, that the user reviews and pays on patchdesign.ai, and implicitly that the return value is a URL. With readOnlyHint/idempotentHint already covering the safety profile, this is strong supplementary context, though it omits the link's expiration or any auth requirements.
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 what the link contains before the important 'no charge' clarification and then the usage trigger. Every sentence carries information, with only the type/size mention being slightly extraneous.
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?
For a read-only link-builder with no output schema, the description covers what the link is, what it costs (nothing), where payment happens, and when to use it. An agent could call this correctly without opening 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 coverage is 100%, so designId and quantity are already fully documented (including the price-break default). The description repeats quantity and adds 'type' and 'size', which are not parameters at all, adding mild confusion rather than meaning. Baseline 3 is appropriate.
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 a specific artifact – a link that pre-fills type, size, quantity and price for ordering a design – which is concrete and clearly distinct from quote_patch and sign_in_link. It is phrased as a noun ('the link') rather than a verb, and the title 'Order a design' oversells the action, but the body immediately corrects that.
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?
Explicit trigger conditions are given: use it when the user wants to buy, get a quote by email, or adjust size/quantity on the site. No when-not guidance or named alternatives are provided (e.g. it does not say when to prefer quote_patch over this link), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price a custom patch from the live PatchDesign.AI production price table: type, size and quantity in, the per-patch and total price in USD out, with the next quantity breaks and what the price already includes (artwork, a pre-production sample, worldwide shipping). The price returned is the customer's price, not a starting figure. No quote is needed unless they choose a backing or border with no set price; then that price is confirmed within 2 business hours. There is no minimum: quantity 1 returns the sample prices, and by default quote the price breaks. Use it when the user asks about a price or a minimum.
| Name | Required | Description | Default |
|---|---|---|---|
| widthIn | No | Width in inches, 1 to 12.5. Default 3. | |
| heightIn | No | Height in inches, 1 to 12.5. Default 3. | |
| quantity | No | How many patches. Default 100. Use 1 for a single patch. | |
| patchType | No | Patch type: embroidered (default), woven, chenille, printed, pvc-2d or pvc-3d. Iron-on, velcro and sew-on are backings on an embroidered patch, so use embroidered for those. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, and the description adds genuinely useful context beyond them: the returned price is the customer's final price rather than a starting figure, there is no minimum, quantity 1 returns sample pricing, default is to quote the price breaks, and custom backings/borders are confirmed within 2 business hours. It also discloses what the price already includes (artwork, pre-production sample, worldwide shipping).
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?
Purpose and output are front-loaded, and most sentences carry real information. A few are dense and comma-spliced (the quote/no-quote sentence and the price-breaks default), which slightly slows parsing but does not waste words.
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?
For a read-only pricing lookup with four optional, fully documented parameters and no output schema, the description covers everything an agent needs: what goes in, what comes back, the no-minimum rule, and the exception path for unlisted backings and borders.
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 schema already documents all four parameters including the enum and ranges. The description only restates the input categories (type, size, quantity) and adds the behavioral detail that quantity 1 yields sample prices, which is closer to usage guidance than parameter semantics. Baseline 3 is appropriate.
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 – prices a custom patch from the live PatchDesign.AI production price table – and spells out the input/output contract (type, size, quantity in; per-patch and total USD out). It is clearly distinguishable from design_patch and edit_patch, which concern design rather than pricing.
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?
"Use it when the user asks about a price or a minimum" gives a clear trigger, and the note that no quote is required unless a backing or border lacks a set price supplies a when-not condition. It does not name the sibling tools or state what to call instead for design work, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A link that connects this chat to the user's PatchDesign.AI account (free), lifting the 10-design limit to the account allowance of 50 designs a day and 250 a month, and saving the designs to their account. The link expires in 15 minutes. Give it to the user, then continue once they say they have connected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the non-destructive, non-open-world profile. The description adds genuinely useful context beyond them: the link expires in 15 minutes, connecting lifts the free 10-design limit to 50/day and 250/month, and designs get saved to the account. It doesn't say whether the link is single-use or what happens if it expires unclaimed.
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, front-loaded with what the link does, followed by the expiry and the required agent workflow. The quota numbers are functional information the agent must relay to the user, so they earn their place rather than being 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?
For a zero-parameter, no-output-schema tool, the description covers purpose, effect, expiry, and the follow-up action needed after invocation. It could be slightly more complete by stating what the tool returns (a URL) and whether it can be regenerated.
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 zero parameters, so the baseline is 4. The description correctly reflects that no inputs are required; there is nothing further for it to document.
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 a specific verb+resource: it produces a sign-in link that connects the chat to the user's PatchDesign.AI account. It is clearly distinguishable from siblings like design_patch, edit_patch, order_link, and quote_patch, which perform design or purchase actions rather than authentication.
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 clear operational guidance: give the link to the user and continue once they confirm they have connected, and it implies the trigger condition (lifting the 10-design limit and saving designs to the account). It does not, however, explicitly state when not to use it or contrast it with sibling tools.
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_patch1 field changedInput schema / properties / patchType / enumPrevious value: -[
- "embroidered",
- "woven",
- "chenille",
- "printed",
- "pvc-2d",
- "pvc-3d"
-]New value: +[
+ "embroidered",
+ "woven",
+ "chenille",
+ "printed",
+ "leather",
+ "pvc-2d",
+ "pvc-3d"
+]quote_patch1 field changedInput schema / properties / patchType / enumPrevious value: -[
- "embroidered",
- "woven",
- "chenille",
- "printed",
- "pvc-2d",
- "pvc-3d"
-]New value: +[
+ "embroidered",
+ "woven",
+ "chenille",
+ "printed",
+ "leather",
+ "pvc-2d",
+ "pvc-3d"
+]order_link1 field changedInput schema / properties / quantity / descriptionPrevious value: -"How many patches they want. Default: the minimum run for the type."New value: +"How many patches they want. There is no minimum order. Default: the first price break for the type."edit_patch1 field changedInput schema / properties / designId / descriptionPrevious value: -"The design id returned by design_patch or edit_patch, e.g. d_1a2b3c4d5e6f7a8b. It works in any later turn of the chat."New value: +"The design id from the design_patch or edit_patch result for that design, e.g. d_1a2b3c4d5e6f7a8b, not its D- number. It works in any later turn of the chat."order_link1 field changedInput schema / properties / designId / descriptionPrevious value: -"The design id (d_...)."New value: +"The design id (d_...) from the result of that design, not its D- number."edit_patch1 field changedInput schema / properties / designId / descriptionPrevious value: -"The design id returned by design_patch or edit_patch, e.g. d_1a2b3c4d."New value: +"The design id returned by design_patch or edit_patch, e.g. d_1a2b3c4d5e6f7a8b. It works in any later turn of the chat."design_patchedit_patchorder_linkquote_patchsign_in_linkDesign custom t-shirts, hoodies, caps, mugs and totes, price an order, and link to order 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.
Turn designs into shipped parts: quote 3D printing, CNC, and decals, then check out.
Add one secure layer between your agents and this server.
