RushOrderTees

Describe the order

describe_order

Records more about what the customer wants — an answer to ask_next, a correction, or a whole paragraph — and reports what is still needed. Call it each time the customer gives a new detail. In clients that render our order card the customer sees the order so far and the question in ask_next with its choices as buttons; when several styles fit it shows them too. An answer or a pick made there arrives as a message; the question in ask_next is for the customer whether or not the card shows. Also records a decision about the order: a stop, an objection to the price or the date, or a request we do not offer. It belongs to the order's record, and the reply says what the order still needs.

Input Schema

Name	Required	Description	Default
`context`	Yes	What the customer said, in their own words. Garment, color, size, quantity, print width in inches, placement, deadline — whatever is new. Unstructured prose is fine.
`order_id`	Yes	The order_id returned by start_print_order.

Output Schema

Name	Required	Description
`spec`	Yes	The print as the customer has described it so far, beside garment. Null where they have not said; still_needed lists what is missing.
`notes`	Yes	Relay these to the customer.
`saved`	Yes	Whether the order is saved to a customer account (save_progress).
`status`	Yes
`artwork`	No
`choices`	No	Answers the customer can pick from, one set per field ask_next asks about. Offer them as selectable options where your client can, otherwise as a short list. They are suggestions: colors are families and the customer may name any shade, quantity and width may be any number. Send whatever they answer to describe_order.
`garment`	No	The garment on the order, and what mockup_url shows. Name it when you show the picture; when it is provisional, say so.
`options`	No
`ask_next`	No	Ask the customer this, in your own words, and send the answer to describe_order.
`order_id`	Yes
`next_call`	Yes	What to call next, and why.
`expires_at`	No	When an unsaved order expires; null once it is saved to an account or paid.
`mockup_url`	No	The garment on the order, in the customer's color, with their design on it once we have it. An image address: show it as a picture where your client can, never as text or as a link, and never describe it in place of the summary.
`alternatives`	No	Present from the moment several styles fit until the customer picks, beside whatever ask_next asks: show all of them with their summaries and prices, say the first is what we will use unless they choose, and call choose_style with the id they pick (or send "any" to describe_order to keep the first).
`checkout_url`	No	Show it to the customer as one link labeled "Pay and enter shipping", not as a bare address: they see the artwork and total, confirm their email with a code we send them, then pay and enter their address there.
`mockup_views`	No	Every side of the garment, the printed one first: mockup_url with the design, then the other sides plain. Where your client can show pictures, show them all, so the customer sees which sides stay blank.
`still_needed`	Yes	Fields the customer has not told us yet, and any go-ahead we are waiting on for something the order cannot carry.
`chosen_option`	No
`artwork_upload_url`	No	Present until the design is accepted. Show it to the customer as one link labeled "Upload your design", not as a bare address: they drop their design file on that page and it is checked there. You cannot upload for them.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A3.9/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All RushOrderTees tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?