PatchDesign.AI

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, and the description adds context beyond them: 15-30 second latency, watermark on previews, clean file only on order, and the 10-design free limit. It also discloses the non-idempotent retry policy, which the annotations alone would not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each load-bearing: capability and output, watermark/caveat, input spelling instruction, and quota/retry behavior. Front-loaded with the verb and result, 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, yet the description names the return payload (image plus design id plus order link), the latency, and the retry path — everything an agent needs to call it and interpret the result. Nothing material 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%, so baseline is 3; the description adds real value by instructing 'Say what the patch shows and any text on it, spelled exactly' and clarifying that with a reference image the description becomes adaptation guidance. It doesn't restate width/height/patchType constraints, which the schema already handles.

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 ('Generate a production-ready custom patch design from a description') and immediately distinguishes itself from siblings by noting it returns a design id 'for edits' and an 'order link'. An agent can separate this from edit_patch, order_link, quote_patch and sign_in_link without opening any 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 when-to-use conditions (from a description, optionally a reference image), a concrete retry rule ('If the result says the service was busy, call it once more with the same input'), and the free-quota/auth path ('10 free designs, then the user signs in with the link from sign_in_link'). This is routing-grade guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the safety profile; the description adds genuinely non-obvious behavior: the original design is preserved, a brand-new design with its own id is returned, and the call "counts as one design" (quota/cost implication). This is consistent with destructiveHint=false and idempotentHint=false and goes well beyond the annotation payload.

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 front-loaded sentence carries the action, the id requirement, two example instructions, and the return behavior with zero filler. 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 mutation tool with no output schema, the description covers id provenance, instruction form, the return object's identity, and quota impact. Remaining gaps (auth requirements, where the new design surfaces afterward, failure modes) are minor.

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 both parameters are already documented, including the d_... id format and the 2–800 character instruction. The description restates these (id prefix, plain-words change) and adds illustrative examples, which is useful but not meaningfully 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 ("Make a change to a design from this chat") and backs it with concrete instruction examples. The distinction from the sibling design_patch is only implied via the id provenance in the schema, not stated in the description, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"a design from this chat" and "works in any later turn" imply the context in which the tool is valid, but there is no explicit when-not-to-use or named alternative (e.g. design_patch) to steer selection. Usage is inferable rather than spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds real behavior beyond the readOnlyHint/openWorldHint annotations: it explicitly states nothing is ordered or charged by the call, that the user reviews and pays on patchdesign.ai, and what the link carries. That is exactly the side-effect clarification an agent needs for a tool whose name sounds like a purchase. It stops short of link lifetime, auth needs, or return shape.

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 tool returns, then the no-charge disclaimer, then the usage trigger. Nothing is padded, though the sentence order puts usage last where routing cues are usually most needed.

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 two-parameter, annotation-backed link generator with no output schema, the description covers purpose, the side-effect-free guarantee, off-platform payment, and usage triggers. Only the quote_patch boundary and link properties (expiry, one-time use) are left unstated.

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 both parameters are already documented, so the baseline is 3. The description adds that quantity drives the returned price and that type/size are baked into the link, but that mention of type/size matches no actual parameter, which slightly blurs rather than sharpens 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 uses a specific verb+resource framing ('the link where the user orders a design from this chat') and states what the returned link encodes (type, size, quantity, price for that quantity). It is clearly distinguishable from design_patch/edit_patch by being a link-generator rather than an editor, though it never names the closest sibling, quote_patch.

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 explicit trigger conditions: 'use it when the user wants to buy, get a quote by email, or adjust size and quantity on the site.' That is clear context, but there are no exclusions and no routing against quote_patch, which is the sibling an agent would most likely confuse with the 'quote by email' case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true and openWorldHint=false, but the description adds genuinely useful behavior: pricing comes from a live production table, the call is free and instant, and the response includes the next quantity breaks plus what the price already covers (artwork, pre-production sample, worldwide shipping). This is value beyond the annotations rather than a restatement of the safety profile.

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 is priced and what comes back, with the quantity-1 special case and the inclusions folded in rather than expanded into filler. No sentence is redundant with another.

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 carries the return-value burden and does it: per-patch price, total price, next quantity breaks, and what the price includes. Combined with the annotations covering the read-only nature, an agent has everything needed to call and interpret it.

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 width, height, quantity and patchType with ranges, defaults and the enum, including the note that iron-on/velcro/sew-on map to embroidered. The description largely restates the parameter set ('type, size and quantity in') instead of adding syntax or constraint detail, 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?

The description names a specific verb and resource ('Price a custom patch from the live PatchDesign.AI production price table') and states the input/output shape in one breath: type, size and quantity in, per-patch and total price in USD out. This cleanly separates it from siblings like design_patch and edit_patch, which create or modify artwork rather than return 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?

It gives clear triggering guidance ('call it whenever a price comes up') and a specific case rule ('Quantity 1 returns the single-patch (sample) prices'). It does not name a when-not condition or an alternative sibling for pricing scenarios, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the link expires in 15 minutes, it changes the account allowance to 25 designs/day and 150/month, and it saves designs to the account. It does not contradict 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?

The description is front-loaded with the purpose, then covers expiry and the required user interaction. It is slightly long in the first sentence but every clause conveys useful scope or effect, and the structure is clear.

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 simplicity (no parameters, no output schema) and the existing annotations, the description supplies everything an agent needs: what the link does, its limits, its expiry, and the follow-up action. 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?

The tool has zero parameters, so per the rubric the baseline is 4. The description appropriately adds no parameter information because there are none to describe.

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 resource (a sign-in link to PatchDesign.AI) and its effect (connecting the chat to the user's account, lifting limits, saving designs). It is clearly distinguishable from the sibling tools, which perform design, edit, order, and quote actions.

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 usage instructions: give the link to the user, then continue once they confirm connection. It also implies when to use it (to lift limits and save designs), but it does not explicitly name alternatives or when to avoid this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.