Skip to main content
Glama

RoboTrunk

Update a checkout at the store

update_checkout
DestructiveIdempotent

Sends permitted buyer, address, line-item, context, discount or fulfilment changes to a checkout at a store. Use this when a checkout from create_checkout needs correction before handoff, and to send the buyer's email and full delivery address (from the person, in this conversation or saved in your app) if you did not send them on create_checkout, so the store prefills them and the total includes delivery. Not for paying or sending payment details. Outputs: the updated rail envelope and suggested_tools. Error recovery: buyer_identity_contact_method_required means the store needs the buyer's email, so send buyer.email from the person; BUDGET_EXCEEDED means the store's total, shipping and tax included, is over the ceiling the person approved: tell the person, then raise budget_ceiling_minor once they approve or call cancel_checkout; MERCHANT_REJECTED_INPUT means the store refused one field that errors[] names, so fix it and retry with a new key; IDEMPOTENCY_CONFLICT means use a fresh key for a changed request; INVALID_REQUEST names a body or header problem; INVALID_STATE means the checkout cannot change now, so call get_checkout, then create_checkout again if it ended; CHECKOUT_NOT_FOUND means the handle is unavailable, so call create_checkout again; continuation_not_found or RUN_AUTH_REQUIRED means send checkout_id exactly as an earlier answer returned it and, if you did, call create_checkout again; PAYMENT_INSTRUMENT_NOT_ACCEPTED means remove payment data and retry; any other error, including tool_layer_failure: retry once, then call submit_feedback. Next: get_checkout to read the new status, complete_checkout when it is ready_for_complete. Full guide: get_tool_guide or /agent/tools.json#update_checkout Example call: {"checkout_id":"ucp_transcend-dev-lab_abc123","buyer":{"email":"buyer@example.test"}}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
buyerNoBuyer details for the merchant, or null to leave them unchanged. Example: {"email": "<the person's email>"}: the <...> is the person's own address, never invented.
contextNoOptional merchant context, or null to leave it unchanged.
discountsNoDiscount codes for the merchant, or null to leave them unchanged.
line_itemsNoReplacement line items: the whole basket, every line the checkout should hold, up to 50 at a quantity of 1 to 100 each, all from this checkout's store; or null to leave the current set unchanged. Example: [{"product_id": "<product_id from search_catalog>", "variant_id": "<variant_id from the same result>", "quantity": 1}], the ids exactly as returned, never a page link.
checkout_idYesThe UCP checkout id from create_checkout or get_checkout.
idempotency_keyNoA printable ASCII key for safe retries, or null to generate one.
shipping_addressNoThe merchant shipping address, or null to leave it unchanged. Example: {"first_name": "<from the person>", "last_name": "<from the person>", "street_address": "<street>", "extended_address": "<apartment or suite, or null>", "address_locality": "<city>", "address_region": "<two-letter state code, such as CA>", "postal_code": "<ZIP code>", "address_country": "US"}: every <...> is the person's own value, never invented.
shopping_session_idNoOptional server-issued shopping session correlation ID. It is not purchase authority.
budget_ceiling_minorNoThe total the person approved, shipping and tax included, in minor units, or null. A store total above it is refused BUDGET_EXCEEDED; ask the person. Example: 24995 for a total of 249.95.
fulfillment_option_idNoThe selected fulfillment option id, or null.
budget_ceiling_currencyNoThe ISO-4217 currency of the ceiling, or null for the merchant's own. Any other is refused, naming the merchant's.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

With destructiveHint=true and idempotentHint=true already declared, the description adds real context: the error taxonomy, the fresh-key rule on IDEMPOTENCY_CONFLICT, the budget ceiling enforcement, and the prefill rationale for buyer/address. It does not disclose that line_items replaces the entire basket (destructive semantics) — that only appears in the schema — but the annotation coverage keeps the bar low enough for a 4.

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-loaded with purpose, then usage, outputs, error recovery, next steps, and a concrete example call. The error-recovery block is dense and long, but each entry maps to a distinct, actionable failure mode, so it earns its space rather than padding.

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?

Despite having no output schema, the description names the outputs (updated rail envelope and suggested_tools), enumerates recovery paths for every named error code, states next steps, and provides an example call. Nothing an agent needs to invoke it correctly 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 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains why buyer.email and the full delivery address should be sent (so the store prefills and the total includes delivery) and ties budget_ceiling_minor to the BUDGET_EXCEEDED behavior and the need for explicit approval.

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?

The first sentence states a specific verb (sends changes) and resource (a checkout at a store), and the description explicitly distinguishes itself from create_checkout, get_checkout, complete_checkout, and cancel_checkout. An agent can tell exactly what this tool mutates 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?

It gives explicit when-to-use (a checkout from create_checkout needs correction before handoff, or the buyer email/address was omitted at creation) and when-not-to-use ('Not for paying or sending payment details'). It also routes forward with 'Next: get_checkout ... complete_checkout when it is ready_for_complete', naming the alternatives.

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