Skip to main content
Glama

RoboTrunk

Read a checkout at the store

get_checkout
Read-onlyIdempotent

Reads the current state of a checkout at a store, by checkout_id. Use this when you need the latest merchant status after creation, update or payment at the store. Not for the demo checkout's id (merchant null); read that one with get_order. Outputs: resource, status, next_actions and suggested_tools. A status of requires_escalation, or the message store_checkout_step, means the store needs a step finished on its own checkout page: call complete_checkout; its link opens that page, and the step is finished there before paying, by the person or by you. With click_and_collect_on_store_page, keep this checkout's link to collect: the choice is on that page; send the person there, not to the store's website separately. Error recovery: buyer_identity_contact_method_required means send buyer.email from the person with update_checkout; NOT_A_RAIL_CHECKOUT means the id is not a ucp_ checkout, so call create_checkout with a merchant; continuation_not_found means that reference is unknown, expired (they last up to 24 hours) or from another environment, so call create_checkout again; RUN_AUTH_REQUIRED means checkout_id was not the reference an earlier answer returned, or the 24-hour run behind it has ended, so send it back exactly as given and, if you did, call create_checkout again; CHECKOUT_NOT_FOUND means that checkout cannot be read, so never guess an id; RATE_LIMITED means wait and retry; SERVICE_UNAVAILABLE or a store error (UCP_MERCHANT_BUSY, UCP_MERCHANT_UNAVAILABLE) means retry shortly; any other error, including tool_layer_failure: retry once, then call submit_feedback. Next: update_checkout while the status asks for details, complete_checkout when it is ready_for_complete. Full guide: get_tool_guide or /agent/tools.json#get_checkout Example call: {"checkout_id":"ucp_transcend-dev-lab_abc123"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
checkout_idYesThe checkout handle an earlier UCP checkout tool returned as resource.id. Pass it back exactly as given.
shopping_session_idNoOptional server-issued shopping session correlation ID. It is not purchase authority.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), yet the description adds substantial behavior: the returned fields, the 24-hour expiry of references, rate-limit and service-unavailable retry semantics, and a full error-code-to-remediation table. This is well beyond what structured fields convey.

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 key get_order exclusion are front-loaded, and every clause carries actionable content, but the error-recovery material is compressed into a single dense run-on paragraph that is harder to scan than it needs to be.

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 no output schema, the description compensates by naming the returned fields (resource, status, next_actions, suggested_tools) and covering the status states, escalation path, and error recovery, leaving nothing an agent needs 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 by tying checkout_id to an earlier tool's resource.id, emphasizing it must be returned exactly as given, and explaining that RUN_AUTH_REQUIRED signals a stale reference or expired 24-hour run.

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 ('Reads the current state of a checkout at a store, by checkout_id') and explicitly distinguishes itself from the sibling get_order for the demo checkout. An agent can tell what this returns 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?

Gives explicit when-to-use ('after creation, update or payment at the store'), a when-not ('Not for the demo checkout's id ... read that one with get_order'), and downstream routing ('update_checkout while the status asks for details, complete_checkout when it is ready_for_complete').

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