Skip to main content
Glama

Rendreal

Place the order

order_create
Destructive

Create an order from the session cart (starts unpaid — PENDING_ARTWORK or PENDING_PAYMENT depending on the server).

For a one-line cart, pass that line's offer_id alone. For a cart with several lines, pass selections=[{line_id, offer_id}, ...], one per line, to order them together as one order with one item per line; a bare offer_id against such a cart is rejected (MultiLineCartError) rather than silently ordering just one line. Each item re-sends the sku + configuration its quote priced and binds the chosen offer; the server recomputes price, so no money is sent. Every offer_id must belong to the cart (OfferNotFoundError / LineNotFoundError otherwise — re-run order_get_quote). If RendReal refuses the chosen offer, the job fails with OfferRefusedError and no order is placed: quote again and let the customer choose. If RendReal refuses the order itself, the job fails with OrderRefusedError: the refusal is permanent, so offer a change to the setup or customer support, never a retry.

Shipping and tax are filled by Stripe at checkout. Attach artwork per line: with selections, set each entry's design_id + design_snapshot_id; with a bare offer_id, pass the top-level design_id + design_snapshot_id. Both ids are required for a design to attach, and the snapshot must be the owned design's latest. Every line needs artwork — a design, or a finished artwork file uploaded via order_get_artwork_upload_page — before the order can be paid (order_create_payment_link enforces it).

A line already ordered in this session is refused (LineAlreadyOrderedError) before any upstream order is placed, so the same still-quoted line can't be bought twice; order_view_cart marks such a line already_ordered=true. Start a new line to buy it again.

If catalog_configure_product reported an Unmet Constraint for any selected line, the order is refused (UnmetConstraintUnansweredError; detail.lines lists every such line with its asks in unmet) until the customer answers for each listed line. Tell the customer, per line, what they asked for and what the option accepts. If they accept every listed line as configured, call again with unmet_accepted=true, which orders all the selected lines. If they want a change on any line, call catalog_configure_product with their answer for that line instead.

Returns a job — poll until SUCCEEDED for the order_id and each line's item_id. Then get any missing artwork: design it against the order, or have the customer upload a finished file. Call order_create_payment_link only when the customer asks to pay. An item with designable: false cannot be designed here: for that item offer only the upload of a finished print file, never a design.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>"
    },
    "name": "order_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
offer_idNo
design_idNo
selectionsNo
session_idYes
unmet_acceptedNo
design_snapshot_idNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description adds substantial context beyond them: the server recomputes price so no money is sent, OrderRefusedError is permanent and must never be retried, LineAlreadyOrderedError blocks re-buying a still-quoted line, and unsatisfied constraints refuse the order until `unmet_accepted=true`. It also discloses that a job is returned and must be polled — rich behavioral detail 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.

Conciseness4/5

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

Roughly 400 words, but nearly every sentence encodes a distinct rule or failure mode and the purpose is front-loaded in the first line. Some error-handling passages (e.g., the RendReal refusal explanations) could be tightened without losing meaning, but the length is largely justified by the branching logic.

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?

For a destructive, non-idempotent mutation with six parameters and zero schema description coverage, the description covers inputs, failure modes, retry policy, artwork prerequisites, and the post-call job-polling workflow. With an output schema present it need not detail return fields, and it does not overreach.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains the mutual exclusivity of `offer_id` vs `selections`, the per-entry `line_id`/`offer_id`/`design_id`/`design_snapshot_id` structure, the requirement that both design ids be present and the snapshot be the latest, and the meaning of `unmet_accepted`. Only `session_id` goes unmentioned, which is minor.

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?

Opens with a specific verb and resource — create an order from the session cart — and immediately states the resulting unpaid state (PENDING_ARTWORK / PENDING_PAYMENT), which distinguishes it from the payment-link and quote siblings. An agent can tell what this does and what it does not do 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 Guidelines5/5

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

Explicit branching guidance: bare `offer_id` for a one-line cart, `selections=[{line_id, offer_id}]` for multi-line carts, with the note that a bare offer_id is rejected on a multi-line cart. It also routes to `order_get_quote` for re-quoting, `catalog_configure_product` on unmet constraints, and `order_create_payment_link` only when the customer asks to pay — alternatives and conditions are named, not inferred.

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