Put any picture on a shirt, hoodie, cap, tumbler or tote; get the link where the person buys it.
Scored across 5 tools
check_art and create_design both ingest images and report print sizing, creating some surface overlap, but check_art validates standalone art while create_design composes it onto a purchasable item. get_design, list_items, and report_problem are clearly distinct.
All five tools follow a clean verb_noun snake_case pattern (check_art, create_design, get_design, list_items, report_problem). No deviations or mixed conventions.
Five tools sit comfortably in the well-scoped 3-15 range, and each maps to a distinct step in the art-to-design workflow. No redundancy or filler.
Core workflow is covered: validate art, browse items, create/retrieve designs, and report problems, with payment intentionally offloaded. Minor gaps exist (no list_designs to enumerate saved designs, no delete/update for designs), which agents can mostly work around.
Fetches a picture from a public link, or takes an attached file, stores it for a design and reports its size in pixels and how big it prints well. PNG, JPG, WEBP, GIF, HEIC, PDF or SVG, up to 25 MB. Pictures that are never ordered are deleted after 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | A file the person attached, in the shape ChatGPT passes. | |
| image_url | No | A public http(s) link to the picture. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/openWorld/non-idempotent profile. The description adds real context beyond them: accepted formats, the 25 MB cap, and the retention rule that never-ordered pictures are deleted after 30 days.
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 short sentences with zero filler, leading with the action, then constraints, then the retention caveat. Every sentence carries information an agent needs.
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 covers what is returned (pixel dimensions and printable size) plus inputs and limits. Failure modes (bad link, oversized file, unsupported format) are not described, a minor gap for a nested-parameter intake tool.
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 baseline is 3, but the description adds constraint semantics the schema lacks: which formats are accepted and the 25 MB limit, plus it maps 'a public http(s) link' to image_url and 'an attached file' to file.
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 specific actions and resource: fetch from link or attached file, store it for a design, and report pixel size plus print size. Clear verb+resource, but it never mentions how it relates to siblings like create_design, so differentiation is left to the agent.
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?
Usage is only implied: the agent can infer this is the intake/validation step for a picture before a design is created, and the two input modes are named. There is no explicit when-to-use, when-not, or pointer to an alternative sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Puts a picture (a public link, an upload id, an attached file or SVG markup) on an item and colour and returns the page where the person sees it, picks sizes and pays, with a picture of the result, how big each side prints, the price including US shipping, and any problems. With no picture, it returns the page where the person adds their own picture to the item. A shirt's front prints small on the left chest or big and centered; backs print large. No payment passes through this tool: the person pays on the returned page. Printing requires that the person owns the art or has permission to print it. Limit: 30 designs per address per hour.
| Name | Required | Description | Default |
|---|---|---|---|
| dev | No | A developer's id, used with markup_usd. | |
| ref | No | The name of the assistant or app, such as "claude". | |
| svg | No | SVG markup (lettering or simple shapes) with a viewBox; scripts and linked files are removed. Fonts available: Lato, DejaVu Sans, DejaVu Serif, Liberation Sans, Liberation Serif, Nimbus Sans, URW Gothic, URW Bookman, C059, P052, Z003, Noto Color Emoji. | |
| file | No | A file the person attached, in the shape ChatGPT passes. | |
| item | Yes | The item to print on. | |
| side | No | Where it prints (default front). | |
| size | No | A size to start with on the page, such as "L". | |
| color | No | One of the item's colours; left out, its default. | |
| front | No | chest: small on the left chest (default). center: big and centered, on T-shirts, sweatshirts and hoodies. | |
| title | No | A name for the design (80 characters). | |
| upload | No | An upload id, instead of image_url. | |
| image_url | No | A public http(s) link to the picture. | |
| markup_usd | No | Dollars a developer adds to each item; the buyer sees the full price. | |
| back_image_url | No | A different picture for the back. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing that no payment passes through the tool, printing requires ownership or permission, there is a rate limit, and specific print placement rules (front chest vs. center, backs large). These are critical behavioral details for correct invocation.
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?
The description is front-loaded with the primary action and return value, then adds constraints. It is a bit long but every sentence provides useful context; no significant 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?
Given the tool's complexity (14 parameters, nested objects, no output schema) and its open-world, non-read-only nature, the description covers all essential aspects: inputs (picture types), outputs (page with preview, dimensions, price), behavioral constraints (no payment, permission requirement, rate limit), and print-specific rules.
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 14 parameters thoroughly. The description adds some contextual meaning (e.g., SVG handling, print placement) but does not need to compensate for missing parameter documentation; 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 verb and resource ('puts a picture... on an item') and clearly explains what the tool returns (a preview/checkout page with print dimensions, price with US shipping, and issues). It is distinguishable from siblings like get_design or list_items by focusing on the creation flow.
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 explains the core usage context (with or without a picture) and includes a key operational constraint (30 designs per address per hour). However, it does not explicitly state when to use create_design versus get_design or check_art, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A saved design: its page link, pictures, print sizes and price.
| Name | Required | Description | Default |
|---|---|---|---|
| design | Yes | The design id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. With no output schema, the description usefully discloses what comes back (page link, pictures, print sizes, price), which is real added context, but it says nothing about error behavior or what happens with an unknown id.
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?
A single short sentence with no filler, and the field list is front-loaded. It is efficient, though the fragmentary style leaves the action implicit.
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 one-parameter read tool with annotations and no output schema, the description covers the return fields, which is the main gap the schema leaves. It still omits when to prefer it over siblings and any failure/not-found behavior.
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 parameter 'design' is fully documented in the schema as 'The design id.' with 100% coverage, so the schema carries the burden. The description adds no extra meaning about the id format or source.
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 the resource (a saved design) and enumerates the fields it exposes (page link, pictures, print sizes, price), so an agent can infer it is a read of a design's details. However, it uses a noun phrase with no verb, and nothing distinguishes it from siblings like check_art or 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?
There is no statement of when to call this versus alternatives such as check_art or list_items, nor any prerequisite like needing a valid design id. Usage is only weakly implied by the returned field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything 1211 prints on: each item's colours, sizes, print sizes, the pixels a picture needs to print well, and its price including US shipping.
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | Optional: one item (for example "hoodie") to get just that one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description does add genuinely non-obvious behavioral context — that prices include US shipping and that pixel requirements are returned — but says nothing about list size, truncation, or cost of calling it with no filter.
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?
One front-loaded sentence that leads with the resource and then enumerates the returned fields. Zero padding, though the clause-heavy colon list is dense rather than cleanly structured.
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 burden of describing the return contents, and it does so reasonably well for a read-only listing tool. It nonetheless omits default scope (all items vs. filtered) and any pagination or cardinality note, leaving gaps an agent must resolve by trial.
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% and the single 'item' parameter is fully documented in the schema, including an example value, so the baseline is 3. The description contributes nothing about the parameter — no explanation of matching semantics, case sensitivity, or what happens if the named item does not exist.
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 the resource unambiguously as the catalog of items 1211 prints on, and enumerates the content each entry carries (colours, sizes, print sizes, pixel requirements, price). A verb like 'list' is only implied, and no sibling is explicitly ruled out, but the subject matter is distinct enough from check_art, get_design, and create_design that an agent can tell what this returns.
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?
There is no statement of when to reach for this tool versus get_design or check_art, and no mention that the optional 'item' parameter lets you narrow to a single entry. Usage is only inferable from the content list — the agent must guess whether this is a discovery step before create_design or a lookup after.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores a report about something wrong with 1211's results (a picture refused that should have printed, a wrong price, a picture of the result that does not match, a link that does not open, a failed checkout, or a missing item) with the design it concerns and a short description. A person reads every report. Limit: 20 per address per hour.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| design | No | The design id, when it is about one design. | |
| detail | No | What was wrong, in a sentence or two. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds genuinely non-derivable behavior: 'A person reads every report' discloses human review, and 'Limit: 20 per address per hour' discloses a rate limit. It does not say what is returned or whether a duplicate report is rejected, so it is not fully rich, but it goes well beyond the 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?
It is a single dense sentence plus one short sentence, with the core action front-loaded. The long parenthetical list is somewhat heavy but every item earns its place by clarifying valid report kinds. No filler or repetition.
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 does the needed work: it says the report is stored, that a human reads it, and imposes a rate limit. For a simple 3-parameter write tool this is nearly complete; only the return/confirmation behavior is left unstated, which is a minor omission.
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 67%, and the description supplements the gaps by explaining that the report includes 'the design it concerns' (the `design` param, design id) and 'a short description' (the `detail` param). The enumerated failure modes also disambiguate the `kind` enum values. The remaining gap is minor, since the schema itself carries the enum and required-field info.
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 (stores) and resource (a report about something wrong with 1211's results), and enumerates the concrete problem categories that map to the `kind` enum. It is clearly distinguishable from siblings like check_art, create_design, or get_design, which are all about designs rather than reporting faults.
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?
The examples ('a picture refused that should have printed, a wrong price, a picture of the result that does not match...') give the agent clear situational context for when to call this tool. However, it never states when NOT to use it or names an alternative path, so it stops short of explicit exclusion guidance.
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.
check_artcreate_designget_designlist_itemsreport_problemDesign custom apparel from chat: AI art on tees and hoodies, then a checkout link to buy.
See any clothing, eyewear or accessory on a photo of a person, in about 10 seconds.
Official AI-native print-on-demand MCP — say it, AI designs it, sell 40+ goods, earn royalties.
Shop all-over print cotton tees with your AI agent: search, cart, promos, checkout. Human pays.
Add one secure layer between your agents and this server.
