Print a photo or idea on a poster, canvas, mug, t-shirt, card or puzzle, with proof and price.
Scored across 12 tools
Most tools are cleanly separated by resource and action: search_products vs get_product, get_price vs get_order_status, and the three upload-related tools each do a distinct job. The only real overlap is between edit_design and restyle_design, which both derive a new design from an existing one in ~45 seconds and differ mainly in intent rather than mechanics.
Every tool follows a consistent snake_case verb_noun pattern (create_, edit_, restyle_, get_, search_, place_, use_), with no camelCase or bare-noun outliers. The verb set is small and each verb carries the same meaning across tools.
Twelve tools is well within the sweet spot for a design-to-order pipeline, and each one maps to a distinct step. No tool looks like filler or an accidental duplicate.
The end-to-end lifecycle is covered: browse products, get details and price, supply or generate a design, refine it, proof it, order it, and track it. Minor gaps remain: there is no get_design or list_designs to retrieve a design's details or preview later, and no way to check payment status or cancel an unpaid order beyond get_order_status.
Create a new design with our image model, fitted to the product (aspect ratio, transparent background for clothing). Takes about 45 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Exact text on the design, only if the user wants text | |
| product | Yes | Product reference | |
| description | Yes | Rich description of the image: subject, pose, style, colours, mood |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false), and the description adds genuinely new context: the generation model, automatic product fitting, transparent background for clothing, and a ~45-second latency the agent can plan around. It stops short of saying whether repeats create duplicate designs or whether credits are consumed.
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 the action, then the differentiating behavior, then the latency hint. Nothing is redundant and every clause carries information.
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?
As a non-read-only, non-idempotent creation tool with no output schema, the agent is left not knowing what comes back (a design ID, URL, or preview) or how to reference the result in later edit_design/place_order calls. The 45-second timing is helpful, but the return-value gap is material for a create 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 description coverage is 100%, so all three parameters (text, product, description) are already documented in the schema. The description only echoes 'product' fitting and the visual attributes that belong to the description field, adding no syntax, format, or constraint detail beyond the schema. 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 gives a specific verb and resource ('Create a new design') plus the mechanism ('our image model') and a key output trait ('fitted to the product, aspect ratio, transparent background for clothing'). It clearly implies a new design versus edit_design/restyle_design, but never names the siblings, so differentiation is inferred rather than stated.
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: 'Create a NEW design' hints that editing existing designs belongs to edit_design or restyle_design, and the mention of text/pose/colour suggests when a rich description is needed. There is no explicit statement of when to prefer this over use_chat_image or restyle_design, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Makes the print-ready files and a mockup that shows exactly what will be printed. Returns a proof id.
| Name | Required | Description | Default |
|---|---|---|---|
| design | Yes | Design id (ont_...) | |
| options | No | Options as {type: value} from get_product, e.g. {'type_garment_size': 'l', 'colours_garment': 'Black'} | |
| product | Yes | Product reference | |
| language | No | Language of the user for text on the product (calendar months): nl, en, de, fr, es | en |
| quantity | No | Number of copies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false and idempotentHint=false, so the safety profile is covered. The description adds genuinely new context by saying what is produced (print-ready files and a visual mockup) and what comes back (a proof id), but omits that repeated calls create new proofs and says nothing about cost or latency.
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 short sentences, outcome stated first and the return value second. There is no filler and nothing is buried.
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?
The core output is explained and the schema is fully self-documenting, which carries most of the load. For a non-idempotent creation tool it should still mention prerequisites and the fact that each call yields a distinct new proof, which is the main behavioural gap.
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%, with every parameter including options, language enum list and quantity bounds documented in the schema itself. The description adds no parameter meaning beyond the proof id return, 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?
Specific verb+resource: creates print-ready files plus a mockup and returns a proof id, which cleanly separates it from create_design or place_order. It stops short of naming a sibling or stating where in the workflow it sits, so an agent must infer it comes after design creation.
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?
No when-to-use, when-not-to-use, or prerequisite guidance at all. It never says a design id from create_design and options from get_product are required first, nor how this differs from just viewing a design.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a design or the user's own photo in plain words: add a short text, a name or a date, add a frame, change colours or remove something. Only that change is made. Creates a new design; the original is kept. Takes about 45 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| design | Yes | Design id (ont_...) | |
| product | No | Product reference it will be printed on; the result then gets the shape of that product (e.g. wide for a mug), with text inside the printed area | |
| instruction | Yes | What should change |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes meaningfully beyond the annotations by disclosing that a new design is created and the original is kept (reinforcing destructiveHint=false with concrete consequence) and that a call takes about 45 seconds, which is real latency information the agent cannot get from structured fields. The 'only that change is made' scoping claim is also useful behavioral context. It does not state what permissions or credits are needed.
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, front-loaded with the verb and the kinds of edits, followed by the two facts that matter for planning (new copy created, ~45s duration). 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?
Covers the mutation semantics, non-destructiveness and latency well for a 3-parameter tool with full schema coverage. The notable gap is what comes back — presumably a new design id the agent would need for follow-up calls — which is unstated and there is no output schema to fall back on.
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 format, the instruction field and the product-shape behavior are already documented in the schema. The description reinforces that the instruction is plain words but adds nothing about the product parameter's effect on output shape.
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 ('Change a design or the user's own photo') and enumerates concrete edit types (text, name, date, frame, colours, removal) so the agent knows the input style is plain-language. It does not distinguish itself from the sibling restyle_design, which is the nearest alternative, leaving a small ambiguity.
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 implied through the example edits and the note that 'only that change is made', which tells the agent this is for scoped, targeted edits rather than wholesale redesign. However there is no explicit when-not guidance and no mention of restyle_design or create_design as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status and tracking of an order.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes | Order number, format GP-XXXXXXXX |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, covering the safety profile. The description adds that the response includes tracking information, which is useful beyond annotations, but it doesn't describe error behavior for invalid order numbers or response format.
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 phrase that is front-loaded and free of filler. For a simple read tool, no words are wasted.
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 one fully documented parameter, rich annotations, and no output schema, the description covers enough for correct invocation. It could note what tracking data includes or how invalid orders behave, but those are minor for a simple read operation.
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% and the order parameter's format (GP-XXXXXXXX) is fully documented in the schema. The description adds no further parameter meaning, which meets the baseline when the 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?
States a specific resource (an order) and the attributes returned (status and tracking), so the agent knows what it does. However, it doesn't differentiate from siblings like get_price or get_product, which are also order/product lookups.
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 gives no when-to-use guidance, no prerequisites (e.g., 'after place_order'), and no alternatives. Usage is only implied by the tool name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price including shipping and VAT for the delivery country. This is exactly what the user pays.
| Name | Required | Description | Default |
|---|---|---|---|
| proof | Yes | Proof id (prf_...) | |
| state | No | US and Canada only: state or province (NY, CA, ON, BC, ...) | |
| country | Yes | Delivery country, ISO code (NL, DE, US, ...) | |
| postcode | No | Spain and Canada only: postcode, needed for the shipping price |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (destructiveHint=false, openWorldHint=false), so the bar is lower, and the description usefully adds that the returned amount is tax- and shipping-inclusive rather than a base price. However, it says nothing about why readOnlyHint is false for what looks like a pure lookup, nor about currency or failure behavior for unknown proofs.
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 short sentences with the key qualifier (shipping and VAT, delivery country) front-loaded and zero preamble. The second sentence is close to restating the first but does convey the 'this is the final total' semantics.
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 partially describe the return (a price including shipping and VAT), which is the most important thing. But it leaves gaps on a 4-parameter tool: where the required proof id comes from (presumably create_proof) and what the response looks like on invalid proof or unsupported country.
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 four parameters including the state/postcode country restrictions. The description only reinforces that country determines shipping and VAT; it adds no syntax, provenance for the expected proof id, or format detail 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?
The description names the resource (price) and states precisely what the price covers — shipping and VAT for the delivery country — plus the payoff, that this equals the user's total. That is clearer than a bare 'get price', though it never distinguishes this from siblings like place_order or get_product, which also surface monetary amounts.
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: 'for the delivery country' and 'exactly what the user pays' suggest using it to quote a total before ordering, but there is no explicit when-to-use, no exclusion, and no named alternative (e.g. use place_order to actually purchase). The agent must infer the workflow position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details of one product: options (size, colour, paper, frame), quantities and dimensions.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product reference from search_products |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds useful context about what data is exposed, but it does not describe error behavior, missing products, or response format details.
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, front-loaded sentence that immediately identifies the resource and the returned fields. There is no redundant or wasted language.
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 simple, read-only tool with one fully documented parameter, rich annotations, and no output schema, the description is nearly complete. It lists the main returned data categories but omits edge cases such as invalid product references or empty 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?
Schema description coverage is 100%, and the single product parameter is clearly documented as a reference from search_products. The description adds no additional parameter meaning beyond the schema, so the baseline score of 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 clearly states it returns details for one product and enumerates the relevant data categories: options such as size, colour, paper, frame, plus quantities and dimensions. It distinguishes itself implicitly from broader search tools by specifying a single product, but it does not explicitly name the sibling tool search_products.
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 implied: this tool is for retrieving details of a single product. However, the description does not state when to use it instead of alternatives like search_products or get_price, nor does it mention prerequisites such as obtaining the product reference first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether the user uploaded a file through the upload link; returns the design id when it is there.
| Name | Required | Description | Default |
|---|---|---|---|
| upload | Yes | Upload id (upl_...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description contributes the return behavior (design id when the file is present), but leaves the not-yet-uploaded case undefined — does it error, return empty, or return a status field?
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 sentence, front-loaded with the check and ending on the payoff. Slightly loose phrasing ('when it is there') keeps it from a 5, but there is no wasted text.
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?
There is no output schema, so the description is the only place return semantics can live — and it covers only the success case ('design id when it is there'). The pending/not-uploaded outcome an agent will hit while polling 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% with a single required parameter already documented ('Upload id (upl_...)'). The description adds nothing about the upload id format or how it relates to the link returned by get_upload_link. 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 check ('whether the user uploaded a file through the upload link') plus the useful outcome ('returns the design id'). It reads as a status/poll operation, which implicitly separates it from get_upload_link, though it never names that sibling.
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 phrase 'through the upload link' implies this is polled after get_upload_link, but the description never states when to call it, how often, or what to do if the upload hasn't happened yet. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a secure link (valid 24 hours) where the user uploads their own photo, drawing or design from their device.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | Optional: product reference |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (non-destructive, non-idempotent) but say nothing about lifecycle, so the description's key contribution is the 24-hour validity window and the fact that it produces a link rather than performing the upload. That is meaningful behavioral context beyond the annotations; it stops short of saying whether the link is single-use or what happens after expiry.
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 sentence, front-loaded with the return value and the 24-hour constraint, with no filler. Everything stated 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?
With no output schema, the description correctly takes on the burden of describing the return value (a secure link, 24h validity). It is nearly complete for a zero-required-parameter tool; the only gap is the post-upload handoff (what to call once the image lands), which matters in a flow with get_upload as a sibling.
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% for the single optional "product" parameter, so the baseline applies. The description adds nothing about what the product reference does to the returned link (e.g. whether it scopes or brands the upload), leaving that entirely to the schema's terse "Optional: product reference".
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 ("Returns") plus a concrete resource ("a secure link ... where the user uploads their own photo, drawing or design"), which is unambiguous about what the call produces. It does not, however, differentiate itself from the closely related sibling get_upload, so an agent must infer which one to call.
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 by the phrase "the user uploads their own photo ... from their device" — that hints the tool is for user-supplied images. There is no explicit when-to-use guidance, no statement about which sibling to pick instead (e.g. use_chat_image, get_upload), and no note on what to do after the upload completes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates an unpaid order for an approved proof and returns the link to the checkout page on myimage2life.com (Stripe). Nothing is printed before payment.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Price id (prs_...) from get_price |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety profile (not read-only, idempotent, non-destructive, closed-world), and the description adds real value on top: the order is created unpaid, the response is a checkout URL off-site on Stripe, and no print job is triggered until payment. That two-phase flow (order → external payment → production) is the key behavioral fact an agent needs. It does not say whether re-calling reuses or replaces an existing unpaid order, which matters given idempotentHint=true.
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 short sentences, zero padding, both front-loaded with the highest-value facts: what is created, what is returned, and the payment gate. Nothing redundant with the schema or annotations.
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 usefully describes the return value (checkout link) and the payment gate, which is enough to call this correctly. The one gap is that the proof being ordered is never a parameter, so an agent can't tell from the description how the proof is bound to the order.
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% and the single parameter already documents itself ("Price id (prs_...) from get_price"), so the description correctly doesn't restate it. Baseline 3 applies. It also leaves unexplained how the target proof is identified when only a price id is passed.
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 ("Creates an unpaid order") plus the scope of what it operates on ("for an approved proof") and what it returns ("link to the checkout page on myimage2life.com (Stripe)"). This cleanly separates it from create_proof, create_design, get_order_status, and get_price.
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?
States preconditions implicitly but clearly: the proof must already be approved and paid via Stripe checkout, and "Nothing is printed before payment" tells the agent printing has not happened yet. No explicit when-not-to-use or named sibling alternative, 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.
Redraws a design or the user's own photo in an illustration style, keeping people and animals recognisable and their colours the same. Creates a new design; the original is kept. Takes about 45 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| style | Yes | Illustration style | |
| design | Yes | Design id (ont_...), also for an uploaded photo | |
| details | No | Optional extra wish, e.g. 'warm autumn colours' or 'white background' | |
| product | No | Product reference it will be printed on; the result then gets the shape of that product (e.g. wide for a mug), with text inside the printed area |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description usefully discloses that the operation creates a new design and preserves the original, that subjects remain recognisable with unchanged colours, and that it takes about 45 seconds. It does not cover authentication, quota, or failure behaviour, but it adds meaningful operational context to the non-readOnly, non-idempotent 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?
Three short sentences, front-loaded with the core action and followed by the most important side effects and latency. There is no redundant or filler 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?
For a four-parameter generation tool with no output schema, the description covers the main behavioural concerns: non-destructiveness, preservation of subject identity and colours, and expected latency. It could be slightly more complete by indicating what the new design reference looks like, but it is close to sufficient.
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 explains design ids, style enum values, optional details, and product formatting. The description does not add parameter-level guidance beyond what the schema provides, so the baseline of 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?
The description gives a specific verb and resource ('Redraws a design or the user's own photo in an illustration style') and explicitly states the outcome is a new design while the original is kept. This distinguishes it from mutating siblings such as edit_design or create_design.
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 use case is implied clearly enough: apply an illustration style to an existing design or uploaded photo. However, it does not state when to prefer this over edit_design, create_design, or use_chat_image, nor does it give any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search printable products. Returns a reference, name and size per product.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Optional group: poster, wall_art, clothing, mug, card, calendar, puzzle, photo_book, home, sticker | |
| query | Yes | What the user wants, e.g. 'black t-shirt' or 'poster 50x70' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so safety is covered. The description usefully adds the return shape (reference, name, size per product), which matters since no output schema exists, but it says nothing about result limits, matching behavior (fuzzy vs exact), or empty-result handling.
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 short sentences with zero filler, and the purpose statement is front-loaded before the return-value note. Nothing could be cut without losing information.
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 simple two-parameter read tool with fully documented schema and strong annotations, the description covers purpose and return fields adequately. It could go further by noting pagination or result caps, but nothing essential for a correct call 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 description coverage is 100%: both the free-text query and the enumerated group values are fully documented in the schema. The description adds nothing about how query text is matched or how query and group interact, 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 (search printable products), which is clearly distinct from siblings like get_product or get_price. It never names a sibling to differentiate scope, but the verb itself carries the intent.
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 offers no when-to-use guidance and never mentions get_product, the obvious alternative for retrieving a single known product. The agent must infer the search-vs-fetch split entirely from the tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use an image the user put in the chat as the design.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | File from the chat |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=false and destructiveHint=false, so the safety frame is covered. The description adds nothing beyond that: it doesn't say what side effect occurs (design created? current design overwritten?), whether calling twice duplicates work, or what the agent should do afterward.
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 short sentence with zero filler and the key constraint front-loaded. It is efficiently sized, though the brevity is partly under-specification rather than deliberate density.
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?
This is a non-read-only tool with a nested required object and no output schema, so the description should explain the outcome of the call and any follow-up expectations. It says nothing about what the tool produces or how it relates to the other design-mutating siblings, leaving a real gap.
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 nested file object documents file_id, file_name, mime_type and download_url, so the baseline is 3. The description only clarifies the provenance of the file (must come from the chat), adding marginal value over 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: take an image the user posted in the chat and use it as the design. This is distinguishable from create_design/edit_design/restyle_design, though it never says whether it creates a new design, replaces the current one, or merely seeds a generation step.
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 precondition (an image the user put in the chat) is implied by the phrasing, which gives some sense of when it applies. But there are no explicit when-not conditions and no mention of alternatives like create_design or get_upload for sourcing images another way.
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.
create_designcreate_proofedit_designget_order_statusget_priceget_productget_uploadget_upload_linkplace_orderrestyle_designsearch_productsuse_chat_imageOrder photo prints, canvas, T-shirts and mugs from photos, made by a lab and posted in the US.
Print existing artwork on custom wall art, apparel, and gifts.
PrintGen makes custom apparel from an idea or a photo, with previews and a hosted checkout link.
Design custom t-shirts, hoodies, caps, mugs and totes, price an order, and link to order it.
Add one secure layer between your agents and this server.