Skip to main content
Glama

RoboTrunk

Price a checkout at the store

create_checkout
Idempotent

Prepares a checkout at a named store and returns its envelope. merchant is the store slug search_catalog returned (required). Use when asked to buy, purchase or order. One checkout per store, all its products in line_items, each at the quantity the person wants (1 to 100); products from two stores make two checkouts; send the delivery address and the buyer's email (from the person, here or saved in your app) on this call, so the store prefills them and the first total includes delivery. Set budget_ceiling_minor here to the highest total, shipping and tax included, the person approved. Not for placing the order; complete_checkout issues the store link: the person taps it in their own browser, or you open it and complete the store's checkout. Next: if the store still asks for a detail, send what the person gives with update_checkout; read progress any time with get_checkout; when the status is ready_for_complete call complete_checkout. Error recovery: buyer_identity_contact_method_required means send buyer.email from the person with update_checkout; BUDGET_EXCEEDED means the store's total, shipping and tax included, is over budget_ceiling_minor: tell the person the total, then raise the ceiling with update_checkout once they approve, or call cancel_checkout (the checkout still exists); MERCHANT_REJECTED_INPUT names the field the store refused, so fix it and retry with a new idempotency_key; invalid_request names the field to fix; address_not_accepted means you left out merchant or sent null, so this ran RoboTrunk's test demo: add the store's merchant slug and call again; MERCHANT_NOT_FOUND means that store is not offered, so call search_catalog; out_of_stock means tell the person and call search_catalog; quote_expired or checkout_expired_or_invalid_state means call create_checkout again; idempotency_conflict means retry with a new idempotency_key or null; rate_limited means wait 60 seconds; price_not_fresh means retry in a minute; network_error means call again; UCP_MERCHANT_BUSY, UCP_MERCHANT_UNAVAILABLE or UCP_MERCHANT_REFUSED means try again shortly; payment_unavailable means call submit_feedback; any other error, including tool_layer_failure: retry once, then call submit_feedback. An explicit merchant: null runs RoboTrunk's test demo instead (one item, one test address, nothing charged). Full guide: get_tool_guide or /agent/tools.json#create_checkout Example call: {"merchant":"merchant-from-result","line_items":[{"product_id":"product-id-from-result","variant_id":"variant-id-from-result","quantity":2},{"product_id":"product-id-2-from-result","variant_id":"variant-id-2-from-result","quantity":1}],"buyer_country":"US","shipping_address":{"first_name":"first-name-from-person","last_name":"last-name-from-person","street_address":"street-from-person","address_locality":"city-from-person","address_region":"state-from-person","postal_code":"zip-code-from-person","address_country":"US"},"buyer":{"email":"email-from-person@example.com"}}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
buyerNoBuyer fields for the named merchant, including the email it requires, or null. Example: {"email": "<the person's email>"}: the <...> is the person's own address, never invented.
contextNoOptional merchant context such as destination or language, or null. The currency is the merchant's own and is never taken from a caller.
merchantYesThe store slug search_catalog returned with the product. Required: a call without it is refused. Only an explicit null runs RoboTrunk's one-product test demo, which sells nothing.
discountsNoDiscount codes for the store, or null.
line_itemsYesFor a store: one line per product, up to 50, quantity 1 to 100 each; the store has the final say on stock. For the RoboTrunk demo (merchant null): exactly one line at quantity 1. Example: [{"product_id": "<product_id from search_catalog>", "variant_id": "<variant_id from the same result>", "quantity": 2}], the ids exactly as returned, never a page link.
buyer_countryNoShopper's ISO country: what you know, else your best guess; unknown if none. Left out, it is read as unknown and the answer asks you to send it. Example: "AU", "US" or "unknown", never a country name.unknown
idempotency_keyNo16 to 128 printable ASCII characters, or null to have the tool generate one. Each internal step gets its own suffixed key, so a repeat is safe.
shipping_addressNoThe person's shipping address, or null. 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.
buyer_country_basisNoOptional, with buyer_country: known if you know the country, guessed if it is your best guess. Null if neither.
shopping_session_idNoOptional server-issued shopping session correlation ID. It is not purchase authority.
budget_ceiling_centsNoDemo only (merchant null); ignored at a store, so use budget_ceiling_minor there. Null otherwise.
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.
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.7/5.0
Behavior5/5

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

Annotations declare the safety profile (idempotent, open-world, non-read-only), and the description goes well beyond them: one checkout per store, the idempotency-key/suffix behaviour that makes retries safe, the budget-ceiling refusal path, the demo mode triggered by explicit merchant:null, and a full error taxonomy with recovery actions. That is substantial added behaviour an agent cannot get from 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.

Conciseness3/5

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

The purpose and routing are front-loaded, but the body is a single dense block that mixes usage, sequencing, a long error-code dictionary, and a full example call that duplicates the schema's own example. Most sentences carry weight, yet structure is poor and the duplicated example call does not earn its space.

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?

With 13 parameters, no output schema, and an open-world, likely-mutating operation, the description still covers prerequisites (merchant slug, address, email), limits (quantity 1–100, 50 lines, one store per checkout), the budget gate, the demo fallback, and a next-step/error-recovery map. Nothing essential for a correct call 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 description coverage is 100%, so a baseline of 3 is warranted, but the description adds real meaning: merchant must be the slug search_catalog returned, the delivery address and buyer email belong on this call so the first total includes delivery, and budget_ceiling_minor is the approved all-in total in minor units. Minor overlap with the schema examples keeps it from a 5.

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 ('Prepares a checkout at a named store and returns its envelope') and immediately scopes the boundary: it is not the tool that places the order. An agent can distinguish it from complete_checkout, update_checkout and get_checkout without opening any 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 trigger ('Use when asked to buy, purchase or order'), an explicit exclusion ('Not for placing the order; complete_checkout issues the store link'), a named handoff sequence (update_checkout, get_checkout, complete_checkout), and named alternatives in cancel_checkout and search_catalog. This is about as complete as usage routing gets.

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