Skip to main content
Glama

RushOrderTees

Get the payment link

create_checkout
Idempotent

Returns the payment link for a fully specified order with a chosen option. Show checkout_url to the customer as a link labeled "Pay and enter shipping": they see their artwork and total, confirm their email address with a code we send them, then pay and enter their shipping address. Nothing is ordered until they pay. Refuses, and says what is missing, if the order is not ready. When the customer is signed in, asking to pay also saves the order to their account, so it stops expiring.

Input Schema

NameRequiredDescriptionDefault
order_idYesThe order_id returned by start_print_order.

Output Schema

NameRequiredDescriptionDefault
specYesThe print as the customer has described it so far, beside garment. Null where they have not said; still_needed lists what is missing.
notesYesRelay these to the customer.
savedYesWhether the order is saved to a customer account (save_progress).
statusYes
artworkNo
choicesNoAnswers 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.
garmentNoThe garment on the order, and what mockup_url shows. Name it when you show the picture; when it is provisional, say so.
optionsNo
ask_nextNoAsk the customer this, in your own words, and send the answer to describe_order.
order_idYes
next_callYesWhat to call next, and why.
expires_atNoWhen an unsaved order expires; null once it is saved to an account or paid.
mockup_urlNoThe 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.
alternativesNoPresent 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_urlNoShow 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_viewsNoEvery 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_neededYesFields the customer has not told us yet, and any go-ahead we are waiting on for something the order cannot carry.
chosen_optionNo
artwork_upload_urlNoPresent 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.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources