Skip to main content
Glama

Rendreal

Cancel an order

order_cancel
DestructiveIdempotent

Cancel an order this session created, or a paid order from another conversation, while RendReal still allows it.

Irreversible — the order and any artwork work on it are gone. An order is cancelled whole: there is no per-item cancel, so when the customer names one product of an order with several items, tell them the cancel ends every item in it. Call it as soon as the customer asks to cancel: an unpaid order is cancelled on that call when Compass reads their customer_words as a request to cancel it. Any other call, such as for a paid order or on words that ask for something else, takes two calls: the first fails with OrderCancelConfirmationRequiredError and sends nothing. Then quote the order's reference_id back to the customer and wait for a clear yes. Only after they agree, call again with confirmed=true and the brief cancellation question plus their exact answer in customer_words. confirmed=true on a call Compass has not refused yet, or with no new customer words since the refusal, is refused the same way. customer_words is an exact quote of only the customer's request to cancel this order on the first call. On the confirming call, include only the brief cancellation question and the customer's exact answer, even if they repeat the same words, such as "yes". Exclude the rest of their message and all conversation history. Never paraphrase. Never cancel on a hint, and never pick the order yourself when the session has several — ask.

For an order this session created, pass its order_id. For an order from another conversation, pass instead the reference_id and email the customer gives you — the order reference and the email it was paid with, exactly as typed, never guessed — on both calls. ForeignOrderNotFoundError means the pair matched no order: ask them to re-check both. Only a paid order from another conversation can be cancelled here: ForeignOrderNotPaidError means it is unpaid; give the customer its reason as written. A foreign order_id alone fails with OrderNotInSessionError and no upstream call. RendReal decides what is cancellable: an unpaid order, or a paid order in the short window after payment, before production starts. A refusal (OrderNotCancellableError) means production has started and no retry will help: tell the customer and offer customer support. After a confirmed cancel, read refund: for refunded, tell the customer the payment is refunded to the card they paid with; for requested, give them refund_note as written; for none, say nothing about a refund. Promise no timing for a refund, and never tell the customer they were not charged.

Returns a job — poll until SUCCEEDED. status is the order's live status after the cancel, read back from RendReal: only CANCELLED there means it is cancelled. already_cancelled: true means it was cancelled before this call and nothing was sent. OrderCancelNotConfirmedError means RendReal accepted the request but the order has not changed state yet — say the request went through but is unconfirmed, and re-check with order_get on the customer's next message. OrderCancelOutcomeUnknownError means the request reached RendReal but its outcome could not be confirmed: say neither that it is cancelled nor that nothing changed; say you could not confirm it, and check order_get on their next message; for an order from another conversation, re-check with order_lookup instead. After a confirmed cancel the cart line the order came from is orderable again.

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>",
      "customer_words": "<customer_words>"
    },
    "name": "order_cancel"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailNo
order_idNo
confirmedNo
session_idYes
reference_idNo
customer_wordsYesExact customer cancellation request on the first call. On the confirming call, include only the brief cancellation question and the customer's exact answer. Exclude unrelated message text and conversation history.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive and idempotent, but the description goes far beyond them: it discloses irreversibility ('the order and any artwork work on it are gone'), the whole-order rule, RendReal's cancellability window, refund outcome handling per refund value, job polling, and post-cancel cart restocking. Each error class is mapped to a distinct agent behavior, and there is no contradiction with 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.

Conciseness4/5

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

Purpose and the irreversible warning are front-loaded, and nearly every sentence carries operational consequences rather than filler. It is nonetheless very long and dense for a six-parameter tool, with the error/refund guidance running together in a single block that is harder to scan than its content warrants.

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?

Even though an output schema exists, the description explains the return fields the agent must act on — status, refund/refund_note, already_cancelled — plus the confirmation and outcome-unknown error paths. Nothing needed to call this correctly, or to behave correctly after it, is missing.

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 only 17%, so the description must carry the load, and it does for the ambiguous parameters: it explains the order_id-versus-reference_id+email choice, that the pair must be 'exactly as typed, never guessed' on both calls, the meaning of confirmed, and the precise quoting rules for customer_words. Only session_id is left implicit, which holds it back from a top mark.

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 and resource and immediately scopes it: 'Cancel an order this session created, or a paid order from another conversation.' It further distinguishes whole-order cancellation from per-item removal, so the agent can tell this apart from order_remove_line or order_get without opening their schemas.

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?

Gives explicit when-to-use ('Call it as soon as the customer asks to cancel'), when-not ('never cancel on a hint', 'never pick the order yourself when the session has several — ask'), and alternatives for follow-up (order_get, and order_lookup for another conversation's order). The two-call confirmation protocol is spelled out, including what a premature confirmed=true does.

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