RushOrderTees

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

Annotations already declare this is a non-read-only, idempotent, non-destructive operation. The description adds meaningful context beyond the schema by stating that the price is locked in server-side and that 'There is no way to pass a price,' which prevents the agent from attempting a price override. It still does not discuss reversibility or permission requirements, so it is not fully exhaustive.

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 no wasted text. The primary action and source of the option are front-loaded, followed by the critical identifier constraint and the price constraint.

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 annotations covering safety and idempotency, a full schema, and an output schema, the description supplies the key procedural context: where the option comes from and that price cannot be supplied. It is nearly complete, though it could mention whether a locked option can later be changed or how it relates to similar choice tools.

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 two required parameters are already documented clearly in the schema. The description reinforces that option_id must be passed 'exactly as returned,' but does not add format or constraint details beyond what the schema provides; the no-price statement is behavioral rather than a parameter clarification.

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: it locks in the option selected from get_options and its price. This clearly distinguishes it from the retrieval sibling get_options, though it does not differentiate it from other selection-related siblings such as choose_style or pick_choice.

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 should be used after get_options, since it references the option the customer picked from that tool. However, it gives no explicit guidance on when to use this versus choose_style, pick_choice, or other siblings, and no exclusions or prerequisites are stated.

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 (not read-only, idempotent, non-destructive); the description adds that the color is applied in the same call ('the style lands in that shade in one call'), which tells the agent no follow-up call is needed. It does not cover what happens on an invalid or stale style_id, or whether a prior choice is replaced.

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 front-loaded sentences: action, routing rule, then the color special case. Mostly earns its place, though the color sentence duplicates what the schema property already says rather than adding new 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?

An output schema exists, so return values need not be explained, and all three parameters are schema-documented. The description supplies the remaining decision-relevant context: when to call it, where free-text picks go instead, and how color composes with the call.

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 all three parameters are already documented. The description restates the color rule almost verbatim from the schema ('picked a picture from preview_colors or wants the style in another shade') and adds no syntax, format, or edge-case detail beyond it, 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 states a concrete action (commit the order onto one of the alternatives returned by describe_order, by id) and a secondary case (the style already chosen). It distinguishes itself from describe_order, but does not differentiate from lookalike siblings such as choose_option or pick_choice, leaving some ambiguity about which selection tool to pick.

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 an explicit trigger ('when the customer picks one of them'), an explicit exclusion with a redirect ('a pick in their own words can still go to describe_order'), and a conditional rule for color sourced from preview_colors. Routing is unambiguous for the cases it covers.

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?

Goes well beyond the annotations: it discloses that the returned URL must be presented as a specific labeled link, the multi-step customer flow it triggers (confirm email with a code, pay, enter shipping), that nothing is ordered until payment, that the call refuses with an explanation when the order isn't ready, and that signed-in customers get the order saved and no longer expiring. The side-effect disclosure is consistent with readOnlyHint=false and 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?

Front-loads the core action and ordering, then the usage flow, then the failure mode — a sensible sequence. It is slightly dense and the UI-label instruction is verbose, but each sentence contributes behavior the agent wouldn't otherwise know.

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?

An output schema exists, so return formatting doesn't need documenting here; the description instead covers preconditions, refusal behavior, side effects, and downstream customer steps. Nothing essential to calling or acting on the result 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% for the single order_id parameter, and the schema already says it comes from start_print_order; the description adds no further semantics about format or sourcing. Baseline 3 applies since the schema carries the load.

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 ('Returns the payment link') and adds the precondition ('fully specified order with a chosen option'), which separates it from sibling tools like get_options or choose_option that operate on orders that are not yet complete. An agent can identify the tool's job without opening the 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?

The required order state ('fully specified order with a chosen option') and the refusal behavior when the order isn't ready tell the agent when this tool applies versus earlier-flow siblings such as choose_option or start_print_order. No sibling is named explicitly as an alternative, so it falls 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.

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries most of the load and does add real context: the detail is attached to the order's record, the reply enumerates what is still missing, and card-rendering behavior is explained. It does not cover failure modes (e.g. invalid order_id) or whether repeated calls are additive, which keeps it from a 5.

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 opening clause front-loads the action well, but the description sprawls into repeated restatements of the same idea ("reports what is still needed" vs. "the reply says what the order still needs") and a tangled sentence about ask_next being for the customer regardless of the card. Several sentences could be tightened 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?

An output schema exists, yet the description still usefully signals that the response lists remaining requirements. Combined with the two-parameter, 100%-covered input schema, an agent has enough to call it correctly; the main omission is how it relates to the choice-oriented siblings.

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 baseline is 3, but the description goes beyond it by enumerating what belongs in context — answers to ask_next, corrections, whole paragraphs, including pick-from-card events — which clarifies semantics the schema only gestures at. The order_id side is left entirely to 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 states a specific verb and resource: it records new customer detail (an answer to ask_next, a correction, a paragraph) onto the order and reports what the order still needs. That is concrete and distinguishable from generic write tools, but it never names a sibling (choose_option, pick_choice, resume_order) to draw the boundary explicitly.

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?

"Call it each time the customer gives a new detail" gives a clear trigger condition, and the card/ask_next explanation tells the agent how button answers surface as messages. It stops short of stating when NOT to use it versus choose_option or pick_choice, which look like the closest alternatives.

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 concrete behavioral context: it is free to call ('it costs nothing'), repeatable, and prices are server-supplied ('cannot be passed in'). It also discloses the precondition that the artwork must pass print check. However, it does not explain why the annotation has readOnlyHint=false, leaving the non-read-only side effect unspecified.

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 core behavior and prerequisites, then moves to practical usage. Most sentences earn their place, though the picker-specific sentence is somewhat niche; overall it is efficient and well-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?

Given the tool has an output schema, the description need not explain return values. It covers prerequisites, how to use the returned options, repeat-call behavior, and cost, leaving no critical gap for an agent deciding how and when to invoke 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% and the single order_id parameter is already documented as coming from start_print_order. The description adds no parameter-specific meaning 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 states a specific verb and resource: 'Returns priced options with lead times'. It also names prerequisites ('order is fully described and the artwork has passed the print check'), which distinguishes this tool from siblings like describe_order or submit_artwork.

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 explicitly says when to call (after order description and print check), what to do with results (present to customer), and how to proceed (each option has an id for choose_option). It also covers repeated calls ('whenever the customer asks to see or reconsider') and alternative client behavior via the option picker.

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 readOnlyHint annotation already establishes safety. The description adds useful behavioral context beyond annotations by disclosing that the customer must be signed in and that the client will prompt sign-in if 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?

The description is three compact sentences with no wasted text. Purpose, authentication requirement, and usage triggers are front-loaded in a logical order.

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 an output schema, full parameter coverage, and read-only annotations, the definition provides enough context for correct invocation. It covers authentication and use cases, though it omits return-shape and pagination details that are already handled elsewhere.

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 enum for include is fully documented in the schema. The description does not add any syntax or filtering details beyond what the schema already provides, 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 states a specific verb and resource: it lists the signed-in customer's orders, including their statuses. This clearly separates it from order-detail or checkout tools, though it does not explicitly name a sibling tool for comparison.

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 scenarios: asking what they have, picking up a saved order, or checking order status. It does not state when not to use it or explicitly point to alternatives such as describe_order or resume_order.

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 declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context — the values must match the last reply exactly and the operation is tied to the ask_next choices set — but never says this mutates the order state or what happens on an invalid field/option pair.

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 and immediately followed by the routing condition; nothing is padding. The opening clause ('beside ask_next') is slightly awkward but does convey the dependency on the prior reply.

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?

All three parameters are documented by the schema, an output schema exists, and annotations cover safety, so the description only needs to add routing and matching semantics — which it does. The remaining gap is the unresolved overlap with choose_option and choose_style.

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 field enum is fully enumerated, so the schema does the heavy lifting. The description reinforces exact-match semantics ('by field and option, exactly as shown') but adds little syntax or format detail beyond what the parameter descriptions already state.

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 action ('Lands one of the choices the last reply offered') tied to a concrete resource: the choice set produced by ask_next, keyed by field and option. The scope is clear, but it never distinguishes itself from the close siblings choose_option and choose_style, which sound like they do the same thing.

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?

Explicitly says when to use it ('when the customer picks one of them') and routes free-form answers to describe_order instead. What's missing is guidance on when to use this versus choose_option/choose_style, the ambiguity an agent is most likely to hit.

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 readOnlyHint=true; the description adds the non-obvious multi-turn behavior: pictures are returned per style per color, a pick may arrive as a message in rendering clients, and otherwise the agent must call `choose_style` with style_id and color. That is real workflow context an agent could not infer from the annotation or schema.

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 sentences, front-loaded with what the tool does, then the comparison case, then the pick-handling branch. Every clause carries information; nothing is padding.

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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. With only two parameters and full schema coverage, the description supplies everything else an agent needs: when to call it, what it will not do, and what to do after the customer chooses.

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 schema already explains both `order_id` and the `colors` array, including the 1–4 range and the default when omitted. The description restates the four-color cap but adds no syntax or format detail beyond what the schema provides, 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 — shows the customer's design on the garment in other colors — plus the output granularity (one picture per offered style per color) and the hard cap of four colors. It explicitly contrasts with `describe_order`, so an agent can separate the two without opening either 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 an explicit trigger ('when the customer wants to compare colors or see one before deciding') and an explicit exclusion with the alternative named ('`describe_order` with a new color changes the order, this compares without changing anything'). It also covers the follow-up action after the customer picks.

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 say this is a non-read-only, idempotent, non-destructive write. The description adds what actually changes ('fresh window and fresh links'), what comes back ('returns where things stand'), and how to continue ('the call next_call names') — real context the annotations cannot carry.

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

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

Front-loaded with the triggering condition and dense with useful clauses. The closing 'Without a refusal there is nothing to resume' restates the precondition already established, which is mild redundancy, but the sentence does harden the guard against misuse.

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 mutation with a full output schema, everything an agent needs is present: the gating condition, the continuity behavior, the fresh-window side effect, and a pointer to next_call. Return values need not be explained given the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for a single parameter, so the schema already documents it. Credit goes to the description for tying the value to a specific provenance — it must be the order_id that the refusing tool rejected, not any arbitrary order.

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 ('Picks up an order that another tool refused as expired') and immediately separates itself from start_print_order. An agent can distinguish it from every sibling without opening the 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 an explicit precondition ('Applies only after that refusal, with the same order_id'), the intent condition ('customer wants to continue that order rather than start over'), and names the alternative for the other case ('start_print_order opens a new order'). When-to-use, when-not-to-use, and the alternative are all covered.

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 mark this as non-read-only, idempotent, and non-destructive, but the description adds important behavioral context: saved orders never expire, cross-conversation persistence, and the authentication flow including automatic sign-in prompting and retry. This is richer than the annotations alone.

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 compact and front-loaded, with three purposeful sentences covering persistence, authentication, and trigger conditions. No sentence is redundant or 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?

An output schema exists, so return values need not be explained. The description covers the essential behavioral context: persistence, authentication requirements, and usage triggers, making it complete for an agent to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single parameter order_id is already clearly documented in the schema as the ID returned by start_print_order. The description does not add further meaning about the parameter, so it meets the baseline for high schema coverage.

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 action and resource: saving the customer's order to their account. It also clarifies the key benefit that a saved order can be retrieved from any conversation and never expires, which distinguishes it from transient order operations like start_print_order or resume_order.

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 explicitly names when to use the tool: when a response's notes offer saving, or when the customer asks to save, come back later, or keep their order. It also covers the sign-in prerequisite and instructs the client to re-call after authentication.

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 write/non-destructive; the description adds real behavior beyond that: the first reply itself solicits design and garment in customer-facing wording, and the call returns order_id plus outstanding info. It does not say what happens if an open order already exists, which is the main undisclosed trait.

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 short sentences, front-loaded with the action, then usage, then calling convention, then return value. No sentence repeats the schema or wastes space.

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?

An output schema exists, yet the description still summarizes what comes back (order_id, what is still needed, next question), which is appropriate for an entry-point tool the agent will chain from. The missing piece is the already-have-an-order scenario and how it relates to resume_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%, so the schema already documents `context` fully. The description still adds practical guidance — 'a phrase or a paragraph is fine' — reinforcing that unstructured prose is acceptable without a token limit concern.

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: 'Opens a print order'. It implies entry-point status via 'Returns the order_id to use with every other tool', which indirectly differentiates it from siblings like describe_order or create_checkout, but it never names or contrasts any sibling explicitly.

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

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

Gives clear when-to-use ('when the customer wants a design printed on a garment') and an ordering constraint ('Call it before asking your own questions'). It omits when NOT to use it or what to do if an order already exists — a real gap given resume_order is a sibling.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false) it discloses that the call runs a print-quality check at the requested size and returns findings in inches with remediation advice, and that artwork can be replaced afterward — a useful reversibility signal supporting destructiveHint=false. It does not address failure modes, size limits, or what happens if the URL is unreachable.

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 main condition is front-loaded and every sentence is about correct invocation. However, the 'never ask the customer / give them artwork_upload_url instead' point is repeated twice, costing a sentence.

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 highest-risk failure (submitting a design the agent only saw in chat) and the validation answer, and an output schema handles return values. It omits the relationship between image_url and image_base64, which matters since order_id is the only required parameter.

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 defines image_url, image_base64, order_id and filename. The description reinforces the image_url precondition but never explains the image_url vs image_base64 choice or that neither is required by schema, so it adds only marginal meaning over the structured fields.

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 ('sends the design to be printed') plus the precondition (you hold a public https link to the original file). An agent can immediately tell this submits artwork, distinct from sibling tools like choose_option or start_print_order.

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 ('when you already hold a public https link'), explicit when-not ('never ask the customer for one', 'a design you only saw in the chat is not one you hold'), and names the alternative path (hand out artwork_upload_url). Nothing is left to inference.

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