Put any picture on a shirt, hoodie, cap, tumbler or tote; get the link where the person buys it.
Scored across 5 tools
Each tool targets a distinct action: list_items (catalog), check_art (validate/preview), create_design (build+checkout page), get_design (retrieve), report_problem (feedback). The only mild overlap is that both check_art and create_design accept images, but their purposes (preview vs. build a purchasable design) are clearly differentiated in the descriptions.
All five tools follow a clean verb_noun snake_case pattern: check_art, create_design, get_design, list_items, report_problem. No mixing of conventions or vague verbs.
Five tools is on the lean side but fits a focused print-on-demand flow (browse, validate, create, retrieve, report). Each tool earns its place; it only feels slightly thin because a few expected operations are absent.
The core lifecycle (list items → check art → create design → pay on page) is covered, but there's no way to enumerate a user's saved designs, no update/delete/cancel of a design, and no order-status tool. get_design requires an id with no list_designs companion, creating a dead end for discovering existing designs.
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 conversation, as an object with file_id and/or download_url. | |
| 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 provide readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds important behavioral context: supported formats, 25 MB limit, and 30-day deletion policy for unordered pictures. This exceeds annotation coverage, though it doesn't explain auth needs or rate limits.
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 a single, well-structured sentence with zero waste, front-loading the core action and then listing constraints. Every clause 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?
For a tool with 2 optional parameters, no output schema, and annotations that cover safety, the description provides all necessary context: input methods, storage behavior, supported formats, size limits, and lifecycle policy. Nothing critical 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 schema already documents both parameters (file and image_url). The description adds format and size constraints but doesn't explain the difference between using 'file' vs 'image_url' beyond the obvious. Baseline 3 is appropriate when schema does the heavy lifting.
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 uses a specific verb+resource ('Fetches a picture', 'stores it for a design', 'reports its size') that clearly distinguishes it from siblings like create_design or get_design. It states the full scope of the operation in the first sentence.
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 description implies the tool is for checking/uploading a picture, but doesn't explicitly say when to use this versus alternatives. There is no guidance on prerequisites or when-not-to-use, leaving the agent to infer the context.
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 conversation, as an object with file_id and/or download_url. | |
| 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?
Annotations only say the call is a non-read-only, non-idempotent, open-world write with no destruction. The description adds substantially more: no payment flows through the tool, printing requires owning or having rights to the art, and there is a concrete rate limit of 30 designs per address per hour. It also discloses what the returned page contains and that errors surface there.
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 in the first sentence, and the trailing sentences cover fallback behavior, print placement, payment and limits efficiently for a 14-parameter tool. The opening sentence is a dense run-on that could be split, which keeps it just short of 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 no output schema and 14 parameters including a nested file object, the description carries significant burden and does explain the return payload (result picture, per-side print dimensions, price with US shipping, problems) and the operating constraints. Minor gaps remain around the developer-oriented parameters (dev, ref, markup_usd) and how duplicate calls are handled.
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 the schema already documents all 14 parameters including enums for item, side and front. The description recasts those fields in prose (picture sources, colour, chest-vs-center printing) but adds no format, syntax or default detail the schema lacks, 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+resource combination: put a picture on an item and return the purchase/preview page, plus the no-picture fallback. It is clear what the tool produces, but it never names or contrasts with siblings such as get_design or check_art, so the agent must infer the 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?
It gives one useful conditional — with no picture it returns the page where the person uploads their own art — which hints at a degenerate usage mode. However there is no explicit statement of when to use this versus get_design, check_art or list_items, and no when-not guidance beyond the print-permission note.
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_art1 field changedInput schema / properties / file / descriptionPrevious value: -"A file the person attached, in the shape ChatGPT passes."New value: +"A file the person attached in the conversation, as an object with file_id and/or download_url."create_design1 field changedInput schema / properties / file / descriptionPrevious value: -"A file the person attached, in the shape ChatGPT passes."New value: +"A file the person attached in the conversation, as an object with file_id and/or download_url."check_artcreate_designget_designlist_itemsreport_problemPrint on demand for AI agents. No sign-up. Picture, words or logo on a tee, hoodie or tote.
Design custom t-shirts, hoodies, caps, mugs and totes, price an order, and link to order it.
Design custom apparel from chat: AI art on tees and hoodies, then a checkout link to buy.
Create, write and publish Printify products from chat, after a preview you approve.
Add one secure layer between your agents and this server.
