Agentic commerce gateway: discovery, search, checkout across Shopify/Woo/Odoo/PrestaShop with UCP, ACP, AP2, X402. Checkout rules for agents, and trust receipts.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 27 tools
Descriptions go to unusual lengths to separate near-pairs: quote_checkout vs preview_checkout, get_checkout_state vs ucp_get_checkout, and the standard vs ucp_* flows all carry explicit 'use ONLY for' guidance. Residual overlap remains (search_products vs search_products_enriched, complete_checkout vs ucp_complete_checkout, get_store_trust vs get_merchant_profile) but is mitigated by text.
Nearly everything follows verb_noun snake_case (create_cart, get_shipping_rates, verify_trust_receipt), and the ucp_ prefix is applied uniformly to the alternate protocol. Minor deviations only: browse_categories instead of list_categories, and slightly asymmetric get_store_trust vs get_merchant_profile.
27 tools is heavy for a store checkout surface, and the count is inflated by two parallel checkout stacks (create_cart/preview/complete plus six ucp_* equivalents). Each individual tool is defensible, but the duplicated flows push it well past a well-scoped set.
Catalog search, detail, comparison, cart, shipping, discounts, checkout, receipts and trust verification are all covered. Gaps: no cancel/clear for standard carts (only ucp_cancel_checkout exists), and no order history, order lookup or return/refund operations, which are dead ends for post-purchase workflows.
Apply a discount or promo code to the cart. Checkout guide: read the MCP resource trusteed://guides/checkout. CREDENTIAL: this store needs one. Call the create_sandbox_key tool first (it is in this tool list and needs no credential), then pass the key you get back as the agent_key argument — or as an Authorization: Bearer header if your client can set headers. Do not ask a person to log in: there is no human login for this store.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Set to 'ucp_identity' to apply a loyalty discount derived from a UCP identity token instead of a promo code. | |
| cart_id | Yes | Cart session ID | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| discount_code | No | Discount or promo code to apply (required unless source is ucp_identity) | |
| identity_token | No | UCP identity bearer token (required when source is ucp_identity). | |
| idempotency_key | No | REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta["trusteed/idempotency-key"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation. |
| Name | Required | Description |
|---|---|---|
| cart_id | Yes | |
| currency | Yes | |
| discount_code | Yes | |
| discount_cents | Yes | |
| new_total_cents | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, idempotent=true, and destructive=false, so the safety profile is covered. The description adds genuinely useful operational context beyond that: the credential requirement, the absence of human login, and the two ways to supply the key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, followed by credential mechanics. It is slightly verbose on the credential workflow, but every sentence carries actionable information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety semantics, an output schema handling return values, and full schema description coverage, the description's remaining job is the credential/auth workflow, which it explains thoroughly. It is complete enough for an agent to invoke the tool correctly without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents cart_id, agent_key, discount_code, identity_token, source, and idempotency_key in detail. The description largely restates the agent_key mechanism rather than adding format or constraint detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb and resource: 'Apply a discount or promo code to the cart.' It is unambiguous what operation is performed, though it does not explicitly distinguish itself from cart-mutation siblings like the checkout tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite chain (call create_sandbox_key first, then pass the key as agent_key or an Authorization header) and points to the checkout guide resource. It does not, however, state when to prefer this tool over alternatives or any conditions under which it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all product categories in Demo Store with product counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds one behavioral detail beyond that — that results carry product counts — but omits return shape, whether the list is flat or hierarchical, and any pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the resource and the payload ('with product counts') front-loaded and zero filler. Nothing here is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, fully annotated read tool this is nearly sufficient, and with no output schema the 'product counts' mention partially covers the return value. The only real gap is whether the output is a flat list or a category tree, which an agent might want to know before rendering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing for the description to clarify; per convention the baseline is 4. The description correctly implies the call needs no input to enumerate all categories.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('product categories') scoped to Demo Store, and adds that product counts are included. It is clearly distinguishable from sibling search tools like search_products, though it does not explicitly name an alternative to route away from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus search_products or search_products_enriched, and no prerequisites or exclusions. The browsing intent is only implied by the word 'browse' in the name, not by the description text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2 to 5 products side-by-side with normalized attribute table and best-value recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| product_ids | Yes | Array of product IDs to compare (2-5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful context beyond them by disclosing what the tool produces: a normalized attribute table and a best-value recommendation, which is meaningful since no output schema exists. It does not mention error behavior for invalid or unavailable IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, with the constraint and output description packed in without filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description compensates well by summarizing the return structure and the recommendation behavior, while annotations carry the safety profile. Missing only edge-case handling (invalid IDs, fewer than two valid products), which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter and schema description coverage is 100%, with minItems/maxItems enforcing the same 2-5 range the description states. The description therefore adds no semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compare) and resource (products) plus the operational scope (2 to 5) and the shape of the result (normalized attribute table, best-value recommendation). It is easy to distinguish from get_product_details or search_products in spirit, but it never names a sibling or explicitly contrasts with them, so it falls short of the 5 tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 2-5 constraint and 'side-by-side' framing imply the usage context (multi-product evaluation), but there is no explicit when-to-use statement, no when-not-to-use, and no named alternative such as search_products or get_product_details. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete the purchase. Provide buyer.name and buyer.email from the conversation before opening approval; ask in chat if either is missing. The approval page only reviews these details. PREFER THE CART CARD: if there is an interactive card for this cart, let the buyer confirm and (when the store offers a choice) pick the payment method there — including retrying after a declined payment or switching method — instead of calling this tool yourself. Each call you make here opens a new card in the transcript instead of updating the one already open. Only call it yourself when there is no interactive card or the buyer explicitly asks you to complete it in chat. Idempotent — replay is keyed on checkout_session_id: any retry against a session that already has an order returns that same order (COMPLETED or PENDING_EXTERNAL_CONFIRMATION) without re-charging. The provided idempotency_key is recorded on the session for audit and short-circuits a repeated call with the same key.
If the response has status PENDING_EXTERNAL_CONFIRMATION, no purchase has completed yet: read order_placed and next_action — a person has to approve or pay at its url; next_action says whether calling again with the same checkout_session_id and idempotency_key can read the outcome. KYAPAY (payment_method=KYAPAY or a kyapay_token): charging with KYApay is not available. KYApay is identity verification here, not a payment rail, so the call is rejected with PAYMENT_METHOD_NOT_CONFIGURED before anything is charged or written; use another payment method. The Skyfire KYA token serves identity on the REST API, not payment in this tool. On demo-store the approval step records a confirmation but does not verify that a human gave it. PAYMENT MANDATE: this tool also requires one, issued by the platform, not written by you. Call preview_checkout for this cart, open the approval_url it returns, poll approval_status_url with your agent credential, and send the mandate you receive as the payment_mandate argument or an X-Payment-Mandate header. The approval is bound to your agent credential and the cart; it does not verify that a person was present. Checkout guide: read the MCP resource trusteed://guides/checkout. CREDENTIAL: this store needs one. Call the create_sandbox_key tool first (it is in this tool list and needs no credential), then pass the key you get back as the agent_key argument — or as an Authorization: Bearer header if your client can set headers. Do not ask a person to log in: there is no human login for this store.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer | No | Optional buyer contact information | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| cel_context | No | Optional. Send only evidence you can substantiate; it can only make a check stricter, never looser. Unknown keys or out-of-range values are rejected with INVALID_ARGUMENT. Keys: key_age_hours, requested_scopes, product_categories, price_delta_bps, discount_codes_tried, discount_bps, lowest_stock, return_policy_mismatch, is_subscription, autorenew_consent, is_b2b, purchase_order_hash, shipping_po_box, shipping_freight_forwarder, provider_confidence, stored_value_cents, cross_merchant_abuse, refund_ratio, dispute_count, completed_orders_24h, merchant_orders_1h, digital_good_types, agent_provider_id. | |
| kyapay_token | No | Not available for payment: charging with KYApay is switched off, because KYApay is identity verification here, not a payment rail. A call that passes this token is rejected with PAYMENT_METHOD_NOT_CONFIGURED before anything is charged or written. The Skyfire KYA token is used for identity on the REST API, not in this tool. | |
| payment_method | No | Payment method to use. PAYPAL creates a PayPal order and presents approval URL. KYAPAY is not available for payment: KYApay is identity verification here, so a request with KYAPAY is rejected without charging anything. ACP (Stripe-native settlement) returns a 'not enabled' response unless this deployment enables native settlement; when enabled it charges the Stripe Shared Payment Token passed as shared_payment_token. X402 is available through the configured x402 protocol flow, not this checkout tool. MOCK moves no money: it completes the order without charging. Whether a store accepts it depends on the store's configuration (it is the default on demo-store). Defaults to MOCK if not specified. | |
| payment_option | No | Payment method THE PERSON chose, when preview_checkout returned payment_options. Ask the person; never choose for them. Card numbers and wallet keys are never sent here: the person approves (and, with own_wallet, signs) on the approval page. | |
| idempotency_key | Yes | REQUIRED as an argument in this tool: the `Idempotency-Key` header or `_meta` alone is not enough. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation. | |
| payment_mandate | No | Payment mandate issued by the platform for this cart: the compact JWS you receive after the approval opened by `preview_checkout` is granted (its `exp` is Unix seconds and `aud` is this store's slug). Forward it as received; a mandate you write yourself is not accepted here. The approval is bound to your agent credential and does not verify that a person was present. Use this when your client cannot set an `X-Payment-Mandate` header. | |
| checkout_session_id | Yes | Checkout session ID from preview_checkout — the same value as create_cart's cart_id (must be a valid UUID) | |
| save_payment_method | No | Only with PayPal at a store that charges into its own PayPal account, for a signed-in buyer (not guest access), and only when the person asked for it: true asks PayPal to save this PayPal account during this purchase, so later purchases at this store can be charged without a new approval, within per-charge and daily limits. Never set it on your own initiative. In any other case it is ignored and the response says so in details; it never causes an error. | |
| shared_payment_token | No | Stripe Shared Payment Token (spt_…) granted by the buyer's agent wallet for payment_method=ACP. Issued by Stripe, scoped to this merchant, amount and currency, and consumed when used: it can be charged once. Only honoured when this deployment enables native ACP settlement. | |
| reconfirmed_state_hash | No | SHA-256 of the authoritative merchant state, as returned in details.reconfirm_state_hash by a previous STATE_RECONFIRMATION_REQUIRED error. Required to proceed when the merchant state moved after the approved preview. Passing a stale hash is refused: it means the state moved again and must be reconfirmed anew. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| details | No | |
| currency | Yes | |
| order_id | Yes | |
| idempotent | Yes | |
| store_name | Yes | |
| test_funds | No | |
| money_moves | No | |
| next_action | No | |
| payment_url | No | |
| total_cents | Yes | |
| approval_url | No | |
| order_placed | No | |
| funding_source | No | |
| payment_method | No | |
| shipping_source | No | |
| payment_captured | No | |
| external_order_id | No | |
| checkout_session_id | Yes | |
| shipping_authoritative | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety/idempotency hints, but the description adds far more: idempotency keyed on checkout_session_id, PENDING_EXTERNAL_CONFIRMATION semantics, KYAPAY being rejected before any charge, the platform-issued payment mandate workflow, the sandbox credential requirement, and the demo-store non-verification caveat. Consistent with idempotentHint=true and readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite inline section labels (KYAPAY:, PAYMENT MANDATE:, CREDENTIAL:), it is one dense monolithic block and repeats schema-documented facts about KYAPAY, the mandate, and the credential. Most content is load-bearing for a checkout tool with this many branches, but there is measurable redundancy and no clean paragraph breaks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, yet the description still explains the PENDING_EXTERNAL_CONFIRMATION read path (order_placed, next_action). Combined with credential, mandate, and idempotency guidance, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning for parameters beyond the schema: it clarifies that payment_mandate must be platform-issued (not authored by the agent), that agent_key comes from create_sandbox_key, and the checkout_session_id/idempotency_key retry contract. It duplicates some KYAPAY detail already in the schema, keeping it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Complete the purchase' names a specific verb and resource, and the body distinguishes it from siblings like preview_checkout and the cart card path. An agent can tell immediately what this tool does and when it is the wrong entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when/when-not routing: 'PREFER THE CART CARD... Only call it yourself when there is no interactive card or the buyer explicitly asks.' It names the alternatives (cart card, preview_checkout, create_sandbox_key) and the exact conditions selecting each, including retry-after-decline handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a shopping cart in Demo Store. Returns a cart_id. Pass it as cart_id to get_shipping_rates, select_shipping_option, apply_discount and preview_checkout; complete_checkout and get_trust_receipt take the same value as checkout_session_id.
KYA IDENTITY: a Skyfire kya token has no effect on this tool (it grants no trust boost here); KYA identity applies to the REST agent API (Authorization: Bearer), not to the MCP tools. Checkout guide: read the MCP resource trusteed://guides/checkout. CREDENTIAL: this store needs one. Call the create_sandbox_key tool first (it is in this tool list and needs no credential), then pass the key you get back as the agent_key argument — or as an Authorization: Bearer header if your client can set headers. Do not ask a person to log in: there is no human login for this store.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Items to add to cart | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| agent_token | No | JWS compact (EdDSA/Ed25519) signed by the agent. Required for Shopify enforcement rules R001/R002/R004. A malformed token fails with AGENT_TOKEN_INVALID on any platform. On Shopify stores Trusteed also verifies the signature on receipt against a registered key that must belong to the calling agent (otherwise AGENT_TOKEN_INVALID and no cart is created), and the checkout Function verifies it again offline at payment. On other platforms Trusteed checks its structure only and forwards it to the store. | |
| display_context | No | Agent display capability: webview (browser) or headless | headless |
| idempotency_key | No | REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta["trusteed/idempotency-key"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation. | |
| agent_session_id | No | Opaque agent session identifier for cart resume across sessions |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| status | Yes | |
| cart_id | Yes | |
| currency | Yes | |
| next_step | Yes | |
| expires_at | No | ISO-8601 UTC instant at which this checkout SESSION stops being usable. It is not a stock reservation and not a price guarantee. |
| store_name | Yes | |
| session_state | Yes | |
| subtotal_cents | Yes | |
| display_context | Yes | |
| agent_session_id | Yes | |
| expires_in_seconds | No | Whole seconds left on this checkout SESSION at response time (0 when already past). It is not a stock reservation and not a price guarantee. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=true, openWorld=false), and the description goes well beyond them by disclosing the credential model, the fact that a Skyfire kya token has no effect here, and the distinction between MCP auth and the REST agent API. This is exactly the auth/permission context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and downstream routing first, credentials and identity caveats after. The uppercase labels (KYA IDENTITY, CREDENTIAL) aid scanning, though the block is dense enough that it reads more like a runbook than a description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and for a 6-parameter write tool the description still covers the credential prerequisite, the identity caveat, the downstream tool chain, and a guide pointer. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real semantic glue by documenting how the output value flows into differently-named parameters (cart_id vs checkout_session_id) and by clarifying the agent_key/header relationship. It adds meaning without re-stating the schema's own field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Create a shopping cart in Demo Store') and names the concrete artifact produced ('Returns a cart_id'). It also disambiguates from the large checkout sibling cluster by mapping its output to the exact parameter names downstream tools expect, so an agent can place it in the workflow without opening other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit ordering and prerequisites: call create_sandbox_key first, then pass the returned key as agent_key or an Authorization header. It also states when-not (no human login exists for this store) and points to the authoritative checkout guide resource, leaving no routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a temporary sandbox credential for this demo store, valid 24h. Present it as an Authorization: Bearer header, or — when your client cannot set headers — as the agent_key argument of the checkout tools. Payments here are simulated: this credential settles nothing and works only on the demo store. No human login is involved at any point.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses a 24h expiry, that payments are simulated and the credential 'settles nothing', that it works only on the demo store, and that no human login is involved. It does not state whether repeated calls mint a new key or invalidate an old one, nor any rate limit, which keeps it out of the top band.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences: the credential and its lifetime are front-loaded, the presentation mechanism follows, and the simulated-payment caveat closes. Every sentence carries non-redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter credential-minting tool with no annotations and no output schema, the description supplies everything an agent needs: what it returns conceptually, how to transmit it, its lifetime, and the critical trust caveat that it is demo-only and non-settling. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. The description adds relevant naming context by identifying the `agent_key` argument used downstream, though there are no input parameters whose semantics need explaining.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (temporary sandbox credential / API key) with the scope made explicit ('for this demo store, valid 24h'). An agent can immediately tell this apart from the checkout and trust siblings, none of which mint credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains how to present the credential (Authorization: Bearer header) and gives the fallback path when a client cannot set headers (agent_key argument of checkout tools), which effectively tells the agent where the credential is consumed. It stops short of an explicit 'call this before invoking checkout tools' instruction or naming an alternative, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current state of a cart created with create_cart: status, lines, totals, selected shipping, when it was previewed, its order if one exists and a pointer to get_trust_receipt. Read-only: it changes nothing and does not open any approval. Use it to resume a purchase; for UCP checkouts use ucp_get_checkout. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | Yes | The cart id returned by create_cart (the checkout session id, a valid UUID). | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description reinforces read-only and adds a genuine extra ('does not open any approval'), which no annotation conveys. It also enumerates what state is exposed (status, lines, totals, shipping, preview time, order, receipt pointer), compensating for the absent output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the purpose before routing and the guide reference. Slightly dense with the field enumeration, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich annotations and no output schema, the description carries the burden well: it lists the returned state, the safety profile, the alternative tool, and a documentation pointer. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are fully documented in the schema, so the baseline is 3. The description's reference to 'a cart created with create_cart' only restates the schema's own note about cart_id's origin and adds no syntax or format detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Read the current state of a cart') and enumerates the returned fields, so the agent knows exactly what comes back. It also explicitly contrasts itself with ucp_get_checkout, making sibling disambiguation immediate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the positive condition ('Use it to resume a purchase') and names the alternative with its selector ('for UCP checkouts use ucp_get_checkout'). It even points to the checkout guide resource for deeper context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete profile — trust score, policies, compliance, and protocol support — of the merchant this MCP endpoint belongs to. Takes NO parameters: the merchant is fixed by which store's /:storeSlug/mcp endpoint you connected to, not by an argument. To read a different merchant's profile, call this same tool on that merchant's own endpoint instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| store | Yes | |
| trust | Yes | |
| identity | Yes | |
| policies | Yes | |
| discovery | Yes | |
| protocols | Yes | |
| acpFeedUrl | Yes | |
| compliance | Yes | |
| manifest_jws | Yes | |
| manifest_hash | Yes | |
| protocolScopeNote | Yes | |
| agentPolicySummary | Yes | |
| manifest_signed_at | Yes | |
| supportedProtocols | Yes | |
| identityProviderType | Yes | |
| enrichedCatalogEnabled | Yes | |
| identityLinkingEnabled | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and openWorldHint, so the description needn't restate safety. It adds important behavioral context beyond the annotations: there is no parameter-based targeting, merchant identity is determined by the connected endpoint, and reading another merchant requires switching endpoints. It does not discuss auth or rate limits, but the endpoint-scoping insight is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no waste. It front-loads what the tool returns, then immediately addresses the critical invocation constraint, then the alternative path for other merchants.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description does not need to enumerate return fields, and annotations already cover the safety profile. Given that, the description is complete: it tells the agent what the tool returns, that it takes no arguments, and how to target a different merchant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema itself provides no semantic guidance. The description compensates by explaining why no parameters exist and how merchant identity is instead supplied implicitly by the endpoint. That is exactly the kind of clarification a parameterless tool needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Get the complete profile ... of the merchant') and enumerates the contents: trust score, policies, compliance, and protocol support. It clearly distinguishes this merchant-scoped profile from sibling trust tools by tying the resource to the MCP endpoint itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains the unusual invocation model: this tool takes no parameters because the merchant is fixed by the connected endpoint, and it directs the agent to call the same tool on another merchant's endpoint when a different merchant is needed. It does not explicitly compare itself to siblings like get_store_trust or get_trust_receipt, so it falls short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a SUMMARY of a specific page on Trusteed: its title, description, keywords, related tools and the link to the full page. It returns a summary, not the full page text: read the linked URL when the whole page is needed. content_scope says what came back. Pass the page slug (e.g. 'for-agents', 'pricing', 'blog') or a blog post slug (returns its excerpt). Use get_site_map first to discover available slugs. Pass page='blog' to list all blog posts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | Page slug (e.g. 'for-agents', 'pricing', 'trust') or blog post slug. Use 'blog' to list all blog posts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful behavior beyond them: it returns a summary rather than full text, `content_scope` indicates what came back, and a blog post slug yields only its excerpt. It does not describe pagination or error behavior, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The summary-vs-full-text distinction is front-loaded, followed by the return contents, the scope caveat, and the slug/prerequisite guidance. Every sentence carries distinct information with no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-shape burden and does so by listing the summary fields and the `content_scope` indicator. Prerequisite discovery and the blog-listing special case are both covered, so an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single `page` parameter, so the baseline is 3. The description adds value beyond the schema by giving concrete slug examples ('for-agents', 'pricing', 'blog') and noting that a blog post slug returns the post's excerpt, which clarifies accepted input forms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (page content) and immediately scopes it: 'a SUMMARY ... not the full page text'. It enumerates what the summary contains (title, description, keywords, related tools, link), which cleanly separates it from siblings like get_site_map and search_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: use get_site_map first to discover slugs, read the linked URL when the full page is needed, and pass page='blog' to list posts. It names the prerequisite tool and the fallback action rather than leaving them to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific product in Demo Store, including all variants, sizes, colors, and availability.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Product ID — use the `id` field returned by search_products or nlweb_ask (e.g. 'prod-001'). Do not invent IDs. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| tags | No | |
| error | No | |
| price | No | |
| title | No | |
| jsonLd | No | |
| vendor | No | |
| message | No | |
| currency | No | |
| variants | No | |
| image_url | No | |
| attributes | No | |
| categories | No | |
| product_id | No | |
| review_count | No | |
| stock_status | No | |
| average_rating | No | |
| compare_at_price | No | |
| rating_provenance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description carries no burden for safety traits. What it adds is content scope (variants, sizes, colors, availability) rather than behavioral characteristics like rate limits, errors, or authorization requirements. This is adequate but adds no significant behavioral transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, the action is front-loaded, and the included detail modifiers are concise. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool with an output schema and rich annotations, the description is essentially complete. It doesn't explain when to use it vs alternatives, but that gap is relatively minor for a get-by-ID operation and is somewhat addressed by the schema. Overall, it provides enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for product_id is complete (100% coverage) and already instructs using the `id` field from search_products or nlweb_ask and not to invent IDs. The tool description provides no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information for a specific product, listing included attributes (variants, sizes, colors, availability). The verb 'Get' and resource 'specific product' are explicit. It does not explicitly distinguish from sibling tools like search_products or search_products_enriched, but the 'specific product' phrasing implies a lookup-by-ID role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific product ID is known, but it does not provide explicit guidance on when to use this tool versus alternatives such as search_products or compare_products. The parameter schema adds the hint to use IDs from search_products or nlweb_ask, but the description itself lacks this context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available shipping rates for the cart. Requires shipping_address — pass it in the call. If the buyer requests the cheapest option, use cheapest_shipping_handle when non-null; it is null when rates cannot be compared in the cart currency. Rates marked authoritative=false are estimates, not the final charge.
PREFER THE CART CARD: if create_cart returned an interactive card (the buyer can see and click it), let them enter the address and pick shipping there instead of calling this tool yourself — each top-level call you make here opens a new card in the transcript instead of updating the one already open. Only call it yourself when there is no interactive card (text-only client) or the buyer explicitly asks you to handle it in chat. Checkout guide: read the MCP resource trusteed://guides/checkout. CREDENTIAL: this store needs one. Call the create_sandbox_key tool first (it is in this tool list and needs no credential), then pass the key you get back as the agent_key argument — or as an Authorization: Bearer header if your client can set headers. Do not ask a person to log in: there is no human login for this store.
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | Yes | Cart session ID returned by create_cart | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| shipping_address | No | Destination address. Required: this tool does not prompt for it. |
| Name | Required | Description |
|---|---|---|
| rates | Yes | |
| cart_id | Yes | |
| address_city | No | |
| address_country | No | |
| cheapest_shipping_handle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that authoritative=false rates are estimates rather than final charges, that cheapest_shipping_handle is null when rates cannot be compared in the cart currency, and that each top-level call opens a new card in the transcript. The credential requirement is also documented. Annotations (readOnlyHint=false, non-idempotent) do not cover any of this, and nothing contradicts them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then the card preference, then the credential flow, so the important routing rule comes early. It is dense and a little long, with the credential repeated across the description and schema, but nearly every sentence carries operational information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and return values are not restated, yet the one return-field semantic an agent actually needs (authoritative=false meaning estimates) is given. Combined with the address requirement, credential flow, and card-vs-chat decision, nothing needed to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies, but the description adds real meaning: it states shipping_address must be supplied in the call and that the tool will not prompt for it, and it explains the agent_key credential's purpose and the alternative Authorization header path. That is value beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("Get available shipping rates for the cart") and immediately scopes it against the sibling flow by pointing to select_shipping_option territory via cheapest_shipping_handle. An agent can tell it apart from create_cart or select_shipping_option without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-not-to-use guidance: prefer the cart card and let the buyer pick shipping there, only call directly when there is no interactive card or the buyer explicitly asks. It also names the checkout guide resource and the prerequisite create_sandbox_key tool, so the routing decision and the setup path are both unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the complete site map of Trusteed: all public pages organized by category. Use this to discover what sections are available (docs, blog, integrations, legal, marketing) and find the right path before calling get_page_content.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter pages by category: commerce, docs, legal, blog, marketing, integrations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the return shape ('all public pages organized by category') which matters since no output schema exists, but says nothing about pagination, completeness guarantees, or auth needs. Adds modest value over 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the core behavior front-loaded and the usage/routing hint second. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter, read-only discovery tool with no output schema, the description covers purpose, scope, and the intended follow-up call. Only the shape/detail of the returned map (ordering, fields per page) is left implicit, which is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'category' enum parameter is fully documented in the schema. The description never mentions the category filter, so it adds no meaning beyond structured data — baseline 3 per the schema-coverage rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the complete site map of Trusteed') plus the scope ('all public pages organized by category'). It explicitly distinguishes itself from the sibling get_page_content by positioning itself as the discovery step before it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use it ('Use this to discover what sections are available... and find the right path before calling get_page_content'), naming both the goal and the follow-up tool. It stops short of stating when NOT to use it or naming alternative discovery tools such as search_docs or browse_categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Demo Store's signed trust score (v4.1, 0-100) with per-signal data quality, confidence level, and a detached JWS for offline verification. Don't trust the number — verify it: download the JWKS at jwks_snapshot_uri, validate jws_compact with signing_kid, and recompute payload_hash_sha256.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| score | Yes | |
| available | Yes | |
| breakdown | Yes | |
| issued_at | Yes | |
| score_cap | Yes | |
| signature | Yes | |
| store_slug | Yes | |
| computed_at | Yes | |
| scoring_version | Yes | |
| confidence_level | Yes | |
| recommended_action | Yes | |
| confidence_interval | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world; the description goes further by disclosing the payload's structure, that the JWS is detached, and the exact offline verification path including key discovery and hash recomputation. That is real behavioral context an agent could not infer from the annotation block.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both load-bearing: the first defines the payload, the second is a front-loaded imperative verification sequence. No filler and no restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not enumerate return fields, yet it usefully summarizes them and supplies the verification workflow. The only missing piece for full completeness is any guidance on failure modes or when the score is unavailable versus when a receipt should be fetched instead.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; the description correctly adds nothing parameter-related and instead spends its words on output semantics. Nothing in the description misrepresents the empty input contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get Demo Store's signed trust score') and immediately qualifies it with version, scale (v4.1, 0-100), and the bundled artifacts (per-signal data quality, confidence level, detached JWS). This clearly separates it from receipt-oriented siblings like get_trust_receipt and verify_trust_receipt, which operate on receipts rather than the score itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete usage posture ('Don't trust the number — verify it') and a three-step verification recipe pointing at jwks_snapshot_uri, signing_kid, and payload_hash_sha256. It does not, however, say when to prefer this over get_trust_receipt or verify_trust_receipt, so sibling routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the signed trust receipt for a checkout. A receipt records the complete_checkout call; read order_placed before telling anyone a purchase happened. Returns the receipt id, the JWS signature and how to verify it. Issuance is asynchronous: right after complete_checkout this may answer status: "pending" with a retry delay. pending with code receipt_pending means the purchase completed and the receipt is on its way; checkout_in_progress means the complete_checkout call is still running. Only the credential that made the purchase can read its receipt. A receipt attests that the call happened, not that money moved: read settlement (it is not_attested unless the payment rail confirmed it). PREFER THE CART CARD: if the purchase was completed on an interactive card, it already fetches and shows this receipt itself right after the order — calling this tool yourself right after is usually redundant and opens a new card in the transcript. Call it yourself only when there is no interactive card, or the buyer asks for the receipt later in a new turn. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | No | The order id of a completed purchase, when you have the order but not the checkout session. Provide this or checkout_session_id. | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| checkout_session_id | No | The checkout session id returned by create_cart and echoed by complete_checkout. Provide this or order_id. |
| Name | Required | Description |
|---|---|---|
| jws | No | |
| code | No | |
| docs | No | |
| status | Yes | |
| call_id | No | |
| message | No | |
| order_id | No | |
| issued_at | No | |
| dimensions | No | |
| receipt_id | No | |
| verify_url | No | |
| verify_with | No | |
| order_placed | No | |
| checkout_status | No | |
| does_not_attest | No | |
| signature_status | No | |
| retry_after_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description goes well beyond them, disclosing asynchronous issuance, the pending/receipt_pending/checkout_in_progress states, the credential scoping constraint, and the attestation-vs-settlement distinction. The only deduction is for not clarifying the pagination or response shape, though an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then layered with state semantics and routing guidance. It is a single dense paragraph, and nearly every clause carries operational weight, but it runs long enough that the receipt-state rules and the 'prefer the cart card' rule compete for attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with full annotation coverage and an output schema, this covers everything an agent needs: what it returns, async states and retry, error codes, auth scoping, and when calling it is redundant. A checkout guide resource is also referenced for deeper context. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema explains both order_id and checkout_session_id as alternatives, plus the agent_key fallback. The description adds nothing beyond this about parameter semantics itself. It also doesn't clarify that providing both ids or neither is acceptable, though required parameters are zero.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: "Retrieve the signed trust receipt for a checkout." It also defines what a receipt is and its relation to complete_checkout, which clearly separates it from checkout-state tools. It does not explicitly distinguish itself from the sibling verify_trust_receipt, leaving that boundary to be inferred from "how to verify it".
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-not guidance: "PREFER THE CART CARD... calling this tool yourself right after is usually redundant and opens a new card in the transcript." It then names the exact conditions under which an agent should call it instead (no interactive card, or a later turn), which is about as decisive as routing guidance gets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview the complete order summary before payment. Advances the session to ready-for-payment state. If you only need the price, call quote_checkout instead: it computes the same total without advancing the session or opening an approval.
PREFER THE CART CARD: if there is an interactive card for this cart, let it compute and show the summary instead of calling this tool yourself — it keeps the flow in one card. Checkout guide: read the MCP resource trusteed://guides/checkout. CREDENTIAL: this store needs one. Call the create_sandbox_key tool first (it is in this tool list and needs no credential), then pass the key you get back as the agent_key argument — or as an Authorization: Bearer header if your client can set headers. Do not ask a person to log in: there is no human login for this store.
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | Yes | Cart session ID returned by create_cart | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| payment_mandate | No | Payment mandate issued by the platform for this cart: the compact JWS you receive after the approval opened by `preview_checkout` is granted (its `exp` is Unix seconds and `aud` is this store's slug). Forward it as received; a mandate you write yourself is not accepted here. The approval is bound to your agent credential and does not verify that a person was present. Use this when your client cannot set an `X-Payment-Mandate` header. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| status | Yes | |
| currency | Yes | |
| next_step | No | |
| tax_cents | Yes | |
| expires_at | No | |
| store_name | Yes | |
| tax_status | Yes | |
| total_note | Yes | |
| approval_id | No | |
| total_cents | Yes | |
| approval_url | No | |
| discount_cents | Yes | |
| shipping_cents | Yes | |
| shipping_title | No | |
| subtotal_cents | Yes | |
| total_is_final | Yes | |
| payment_options | No | |
| shipping_source | No | |
| next_step_message | No | |
| expires_in_seconds | No | Whole seconds left on this checkout SESSION at response time (0 when already past). It is not a stock reservation and not a price guarantee. |
| approval_status_url | No | |
| checkout_session_id | Yes | |
| shipping_authoritative | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the description is consistent with them while adding context they cannot carry: it advances the session to ready-for-payment, opens an approval, and requires a credential obtained via create_sandbox_key rather than a human login. This is exactly the kind of state-change and auth disclosure annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and the state-change warning, then routing, then credential mechanics. It is denser than average and the bolded cart-card paragraph plus the credential paragraph add length, but each carries actionable routing or auth information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. Between the stated state transition, the alternative tool, the credential provisioning path, and the guide resource, an agent has everything needed to invoke this correctly on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions for cart_id, agent_key, and payment_mandate are already detailed, so the baseline is 3. The description nonetheless adds sequencing value the schema lacks: it tells the agent to call create_sandbox_key first (which needs no credential) and that the key may be passed as the agent_key argument or an Authorization: Bearer header.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource (preview the complete order summary before payment) and immediately scopes it against the sibling that does something superficially similar, quote_checkout. An agent can distinguish it from quote_checkout, complete_checkout, and get_checkout_state 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (before payment), explicit when-not (use quote_checkout if you only need the price, because this tool advances the session and opens an approval), a stated preference for the cart card, and a pointer to the checkout guide resource. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only price quote. Does not advance the session, open approvals or enable payment. To pay, call preview_checkout.
Computes the same totals as preview_checkout for this cart (subtotal, shipping, discount, tax status, total_is_final), with status QUOTE_ONLY, but not the same checks: it does not check your payment mandate's spending cap; preview_checkout does. Read-only on Trusteed's side: where the store prices orders on its own platform (WooCommerce), the store builds a temporary cart to compute the quote and discards it. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | Yes | Cart session ID returned by create_cart | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, but the description adds substantial non-obvious context: no session advancement, no approvals, no payment enablement, no spending-cap enforcement, and the fact that WooCommerce stores build and discard a temporary cart. This is exactly the extra behavioral disclosure the dimension rewards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core definition and the routing alternative in the first two sentences. The remaining detail (check differences, WooCommerce internals, guide link) is useful but slightly dense; nearly every sentence earns its place, though the parenthetical total list borders on schema restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully enumerates the computed fields (subtotal, shipping, discount, tax status, total_is_final) and the QUOTE_ONLY status, and points to the checkout guide resource. Nothing needed to call or interpret the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (cart_id, agent_key) are fully documented in the schema. The description adds no parameter-level syntax, format, or constraint detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read-only price quote') and immediately distinguishes itself from its closest sibling by naming preview_checkout as the tool that actually enables payment. An agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('read-only price quote') and when-not ('does not advance the session, open approvals or enable payment'), with a named alternative ('To pay, call preview_checkout'). It even specifies a behavioral difference in checks: quote_checkout does not enforce the payment mandate's spending cap while preview_checkout does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all Trusteed public documentation: pages, blog posts, FAQ entries, error codes, the agent checkout guide, and the tools of this endpoint. Returns ranked results by relevance. Use this to find answers about protocols, pricing, integration guides, trust scores, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter results by type: page, blog, faq, error (error codes), guide (checkout guide sections) or tool (tools served by this endpoint). Omit to search all types. | |
| limit | No | Maximum number of results (1-20, default 10) | |
| query | Yes | Search query, e.g. 'trust score threshold', 'shopify integration', 'rate limits' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds value beyond that by stating results are ranked by relevance and by scoping the searchable corpus, though it omits any note on pagination or result truncation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause with the corpus list following, then return behavior, then usage. Efficient, though the final sentence's content areas partly restate the first sentence's enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey return behavior, which it does ('ranked results by relevance'). Combined with fully documented parameters and rich annotations, it is nearly complete for a simple search tool; only pagination/result-count semantics are unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (type enum, limit bounds, query examples all documented inline), so the baseline is 3. The description's enumeration of content types loosely maps to the type filter but adds no syntax or format detail beyond what the schema already carries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (full-text search) and resource (Trusteed public documentation) and enumerates the covered content types. An agent can distinguish this from get_page_content (fetches a single page) and search_products (product search), though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this to find answers about protocols, pricing, integration guides, trust scores, and more" gives clear context for when to reach for the tool. It stops short of naming alternatives or stating when-not to use it, so no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search products in Demo Store. Returns matching products with prices, images, availability, and direct links. Results include data for generating a visual product carousel artifact with category filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (1-50) | |
| query | No | Search query (e.g. 'red sneakers', 'winter jacket'). Omit to list all products. | |
| cursor | No | Opaque pagination cursor from next_cursor of a previous response. Only valid for the SAME query, category, price range and sort_by — a cursor replayed against different filters is rejected, not silently applied. | |
| compact | No | When true, the same products are described only once instead of twice. `structuredContent.products` stays the full typed record — every field, every product, untouched — but the text reply becomes a short id/title/price/currency/availability line per product instead of a markdown re-narration of that same data (images, links, ratings inline). Nothing that asserts trust is affected: `merchant_trust`, `rating_provenance` and `sort_provenance_warning` are never trimmed by this flag. Ignored when `field_mask` is also set — a field mask already replaces the narration with a compact listing, so there is nothing left for `compact` to cut. | |
| sort_by | No | Sort order for results | relevance |
| category | No | Filter by category slug | |
| max_price | No | Maximum price filter | |
| min_price | No | Minimum price filter | |
| field_mask | No | Return only these product fields, to spend less of your context on a large catalogue. `id` is always included. Supplying a mask also drops the carousel/UI payloads, which are the bulk of a full response. |
| Name | Required | Description |
|---|---|---|
| query | No | |
| total | Yes | |
| has_more | No | |
| products | Yes | |
| next_cursor | No | |
| store_environment | No | |
| sort_provenance_warning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value beyond those by revealing that results are structured for generating a visual product carousel artifact and include category filtering. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core action and return value, then the artifact-specific detail. No wasted words or redundant rehashing of the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich input schema, output schema, and safety annotations, the description is largely complete for invoking the tool correctly. The only notable gap is the lack of any pointer to search_products_enriched when richer results are needed, but that is more of a usage-guidance issue than a completeness failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description only lightly touches category filtering soldered and does not need to supplement the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Search products in Demo Store') and summarizes what is returned: matching products with prices, images, availability, and direct links. It is clear but does not explicitly differentiate itself from the sibling 'search_products_enriched', so an agent must infer which search variant to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus search_products_enriched or browse_categories. The description implies generic product search but provides no exclusions, alternatives, or route-selection logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search products with enriched data including structured attributes, variants, GTIN, and images. Ideal for comparison and detailed product discovery. Matching is keyword/substring-based (title, description, tags, vendor) with rating-then-review ordering — the rating and review count it orders by are asserted by the merchant and are not verified by Trusteed. Use this when you have concrete keywords, a category, or a price range.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-20) | |
| query | Yes | Search query | |
| category | No | Filter by category | |
| max_price | No | Maximum price | |
| min_price | No | Minimum price |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| products | Yes | |
| sort_provenance_warning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, non-mutating operation. The description adds valuable behavioral context by specifying the matching algorithm (keyword/substring-based on title, description, tags, vendor) and the ordering (rating then review count), plus the important caveat that ratings are not verified by Trusteed. This adds transparency beyond annotations, though it could mention pagination or result limits, hence scoring 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose and enriched data context, then follows with technical details and usage guidance. It avoids fluff, but slightly dense in the middle with matching/ordering details; still, every sentence contributes to understanding. Score 4 rather than 5 because the flow could be improved by separating use case from mechanics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema (likely describing the enriched data structure) and rich annotations, the description covers the key aspects: what data is returned, how matching works, ordering, and when to use. It doesn't explicitly mention pagination or how to handle empty results, but for a search tool with this complexity, it's adequately complete. Score 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description reinforces the usage of query, category, and price range (linking to min_price/max_price) and clarifies the search scope. It doesn't introduce entirely new parameter details beyond schema, but given high coverage, baseline is 3, and the description's linking of natural language to parameters adds value, hence 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching products with enriched data (structured attributes, variants, GTIN, images) and specifies the use case ('ideal for comparison and detailed product discovery'). It distinctly differentiates from the sibling tool 'search_products' by emphasizing the enriched data and ideal use case, making it easy for an agent to choose correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this when you have concrete keywords, a category, or a price range.' It also clarifies the matching mechanism and ordering criteria, and importantly highlights that the ordering is based on merchant-asserted ratings and reviews, which is a key caveat. This provides clear and actionable guidance beyond simple when-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select a shipping method for the cart. Must call get_shipping_rates first and provide idempotency_key. Reuse the same key for retries of the same cart and option; use a new key if either changes.
PREFER THE CART CARD: if there is an interactive card for this cart, let the buyer pick shipping there instead of calling this tool yourself — it keeps the flow in one card instead of opening a new one per step. Checkout guide: read the MCP resource trusteed://guides/checkout. CREDENTIAL: this store needs one. Call the create_sandbox_key tool first (it is in this tool list and needs no credential), then pass the key you get back as the agent_key argument — or as an Authorization: Bearer header if your client can set headers. Do not ask a person to log in: there is no human login for this store.
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | Yes | Cart session ID | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| idempotency_key | No | REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta["trusteed/idempotency-key"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation. | |
| shipping_handle | Yes | Shipping method handle from get_shipping_rates |
| Name | Required | Description |
|---|---|---|
| cart_id | Yes | |
| currency | Yes | |
| total_cents | Yes | |
| selected_title | Yes | |
| shipping_cents | Yes | |
| subtotal_cents | Yes | |
| selected_handle | Yes | |
| shipping_source | Yes | |
| shipping_authoritative | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, idempotent, non-destructive local write, and the description adds substantially more: the idempotency-key lifecycle (reuse for same cart+option, new key when either changes), the sandbox credential requirement, and that no human login exists. This is exactly the context an agent needs before a credentialed write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Action, precondition, and idempotency rule are front-loaded, then the card preference, then credentials. The credential paragraph runs long and partially duplicates the agent_key schema description, but every block carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Preconditions, idempotency semantics, credential acquisition, and the preferred interactive alternative are all covered, and an output schema exists so return values need no explanation. Nothing required to invoke this write correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 a nuance the schema lacks: the key must be reused for retries of the same cart AND option, and changed if either changes. The agent_key fallback path is also reiterated. This is meaningful added semantics beyond the field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Select a shipping method for the cart') and immediately distinguishes itself from the sibling get_shipping_rates by making it a prerequisite rather than an alternative. An agent knows exactly what this tool does versus the rate-lookup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the precondition (call get_shipping_rates first), gives idempotency-key reuse policy, and routes the agent away from the tool entirely when an interactive cart card exists. The credential path and the 'no human login' constraint are also spelled out, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a UCP checkout session. Transitions to 'canceled' status. Cannot cancel already completed checkouts. Use ONLY for a checkout session created with ucp_create_checkout (Universal Commerce Protocol); for the standard flow (create_cart, preview_checkout, complete_checkout) do not call this tool. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional cancellation reason | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| checkout_id | Yes | UCP checkout session ID (valid UUID) | |
| idempotency_key | No | REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta["trusteed/idempotency-key"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real behavior beyond the annotations: the resulting state ('canceled') and a precondition ('cannot cancel already completed checkouts'). It does not mention authorization or what happens to held carts, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action, then the resulting state, then the precondition, then the sibling exclusion, and finally the guide pointer. No redundant phrasing about what the annotations already state; every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A destruction tool with no output schema. The description covers the resulting status and the sole precondition (already-completed sessions), which is enough to call it correctly. It could clarify whether the cancellation is reversible or what the response contains, but the critical invocation constraints are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the idempotency_key description already covers the retry rule, so the description correctly does not restate it. The one addition 'Use ONLY for a checkout session created with ucp_create_checkout' slightly hints that checkout_id must be a UCP session, but does not add format or semantic detail beyond what the schema already documents. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (cancel) and resource (UCP checkout session) and immediately clarifies its scope against the sibling free function ucp_create_checkout and the standard-flow tools (create_cart, preview_checkout, complete_checkout). The agent can distinguish it from those siblings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives when to use (only for a session created with ucp_create_checkout), when not to use (do not call for the standard create_cart/preview/complete flow), and a prerequisite to consult the guide resource. This is precisely the kind of exclusion-and-alternative routing usage guidance is meant to provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete a UCP checkout session. Transitions to 'completed' status. Idempotent — safe to retry with the same idempotency_key. Use ONLY for a checkout session created with ucp_create_checkout (Universal Commerce Protocol); for the standard flow (create_cart, preview_checkout, complete_checkout) do not call this tool. For a cart built with create_cart use complete_checkout. PAYMENT MANDATE: this tool also requires one, issued by the platform, not written by you. Call preview_checkout for this cart, open the approval_url it returns, poll approval_status_url with your agent credential, and send the mandate you receive as the payment_mandate argument or an X-Payment-Mandate header. The approval is bound to your agent credential and the cart; it does not verify that a person was present. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| ap2 | No | AP2 mandates extension. Required when the checkout carries ap2.merchant_authorization. | |
| meta | No | UCP request metadata. meta['ucp-agent'].profile = URL of the platform profile; it must be an https URL without credentials (at most 2048 characters). | |
| buyer | No | Buyer name and email, needed to request the approval link. | |
| payment | No | UCP payment. With AP2, the Payment Mandate goes in instruments[].credential.token. | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| checkout_id | Yes | UCP checkout session ID (valid UUID) | |
| x402_payload | No | x402: signed payment for the server offer (omit to get it). | |
| payment_option | No | Payment method THE PERSON chose, when preview_checkout returned payment_options. Ask the person; never choose for them. Card numbers and wallet keys are never sent here: the person approves (and, with own_wallet, signs) on the approval page. | |
| idempotency_key | Yes | REQUIRED as an argument in this tool: the `Idempotency-Key` header or `_meta` alone is not enough. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation. | |
| payment_handler | No | Payment handler the store profile publishes. Omit for default. | |
| payment_mandate | No | Payment mandate issued by the platform for this cart: the compact JWS you receive after the approval opened by `preview_checkout` is granted (its `exp` is Unix seconds and `aud` is this store's slug). Forward it as received; a mandate you write yourself is not accepted here. The approval is bound to your agent credential and does not verify that a person was present. Use this when your client cannot set an `X-Payment-Mandate` header. | |
| shared_payment_token | No | Stripe Shared Payment Token (spt_…) granted by the buyer's agent wallet for payment_method=ACP. Issued by Stripe, scoped to this merchant, amount and currency, and consumed when used: it can be charged once. Only honoured when this deployment enables native ACP settlement. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readOnly and idempotentHint=true, but the description adds substantive context beyond them: the idempotency is tied to reusing the same idempotency_key, the mandate must be platform-issued and forwarded as received, and critically the approval is bound to the agent credential and 'does not verify that a person was present'. That is meaningful behavioral disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and routing before the dense payment-mandate instructions. Every sentence carries operational weight, though the mandate paragraph is long and would benefit from tighter phrasing. Size is defensible for a 12-parameter high-stakes mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a complex, high-consequence tool: it covers the routing decision, the required prerequisite flow steps, credential/mandate binding, and points to a dedicated checkout guide resource. With no output schema, the stated status transition ('completed') gives the needed return context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 workflow meaning that the schema can't: it explains that the payment_mandate is obtained via the preview/approval loop and can alternatively travel as an X-Payment-Mandate header, and that idempotency_key must be an argument and not just a header/_meta value. These are cross-parameter usage semantics beyond the field documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Complete a UCP checkout session') plus the resulting state transition ('completed'), and explicitly distinguishes itself from the sibling complete_checkout and from the create side (ucp_create_checkout). An agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('ONLY for a checkout session created with ucp_create_checkout'), when-not ('for the standard flow... do not call this tool'), and names the correct alternative ('For a cart built with create_cart use complete_checkout'). It further spells out the full payment-mandate acquisition path (preview_checkout → approval_url → poll approval_status_url → submit mandate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a UCP (Universal Commerce Protocol) checkout session from line items. Returns a UCP checkout object with status 'incomplete'. Starts the UCP flow (ucp_* tools); for the standard flow use create_cart instead. Do not mix the two flows on the same purchase. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | UCP request metadata. meta['ucp-agent'].profile = URL of the platform profile; it must be an https URL without credentials (at most 2048 characters). | |
| label | No | Optional label for additional identifiers (e.g. external order ref, multi-PSP reference) | |
| intent | No | Intent context for relevance and personalization | |
| currency | Yes | ISO 4217 currency code (e.g. USD) | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| line_items | Yes | Line items for the checkout | |
| idempotency_key | No | REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta["trusteed/idempotency-key"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, idempotent=true and destructive=false, so the write/idempotency profile is covered. The description adds genuinely new behavioral context: the returned object has status 'incomplete' (i.e. this is only the first step of a multi-call flow) and that the UCP flow must not be interleaved with the cart flow. It does not describe failure modes or what invalidates the session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, each carrying a distinct fact (purpose, return state, flow routing, cross-flow warning, guide pointer) with the purpose front-loaded. Nothing is padded or repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter nested-object write tool with no output schema, the description covers the essential flow context and the returned status. The only slight gap is next-step guidance (e.g. that ucp_complete_checkout finalizes the session), which the agent can infer from the sibling names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter — including the ignored price/title fields, the variant_id requirement, and the idempotency_key — is already documented in the schema. The description only gestures at 'line items' and adds no syntax or format detail beyond it, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a UCP checkout session from line items') and names the sibling it competes with ('for the standard flow use create_cart instead'). An agent can distinguish it from create_cart and the other ucp_* tools without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: use this to start the UCP flow, use create_cart for the standard flow, and do not mix the two on the same purchase. It also points to the checkout guide resource for further context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a UCP checkout session by ID. Returns the current state of the checkout. Use ONLY for a checkout session created with ucp_create_checkout (Universal Commerce Protocol); for the standard flow (create_cart, preview_checkout, complete_checkout) do not call this tool. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | UCP request metadata. meta['ucp-agent'].profile = URL of the platform profile; it must be an https URL without credentials (at most 2048 characters). | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| checkout_id | Yes | UCP checkout session ID (valid UUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered structurally. The description adds that it returns the checkout's current state and directs the agent to the checkout guide resource, which is useful routing context, though it says nothing about error behavior for invalid/expired IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the action and return value, then the routing constraint, then the guide pointer. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile and no output schema, the description adequately states what the call returns and when it applies. It could note failure modes (expired or unknown checkout IDs), but for a simple read tool it is essentially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so checkout_id, agent_key and meta are already documented in the schema, including the UUID format and credential fallback. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Retrieve a UCP checkout session by ID') and immediately describes what it returns ('the current state of the checkout'). It also distinguishes itself from the standard flow by naming the sibling tools it must not be used with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition ('Use ONLY for a checkout session created with ucp_create_checkout'), an explicit exclusion ('for the standard flow (create_cart, preview_checkout, complete_checkout) do not call this tool'), and points to a guide resource for further context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview a UCP checkout and move it to ready-for-payment. Call after destination and shipping are set, before ucp_complete_checkout. Use ONLY for a checkout created with ucp_create_checkout. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | UCP request metadata. meta['ucp-agent'].profile = URL of the platform profile; it must be an https URL without credentials (at most 2048 characters). | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| checkout_id | Yes | UCP checkout session ID (valid UUID) | |
| payment_mandate | No | Payment mandate issued by the platform for this cart: the compact JWS you receive after the approval opened by `preview_checkout` is granted (its `exp` is Unix seconds and `aud` is this store's slug). Forward it as received; a mandate you write yourself is not accepted here. The approval is bound to your agent credential and does not verify that a person was present. Use this when your client cannot set an `X-Payment-Mandate` header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the description is consistent with them by framing the call as a state transition. It adds sequencing and gating context ('after destination and shipping are set', 'before ucp_complete_checkout') that the annotations do not convey. It stops short of describing failure modes or what happens if the preconditions are unmet or the call is repeated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what it does first, then the preconditions and ordering, then the restriction and the pointer to the guide. No filler and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-idempotent checkout-state-transition tool with a fully described schema and no output schema, the description covers the step in the flow, its preconditions, and its exclusivity. It leaves the post-ready-for-payment state and the distinction from the non-prefixed preview_checkout sibling unstated, and there is no output schema to fill that in.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so checkout_id and the client-header fallbacks (agent_key, payment_mandate, meta) are already documented in the schema. The description adds no parameter-level detail of its own, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource (preview a UCP checkout) and adds the resulting state change (move it to ready-for-payment), which separates it from a pure read like ucp_get_checkout. It does not, however, explain how it differs from the similarly named sibling preview_checkout, leaving that ambiguity unresolved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit preconditions (destination and shipping must be set), an explicit ordering relationship (before ucp_complete_checkout), and an explicit scoping restriction (ONLY for a checkout created with ucp_create_checkout). It even routes the agent to a supplementary resource for deeper guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a UCP checkout session. Send line_items to replace all lines (each line may name a variant_id), and/or fulfillment to set the delivery address (fulfillment.destination, which returns the shipping options) and choose one (fulfillment.selected_option_id, which adds shipping to the totals). Only allowed when status is 'incomplete'. Use ONLY for sessions created with ucp_create_checkout; for the standard flow use create_cart and select_shipping_option. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | UCP request metadata. meta['ucp-agent'].profile = URL of the platform profile; it must be an https URL without credentials (at most 2048 characters). | |
| currency | No | ISO 4217 currency code (e.g. USD). Optional: defaults to the checkout's currency. | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. | |
| line_items | No | Replacement line items (replaces all lines). Omit to leave the lines as they are. | |
| checkout_id | Yes | UCP checkout session ID (valid UUID) | |
| fulfillment | No | Delivery. Send destination first, then selected_option_id (or both in one call). | |
| idempotency_key | No | REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta["trusteed/idempotency-key"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, idempotent=true, destructive=false), the description discloses the state gate, that line_items replaces ALL lines, and the two side effects: destination returns shipping options, selected_option_id adds shipping to totals. That is substantive behavioral context the annotations do not carry, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core verb+resource, then progressively details the two payload branches and constraints. Dense but every sentence carries information; the parenthetical asides are informative rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description partially compensates by explaining what the two fulfillment branches return/produce and by linking the checkout guide resource. For a 7-parameter nested-object write tool it is nearly complete, though the overall response shape is left to the referenced guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning beyond the schema: replacement semantics of line_items, that a line may name a variant_id, and the ordering relationship between fulfillment.destination and selected_option_id. It stops short of documenting meta, agent_key, or idempotency_key handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Update) and resource (UCP checkout session), then enumerates exactly which fields drive which effects (line_items replaces lines, fulfillment sets destination/option). It is clearly distinguished from siblings by naming ucp_create_checkout, create_cart, and select_shipping_option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the precondition (only when status is 'incomplete'), the scope (use ONLY for sessions created with ucp_create_checkout), and the alternative for the standard flow (create_cart and select_shipping_option), plus a pointer to the checkout guide resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a trust receipt's signature, revocation and chain coverage from inside this session (v1.0 receipts only; other profiles answer unsupported_profile, not invalid). LIMIT: the issuer verifies its own receipt (verified_by: issuer, independent: false), so this is a consistency check, not proof to a third party; independent_verification tells you how to verify it yourself against the public JWKS. Pass the jws from get_trust_receipt. Checkout guide: read the MCP resource trusteed://guides/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| jws | Yes | The compact JWS of the receipt (the `jws` field returned by get_trust_receipt). | |
| agent_key | No | Sandbox credential from `create_sandbox_key`. Use this when your client cannot set an `Authorization: Bearer` header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, but the description adds important behavioral context beyond them: the issuer self-verification limitation (verified_by: issuer, independent: false) and the unsupported_profile response for non-v1.0 receipts. Does not describe response shape, but that is secondary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and scope, then a LIMIT caveat, then input sourcing and a guide pointer. Information-dense and largely free of waste, though the parentheses and multiple embedded clauses make it slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description omits return-value detail, but it does disclose the key limitation and the non-v1.0 behavior, which are the main things an agent needs. Could be more complete on what a successful verification returns, but covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (jws, agent_key) are fully documented in the schema. The description reinforces which jws to supply but adds no format or syntax detail beyond what the schema already provides; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Check) and resource (trust receipt's signature, revocation, chain coverage) with a clear scoping constraint (v1.0 receipts only, other profiles answer unsupported_profile). This is well distinguished from get_trust_receipt, which retrieves rather than verifies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to pass the jws from get_trust_receipt, warns that this is a consistency check not third-party proof, and points to independent_verification and trusteed://guides/checkout for alternatives. Clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_store_trust2 fields changedOutput schema / properties / score_capAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "applies": {
+ "type": "boolean"
+ },
+ "note": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reason_code": {
+ "type": "string"
+ },
+ "uncapped_score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "value",
+ "applies",
+ "uncapped_score",
+ "reason_code",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "store_slug",
- "available",
- "score",
- "confidence_level",
- "scoring_version",
- "issued_at",
- "computed_at",
- "breakdown",
- "signature",
- "confidence_interval",
- "recommended_action"
-]New value: +[
+ "store_slug",
+ "available",
+ "score",
+ "confidence_level",
+ "scoring_version",
+ "issued_at",
+ "computed_at",
+ "score_cap",
+ "breakdown",
+ "signature",
+ "confidence_interval",
+ "recommended_action"
+]get_store_trust2 fields changedOutput schema / properties / computed_atAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / requiredPrevious value: -[
- "store_slug",
- "available",
- "score",
- "confidence_level",
- "scoring_version",
- "issued_at",
- "breakdown",
- "signature",
- "confidence_interval",
- "recommended_action"
-]New value: +[
+ "store_slug",
+ "available",
+ "score",
+ "confidence_level",
+ "scoring_version",
+ "issued_at",
+ "computed_at",
+ "breakdown",
+ "signature",
+ "confidence_interval",
+ "recommended_action"
+]get_merchant_profile1 field changedOutput schema / properties / agentPolicySummary / properties / maxItemsPerOrderAdded value: +{
+ "additionalProperties": true,
+ "properties": {
+ "derivedFrom": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "units": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "units",
+ "derivedFrom"
+ ],
+ "type": "object"
+}get_trust_receipt3 fields changedInput schema / properties / checkout_session_id / descriptionPrevious value: -"The checkout session id returned by create_cart and echoed by complete_checkout."New value: +"The checkout session id returned by create_cart and echoed by complete_checkout. Provide this or order_id."Input schema / properties / order_idAdded value: +{
+ "description": "The order id of a completed purchase, when you have the order but not the checkout session. Provide this or checkout_session_id.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "checkout_session_id"
-]complete_checkout2 fields changedInput schema / properties / payment_mandate / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "properties": {
- "aud": {
- "description": "This store's slug (the one in the URL you are calling) — not a domain.",
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- },
- "currency": {
- "description": "Three-letter currency code; must match the cart's currency.",
- "maxLength": 3,
- "minLength": 3,
- "type": "string"
- },
- "exp": {
- "description": "Expiry as an INTEGER of Unix seconds, in the future — not an ISO 8601 date string.",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- "mandate_id": {
- "description": "Your identifier for this mandate.",
- "maxLength": 128,
- "minLength": 1,
- "type": "string"
- },
- "max_amount_cents": {
- "description": "Spending limit the buyer gave you, as an integer in minor units (cents).",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- "sub": {
- "description": "The identity you authenticate as — it is compared against it. When the credential tool returns a `mandate_subject`, use that value.",
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- }
- },
- "required": [
- "mandate_id",
- "max_amount_cents",
- "currency",
- "exp",
- "sub",
- "aud"
- ],
- "type": "object"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / payment_mandate / descriptionPrevious value: -"Payment mandate with `mandate_id`, `max_amount_cents` (integer, minor units), `currency` (3 letters, must match the cart's), `exp` (expiry as an INTEGER of Unix seconds — not an ISO 8601 date string), `sub` (the identity you authenticate as — it is compared against it) and `aud` (the store slug this mandate is for, e.g. the slug in the URL you are calling — not a domain). It is a spending cap you declare to limit yourself: it authorises nothing and does not prove the buyer's consent. Use this when your client cannot set an `X-Payment-Mandate` header."New value: +"Payment mandate issued by the platform for this cart: the compact JWS you receive after the approval opened by `preview_checkout` is granted (its `exp` is Unix seconds and `aud` is this store's slug). Forward it as received; a mandate you write yourself is not accepted here. The approval is bound to your agent credential and does not verify that a person was present. Use this when your client cannot set an `X-Payment-Mandate` header."preview_checkout2 fields changedInput schema / properties / payment_mandate / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "properties": {
- "aud": {
- "description": "This store's slug (the one in the URL you are calling) — not a domain.",
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- },
- "currency": {
- "description": "Three-letter currency code; must match the cart's currency.",
- "maxLength": 3,
- "minLength": 3,
- "type": "string"
- },
- "exp": {
- "description": "Expiry as an INTEGER of Unix seconds, in the future — not an ISO 8601 date string.",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- "mandate_id": {
- "description": "Your identifier for this mandate.",
- "maxLength": 128,
- "minLength": 1,
- "type": "string"
- },
- "max_amount_cents": {
- "description": "Spending limit the buyer gave you, as an integer in minor units (cents).",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- "sub": {
- "description": "The identity you authenticate as — it is compared against it. When the credential tool returns a `mandate_subject`, use that value.",
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- }
- },
- "required": [
- "mandate_id",
- "max_amount_cents",
- "currency",
- "exp",
- "sub",
- "aud"
- ],
- "type": "object"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / payment_mandate / descriptionPrevious value: -"Payment mandate with `mandate_id`, `max_amount_cents` (integer, minor units), `currency` (3 letters, must match the cart's), `exp` (expiry as an INTEGER of Unix seconds — not an ISO 8601 date string), `sub` (the identity you authenticate as — it is compared against it) and `aud` (the store slug this mandate is for, e.g. the slug in the URL you are calling — not a domain). It is a spending cap you declare to limit yourself: it authorises nothing and does not prove the buyer's consent. Use this when your client cannot set an `X-Payment-Mandate` header."New value: +"Payment mandate issued by the platform for this cart: the compact JWS you receive after the approval opened by `preview_checkout` is granted (its `exp` is Unix seconds and `aud` is this store's slug). Forward it as received; a mandate you write yourself is not accepted here. The approval is bound to your agent credential and does not verify that a person was present. Use this when your client cannot set an `X-Payment-Mandate` header."ucp_complete_checkout2 fields changedInput schema / properties / payment_mandate / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "properties": {
- "aud": {
- "description": "This store's slug (the one in the URL you are calling) — not a domain.",
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- },
- "currency": {
- "description": "Three-letter currency code; must match the cart's currency.",
- "maxLength": 3,
- "minLength": 3,
- "type": "string"
- },
- "exp": {
- "description": "Expiry as an INTEGER of Unix seconds, in the future — not an ISO 8601 date string.",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- "mandate_id": {
- "description": "Your identifier for this mandate.",
- "maxLength": 128,
- "minLength": 1,
- "type": "string"
- },
- "max_amount_cents": {
- "description": "Spending limit the buyer gave you, as an integer in minor units (cents).",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- "sub": {
- "description": "The identity you authenticate as — it is compared against it. When the credential tool returns a `mandate_subject`, use that value.",
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- }
- },
- "required": [
- "mandate_id",
- "max_amount_cents",
- "currency",
- "exp",
- "sub",
- "aud"
- ],
- "type": "object"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / payment_mandate / descriptionPrevious value: -"Payment mandate with `mandate_id`, `max_amount_cents` (integer, minor units), `currency` (3 letters, must match the cart's), `exp` (expiry as an INTEGER of Unix seconds — not an ISO 8601 date string), `sub` (the identity you authenticate as — it is compared against it) and `aud` (the store slug this mandate is for, e.g. the slug in the URL you are calling — not a domain). It is a spending cap you declare to limit yourself: it authorises nothing and does not prove the buyer's consent. Use this when your client cannot set an `X-Payment-Mandate` header."New value: +"Payment mandate issued by the platform for this cart: the compact JWS you receive after the approval opened by `preview_checkout` is granted (its `exp` is Unix seconds and `aud` is this store's slug). Forward it as received; a mandate you write yourself is not accepted here. The approval is bound to your agent credential and does not verify that a person was present. Use this when your client cannot set an `X-Payment-Mandate` header."ucp_preview_checkout2 fields changedInput schema / properties / payment_mandate / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "properties": {
- "aud": {
- "description": "This store's slug (the one in the URL you are calling) — not a domain.",
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- },
- "currency": {
- "description": "Three-letter currency code; must match the cart's currency.",
- "maxLength": 3,
- "minLength": 3,
- "type": "string"
- },
- "exp": {
- "description": "Expiry as an INTEGER of Unix seconds, in the future — not an ISO 8601 date string.",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- "mandate_id": {
- "description": "Your identifier for this mandate.",
- "maxLength": 128,
- "minLength": 1,
- "type": "string"
- },
- "max_amount_cents": {
- "description": "Spending limit the buyer gave you, as an integer in minor units (cents).",
- "exclusiveMinimum": 0,
- "type": "integer"
- },
- "sub": {
- "description": "The identity you authenticate as — it is compared against it. When the credential tool returns a `mandate_subject`, use that value.",
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- }
- },
- "required": [
- "mandate_id",
- "max_amount_cents",
- "currency",
- "exp",
- "sub",
- "aud"
- ],
- "type": "object"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / payment_mandate / descriptionPrevious value: -"Payment mandate with `mandate_id`, `max_amount_cents` (integer, minor units), `currency` (3 letters, must match the cart's), `exp` (expiry as an INTEGER of Unix seconds — not an ISO 8601 date string), `sub` (the identity you authenticate as — it is compared against it) and `aud` (the store slug this mandate is for, e.g. the slug in the URL you are calling — not a domain). It is a spending cap you declare to limit yourself: it authorises nothing and does not prove the buyer's consent. Use this when your client cannot set an `X-Payment-Mandate` header."New value: +"Payment mandate issued by the platform for this cart: the compact JWS you receive after the approval opened by `preview_checkout` is granted (its `exp` is Unix seconds and `aud` is this store's slug). Forward it as received; a mandate you write yourself is not accepted here. The approval is bound to your agent credential and does not verify that a person was present. Use this when your client cannot set an `X-Payment-Mandate` header."browse_categories1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "categories": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "name": {
- "type": "string"
- },
- "product_count": {
- "type": "number"
- }
- },
- "required": [
- "name",
- "product_count"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "store_name": {
- "type": "string"
- },
- "total": {
- "type": "number"
- }
- },
- "required": [
- "categories",
- "total",
- "store_name"
- ],
- "type": "object"
-}New value: +nullcompare_products1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "bestValue": {
- "anyOf": [
- {
- "additionalProperties": true,
- "properties": {
- "productId": {
- "type": "string"
- },
- "reason": {
- "type": "string"
- }
- },
- "required": [
- "productId",
- "reason"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "commonFields": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "comparisonTable": {
- "additionalProperties": {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- "type": "object"
- },
- "products": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "attributes": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "key": {
- "type": "string"
- },
- "value": {
- "type": "string"
- }
- },
- "required": [
- "key",
- "value"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "availability": {
- "type": "string"
- },
- "averageRating": {
- "anyOf": [
- {
- "anyOf": [
- {
- "not": {}
- },
- {
- "type": "number"
- }
- ]
- },
- {
- "type": "null"
- }
- ]
- },
- "currency": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "price": {
- "type": "number"
- },
- "rating_provenance": {
- "anyOf": [
- {
- "additionalProperties": true,
- "properties": {
- "note": {
- "type": "string"
- },
- "origin": {
- "const": "merchant",
- "type": "string"
- },
- "strength": {
- "const": "claimed",
- "type": "string"
- },
- "verified": {
- "const": false,
- "type": "boolean"
- }
- },
- "required": [
- "origin",
- "strength",
- "verified",
- "note"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "reviewCount": {
- "type": "number"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "title",
- "price",
- "currency",
- "availability",
- "reviewCount",
- "attributes"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "recommendation_provenance_warning": {
- "type": "string"
- }
- },
- "required": [
- "products",
- "commonFields",
- "comparisonTable",
- "bestValue"
- ],
- "type": "object"
-}New value: +nullcomplete_checkout3 fields changedInput schema / properties / cel_context / additionalPropertiesPrevious value: -trueNew value: +{}Input schema / properties / cel_context / descriptionPrevious value: -"Optional enforcement context for Trusteed native MCP flows (no Shopify/WooCommerce/PrestaShop/Magento plugin). Providing these fields enables full evaluation of rules R004, R006, R008, R012-R013, R015-R017, R026-R028. See each field's own description for what it means and whether the server verifies it. These values are not signed into the receipt — do not include values you cannot substantiate."New value: +"Optional. Send only evidence you can substantiate; it can only make a check stricter, never looser. Unknown keys or out-of-range values are rejected with INVALID_ARGUMENT. Keys: key_age_hours, requested_scopes, product_categories, price_delta_bps, discount_codes_tried, discount_bps, lowest_stock, return_policy_mismatch, is_subscription, autorenew_consent, is_b2b, purchase_order_hash, shipping_po_box, shipping_freight_forwarder, provider_confidence, stored_value_cents, cross_merchant_abuse, refund_ratio, dispute_count, completed_orders_24h, merchant_orders_1h, digital_good_types, agent_provider_id."Input schema / properties / cel_context / propertiesRemoved value: -{
- "agent_provider_id": {
- "description": "Your provider identifier (e.g. \"openai\", \"anthropic\"), lowercase — send only if it applies to you.",
- "maxLength": 64,
- "minLength": 1,
- "pattern": "^[a-z0-9_\\-]+$",
- "type": "string"
- },
- "autorenew_consent": {
- "description": "True if the buyer explicitly consented to auto-renewal for a subscription — send only if it applies to you.",
- "type": "boolean"
- },
- "completed_orders_24h": {
- "description": "Orders this agent has completed with this merchant in the last 24 hours. Merchant/platform fact — send only with evidence; it can only make a check stricter, never looser.",
- "maximum": 1000000,
- "minimum": 0,
- "type": "integer"
- },
- "cross_merchant_abuse": {
- "description": "True if you have flagged this same buyer/agent for abuse at another merchant. Merchant/platform fact — send only with evidence; it can only make a check stricter, never looser.",
- "type": "boolean"
- },
- "digital_good_types": {
- "description": "Digital-good categories present in this cart — send only if it applies to you.",
- "items": {
- "enum": [
- "gift_card",
- "license_key",
- "downloadable",
- "stored_value"
- ],
- "type": "string"
- },
- "maxItems": 10,
- "type": "array"
- },
- "discount_bps": {
- "description": "Discount applied to this cart, in basis points — send only if it applies to you.",
- "maximum": 10000,
- "minimum": 0,
- "type": "integer"
- },
- "discount_codes_tried": {
- "description": "Number of discount codes you attempted before this checkout — send only if it applies to you.",
- "maximum": 100,
- "minimum": 0,
- "type": "integer"
- },
- "dispute_count": {
- "description": "Number of payment disputes this agent has had with this merchant. Merchant/platform fact — send only with evidence; it can only make a check stricter, never looser.",
- "maximum": 1000000,
- "minimum": 0,
- "type": "integer"
- },
- "is_b2b": {
- "description": "True if you are buying on behalf of a business — send only if it applies to you.",
- "type": "boolean"
- },
- "is_subscription": {
- "description": "True if this checkout creates a recurring subscription. The server checks this itself; a value you send cannot hide what it detects.",
- "type": "boolean"
- },
- "key_age_hours": {
- "description": "Age in hours of the API key/credential you are using with this store. Merchant/platform fact — send only with evidence; it can only make a check stricter, never looser.",
- "maximum": 720,
- "minimum": 0,
- "type": "integer"
- },
- "lowest_stock": {
- "description": "Lowest remaining stock you observed across this cart's line items. Merchant/platform fact — send only with evidence; it can only make a check stricter, never looser.",
- "minimum": 0,
- "type": "integer"
- },
- "merchant_orders_1h": {
- "description": "Orders this merchant has received from any agent in the last hour. Merchant/platform fact — send only with evidence; it can only make a check stricter, never looser.",
- "maximum": 1000000,
- "minimum": 0,
- "type": "integer"
- },
- "price_delta_bps": {
- "description": "Difference, in basis points, between the price you discovered earlier and the cart's current price. The server may recompute this from the catalogue and replace your value.",
- "maximum": 10000,
- "minimum": -10000,
- "type": "integer"
- },
- "product_categories": {
- "description": "Product categories present in this cart, as you understand them — send only if it applies to you.",
- "items": {
- "maxLength": 64,
- "type": "string"
- },
- "maxItems": 50,
- "type": "array"
- },
- "provider_confidence": {
- "description": "Your confidence (0-1) in your own agent-provider identification — send only if it applies to you.",
- "maximum": 1,
- "minimum": 0,
- "type": "number"
- },
- "purchase_order_hash": {
- "description": "Hash of a purchase order backing a B2B purchase — send only if it applies to you.",
- "maxLength": 128,
- "type": "string"
- },
- "refund_ratio": {
- "description": "This agent's refund ratio with this merchant (0-1). Merchant/platform fact — send only with evidence; it can only make a check stricter, never looser.",
- "maximum": 1,
- "minimum": 0,
- "type": "number"
- },
- "requested_scopes": {
- "description": "OAuth/permission scopes you requested when authenticating with this store — send only if it applies to you.",
- "items": {
- "maxLength": 64,
- "type": "string"
- },
- "maxItems": 20,
- "type": "array"
- },
- "return_policy_mismatch": {
- "description": "True if the return policy you were shown does not match what this store publishes elsewhere. Merchant/platform fact — send only with evidence; it can only make a check stricter, never looser.",
- "type": "boolean"
- },
- "shipping_freight_forwarder": {
- "description": "True if the shipping address is a freight-forwarder address — send only if it applies to you.",
- "type": "boolean"
- },
- "shipping_po_box": {
- "description": "True if the shipping address is a PO box. The server checks this itself; a value you send cannot hide what it detects.",
- "type": "boolean"
- },
- "stored_value_cents": {
- "description": "Stored-value amount (e.g. gift card) applied to this cart, in cents. The server checks this itself; a value you send cannot hide what it detects.",
- "maximum": 100000000,
- "minimum": 0,
- "type": "integer"
- }
-}create_sandbox_key1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "api_key": {
- "type": "string"
- },
- "declared_cap_template": {
- "additionalProperties": true,
- "properties": {
- "aud": {
- "type": "string"
- },
- "currency": {
- "type": "string"
- },
- "exp": {
- "type": "string"
- },
- "mandate_id": {
- "type": "string"
- },
- "max_amount_cents": {
- "type": "string"
- },
- "note": {
- "type": "string"
- },
- "sub": {
- "type": "string"
- }
- },
- "required": [
- "mandate_id",
- "max_amount_cents",
- "currency",
- "exp",
- "sub",
- "aud",
- "note"
- ],
- "type": "object"
- },
- "error": {
- "type": "string"
- },
- "expires_at": {
- "type": "string"
- },
- "mandate_subject": {
- "type": "string"
- },
- "presented_as": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "retryable": {
- "type": "boolean"
- }
- },
- "type": "object"
-}New value: +nullget_checkout_state1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "actor": {
- "enum": [
- "buyer",
- "merchant",
- "agent"
- ],
- "type": "string"
- },
- "blocking_expires_at": {
- "description": "ISO-8601 UTC instant at which the pending approval stops being valid. Not the checkout session validity: that is expires_at.",
- "type": "string"
- },
- "blocking_requirement": {
- "enum": [
- "none",
- "merchant_approval",
- "merchant_rejected",
- "buyer_mandate_approval",
- "buyer_payment",
- "preview",
- "session_closed",
- "unknown"
- ],
- "type": "string"
- },
- "checkout_session_id": {
- "type": "string"
- },
- "currency": {
- "type": "string"
- },
- "expires_at": {
- "type": "string"
- },
- "expires_in_seconds": {
- "type": "number"
- },
- "lines": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "line_price_cents": {
- "type": "number"
- },
- "name": {
- "type": "string"
- },
- "product_id": {
- "type": "string"
- },
- "quantity": {
- "type": "number"
- },
- "unit_price_cents": {
- "type": "number"
- }
- },
- "required": [
- "name",
- "quantity",
- "unit_price_cents",
- "line_price_cents"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "next_tool": {
- "type": "string"
- },
- "order": {
- "additionalProperties": true,
- "properties": {
- "external_order_id": {
- "type": "string"
- },
- "order_id": {
- "type": "string"
- },
- "status": {
- "type": "string"
- }
- },
- "required": [
- "order_id",
- "status"
- ],
- "type": "object"
- },
- "other_requirements": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "previewed_at": {
- "type": "string"
- },
- "reason": {
- "type": "string"
- },
- "receipt": {
- "additionalProperties": true,
- "properties": {
- "checkout_session_id": {
- "type": "string"
- },
- "tool": {
- "const": "get_trust_receipt",
- "type": "string"
- }
- },
- "required": [
- "tool",
- "checkout_session_id"
- ],
- "type": "object"
- },
- "shipping": {
- "additionalProperties": true,
- "properties": {
- "handle": {
- "type": "string"
- },
- "price_cents": {
- "type": "number"
- },
- "title": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "status": {
- "type": "string"
- },
- "suggested_next_tool": {
- "type": "string"
- },
- "totals": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "amount_cents": {
- "type": "number"
- },
- "type": {
- "type": "string"
- }
- },
- "required": [
- "type",
- "amount_cents"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "checkout_session_id",
- "status",
- "currency",
- "lines",
- "totals",
- "blocking_requirement"
- ],
- "type": "object"
-}New value: +nullget_page_content1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "category": {
- "type": "string"
- },
- "content_scope": {
- "enum": [
- "summary",
- "index"
- ],
- "type": "string"
- },
- "datePublished": {
- "type": "string"
- },
- "description": {
- "type": "string"
- },
- "excerpt": {
- "type": "string"
- },
- "found": {
- "type": "boolean"
- },
- "keywords": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "path": {
- "type": "string"
- },
- "posts": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "category": {
- "type": "string"
- },
- "datePublished": {
- "type": "string"
- },
- "excerpt": {
- "type": "string"
- },
- "path": {
- "type": "string"
- },
- "slug": {
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "slug",
- "path",
- "title",
- "excerpt",
- "category",
- "datePublished"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "readingTime": {
- "type": "string"
- },
- "related_tools": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "slug": {
- "type": "string"
- },
- "suggestion": {
- "type": "string"
- },
- "tags": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "title": {
- "type": "string"
- },
- "total": {
- "type": "number"
- },
- "type": {
- "enum": [
- "page",
- "blog_post",
- "blog_index"
- ],
- "type": "string"
- }
- },
- "type": "object"
-}New value: +nullget_site_map1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "blog_count": {
- "type": "number"
- },
- "categories": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "faq_count": {
- "type": "number"
- },
- "pages": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "category": {
- "type": "string"
- },
- "description": {
- "type": "string"
- },
- "keywords": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "path": {
- "type": "string"
- },
- "slug": {
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "slug",
- "path",
- "title",
- "description",
- "category",
- "keywords"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "total": {
- "type": "number"
- }
- },
- "required": [
- "pages",
- "total",
- "blog_count",
- "faq_count",
- "categories"
- ],
- "type": "object"
-}New value: +nullquote_checkout1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "checkout_session_id": {
- "type": "string"
- },
- "currency": {
- "type": "string"
- },
- "discount_cents": {
- "type": "number"
- },
- "expires_at": {
- "description": "ISO-8601 UTC instant at which this checkout SESSION stops being usable. It is not a stock reservation and not a price guarantee.",
- "type": "string"
- },
- "expires_in_seconds": {
- "description": "Whole seconds left on this checkout SESSION at response time (0 when already past). It is not a stock reservation and not a price guarantee.",
- "minimum": 0,
- "type": "integer"
- },
- "items": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "line_price": {
- "type": "number"
- },
- "name": {
- "type": "string"
- },
- "quantity": {
- "type": "number"
- }
- },
- "required": [
- "name",
- "quantity",
- "line_price"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "quote_only": {
- "const": true,
- "type": "boolean"
- },
- "shipping_authoritative": {
- "type": "boolean"
- },
- "shipping_cents": {
- "type": "number"
- },
- "shipping_source": {
- "enum": [
- "platform",
- "merchant_policy",
- "estimated"
- ],
- "type": "string"
- },
- "shipping_title": {
- "type": "string"
- },
- "status": {
- "const": "QUOTE_ONLY",
- "type": "string"
- },
- "store_name": {
- "type": "string"
- },
- "subtotal_cents": {
- "type": "number"
- },
- "tax_cents": {
- "type": "number"
- },
- "tax_status": {
- "enum": [
- "included",
- "not_calculated"
- ],
- "type": "string"
- },
- "total_cents": {
- "type": "number"
- },
- "total_is_final": {
- "type": "boolean"
- },
- "total_note": {
- "type": "string"
- }
- },
- "required": [
- "checkout_session_id",
- "store_name",
- "items",
- "subtotal_cents",
- "shipping_cents",
- "discount_cents",
- "total_cents",
- "currency",
- "tax_cents",
- "tax_status",
- "total_is_final",
- "total_note",
- "status",
- "quote_only"
- ],
- "type": "object"
-}New value: +nullsearch_docs1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "query": {
- "type": "string"
- },
- "results": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "excerpt": {
- "type": "string"
- },
- "path": {
- "type": "string"
- },
- "score": {
- "type": "number"
- },
- "slug": {
- "type": "string"
- },
- "title": {
- "type": "string"
- },
- "type": {
- "enum": [
- "page",
- "blog",
- "faq",
- "error",
- "guide",
- "tool"
- ],
- "type": "string"
- }
- },
- "required": [
- "type",
- "slug",
- "path",
- "title",
- "excerpt",
- "score"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "total": {
- "type": "number"
- }
- },
- "required": [
- "results",
- "total",
- "query"
- ],
- "type": "object"
-}New value: +nullucp_cancel_checkout1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "approval_url": {
- "type": "string"
- },
- "created_at": {
- "type": "string"
- },
- "currency": {
- "type": "string"
- },
- "expires_at": {
- "description": "ISO-8601 UTC instant at which this checkout SESSION stops being usable. It is not a stock reservation and not a price guarantee.",
- "type": "string"
- },
- "expires_in_seconds": {
- "description": "Whole seconds left on this checkout SESSION at response time (0 when already past). It is not a stock reservation and not a price guarantee.",
- "minimum": 0,
- "type": "integer"
- },
- "extensions": {
- "additionalProperties": {},
- "description": "`warnings[]` with `code`, `message`, `severity`.",
- "type": "object"
- },
- "fulfillment": {
- "additionalProperties": {},
- "type": "object"
- },
- "id": {
- "type": "string"
- },
- "idempotency_key": {
- "type": "string"
- },
- "intent": {
- "additionalProperties": {},
- "type": "object"
- },
- "label": {
- "type": "string"
- },
- "line_items": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "product_id": {
- "type": "string"
- },
- "quantity": {
- "type": "number"
- },
- "title": {
- "type": "string"
- },
- "variant_id": {
- "type": "string"
- },
- "variant_title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "product_id",
- "title",
- "quantity",
- "price"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "next_action": {
- "additionalProperties": {},
- "description": "Only when a person must approve or pay: `url`, `kind`, `retry`.",
- "type": "object"
- },
- "next_step": {
- "description": "Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp.",
- "type": "string"
- },
- "next_step_message": {
- "type": "string"
- },
- "payment_options": {
- "description": "When present, ask the person which option they want; never choose for them.",
- "items": {
- "additionalProperties": {},
- "type": "object"
- },
- "type": "array"
- },
- "status": {
- "enum": [
- "incomplete",
- "requires_escalation",
- "ready_for_complete",
- "complete_in_progress",
- "completed",
- "canceled"
- ],
- "type": "string"
- },
- "totals": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- },
- "label": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "updated_at": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "status",
- "currency",
- "line_items",
- "totals",
- "created_at",
- "updated_at"
- ],
- "type": "object"
-}New value: +nullucp_complete_checkout1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "approval_url": {
- "type": "string"
- },
- "created_at": {
- "type": "string"
- },
- "currency": {
- "type": "string"
- },
- "expires_at": {
- "description": "ISO-8601 UTC instant at which this checkout SESSION stops being usable. It is not a stock reservation and not a price guarantee.",
- "type": "string"
- },
- "expires_in_seconds": {
- "description": "Whole seconds left on this checkout SESSION at response time (0 when already past). It is not a stock reservation and not a price guarantee.",
- "minimum": 0,
- "type": "integer"
- },
- "extensions": {
- "additionalProperties": {},
- "description": "`warnings[]` with `code`, `message`, `severity`.",
- "type": "object"
- },
- "fulfillment": {
- "additionalProperties": {},
- "type": "object"
- },
- "id": {
- "type": "string"
- },
- "idempotency_key": {
- "type": "string"
- },
- "intent": {
- "additionalProperties": {},
- "type": "object"
- },
- "label": {
- "type": "string"
- },
- "line_items": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "product_id": {
- "type": "string"
- },
- "quantity": {
- "type": "number"
- },
- "title": {
- "type": "string"
- },
- "variant_id": {
- "type": "string"
- },
- "variant_title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "product_id",
- "title",
- "quantity",
- "price"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "next_action": {
- "additionalProperties": {},
- "description": "Only when a person must approve or pay: `url`, `kind`, `retry`.",
- "type": "object"
- },
- "next_step": {
- "description": "Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp.",
- "type": "string"
- },
- "next_step_message": {
- "type": "string"
- },
- "payment_options": {
- "description": "When present, ask the person which option they want; never choose for them.",
- "items": {
- "additionalProperties": {},
- "type": "object"
- },
- "type": "array"
- },
- "status": {
- "enum": [
- "incomplete",
- "requires_escalation",
- "ready_for_complete",
- "complete_in_progress",
- "completed",
- "canceled"
- ],
- "type": "string"
- },
- "totals": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- },
- "label": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "updated_at": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "status",
- "currency",
- "line_items",
- "totals",
- "created_at",
- "updated_at"
- ],
- "type": "object"
-}New value: +nullucp_create_checkout1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "approval_url": {
- "type": "string"
- },
- "created_at": {
- "type": "string"
- },
- "currency": {
- "type": "string"
- },
- "expires_at": {
- "description": "ISO-8601 UTC instant at which this checkout SESSION stops being usable. It is not a stock reservation and not a price guarantee.",
- "type": "string"
- },
- "expires_in_seconds": {
- "description": "Whole seconds left on this checkout SESSION at response time (0 when already past). It is not a stock reservation and not a price guarantee.",
- "minimum": 0,
- "type": "integer"
- },
- "extensions": {
- "additionalProperties": {},
- "description": "`warnings[]` with `code`, `message`, `severity`.",
- "type": "object"
- },
- "fulfillment": {
- "additionalProperties": {},
- "type": "object"
- },
- "id": {
- "type": "string"
- },
- "idempotency_key": {
- "type": "string"
- },
- "intent": {
- "additionalProperties": {},
- "type": "object"
- },
- "label": {
- "type": "string"
- },
- "line_items": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "product_id": {
- "type": "string"
- },
- "quantity": {
- "type": "number"
- },
- "title": {
- "type": "string"
- },
- "variant_id": {
- "type": "string"
- },
- "variant_title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "product_id",
- "title",
- "quantity",
- "price"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "next_action": {
- "additionalProperties": {},
- "description": "Only when a person must approve or pay: `url`, `kind`, `retry`.",
- "type": "object"
- },
- "next_step": {
- "description": "Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp.",
- "type": "string"
- },
- "next_step_message": {
- "type": "string"
- },
- "payment_options": {
- "description": "When present, ask the person which option they want; never choose for them.",
- "items": {
- "additionalProperties": {},
- "type": "object"
- },
- "type": "array"
- },
- "status": {
- "enum": [
- "incomplete",
- "requires_escalation",
- "ready_for_complete",
- "complete_in_progress",
- "completed",
- "canceled"
- ],
- "type": "string"
- },
- "totals": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- },
- "label": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "updated_at": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "status",
- "currency",
- "line_items",
- "totals",
- "created_at",
- "updated_at"
- ],
- "type": "object"
-}New value: +nullucp_get_checkout1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "approval_url": {
- "type": "string"
- },
- "created_at": {
- "type": "string"
- },
- "currency": {
- "type": "string"
- },
- "expires_at": {
- "description": "ISO-8601 UTC instant at which this checkout SESSION stops being usable. It is not a stock reservation and not a price guarantee.",
- "type": "string"
- },
- "expires_in_seconds": {
- "description": "Whole seconds left on this checkout SESSION at response time (0 when already past). It is not a stock reservation and not a price guarantee.",
- "minimum": 0,
- "type": "integer"
- },
- "extensions": {
- "additionalProperties": {},
- "description": "`warnings[]` with `code`, `message`, `severity`.",
- "type": "object"
- },
- "fulfillment": {
- "additionalProperties": {},
- "type": "object"
- },
- "id": {
- "type": "string"
- },
- "idempotency_key": {
- "type": "string"
- },
- "intent": {
- "additionalProperties": {},
- "type": "object"
- },
- "label": {
- "type": "string"
- },
- "line_items": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "product_id": {
- "type": "string"
- },
- "quantity": {
- "type": "number"
- },
- "title": {
- "type": "string"
- },
- "variant_id": {
- "type": "string"
- },
- "variant_title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "product_id",
- "title",
- "quantity",
- "price"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "next_action": {
- "additionalProperties": {},
- "description": "Only when a person must approve or pay: `url`, `kind`, `retry`.",
- "type": "object"
- },
- "next_step": {
- "description": "Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp.",
- "type": "string"
- },
- "next_step_message": {
- "type": "string"
- },
- "payment_options": {
- "description": "When present, ask the person which option they want; never choose for them.",
- "items": {
- "additionalProperties": {},
- "type": "object"
- },
- "type": "array"
- },
- "status": {
- "enum": [
- "incomplete",
- "requires_escalation",
- "ready_for_complete",
- "complete_in_progress",
- "completed",
- "canceled"
- ],
- "type": "string"
- },
- "totals": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- },
- "label": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "updated_at": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "status",
- "currency",
- "line_items",
- "totals",
- "created_at",
- "updated_at"
- ],
- "type": "object"
-}New value: +nullucp_preview_checkout1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "approval_id": {
- "type": "string"
- },
- "approval_status_url": {
- "type": "string"
- },
- "approval_url": {
- "type": "string"
- },
- "checkout_session_id": {
- "type": "string"
- },
- "currency": {
- "type": "string"
- },
- "discount_cents": {
- "type": "number"
- },
- "expires_at": {
- "type": "string"
- },
- "expires_in_seconds": {
- "description": "Whole seconds left on this checkout SESSION at response time (0 when already past). It is not a stock reservation and not a price guarantee.",
- "minimum": 0,
- "type": "integer"
- },
- "items": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "line_price": {
- "type": "number"
- },
- "name": {
- "type": "string"
- },
- "quantity": {
- "type": "number"
- }
- },
- "required": [
- "name",
- "quantity",
- "line_price"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "next_step": {
- "enum": [
- "ask_user_payment_method",
- "complete_ucp_checkout"
- ],
- "type": "string"
- },
- "next_step_message": {
- "type": "string"
- },
- "payment_options": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "available": {
- "type": "boolean"
- },
- "charges_without_approval": {
- "const": true,
- "type": "boolean"
- },
- "funding_source": {
- "anyOf": [
- {
- "enum": [
- "platform_test_card",
- "platform_test_wallet",
- "buyer_wallet"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "enum": [
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "paypal",
- "kyapay"
- ],
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "rail": {
- "enum": [
- "stripe",
- "x402",
- "kyapay",
- "paypal"
- ],
- "type": "string"
- },
- "reason_unavailable": {
- "enum": [
- "coming_soon",
- "not_enabled",
- "currency_not_supported",
- "unsupported_on_this_tool"
- ],
- "type": "string"
- }
- },
- "required": [
- "id",
- "label",
- "rail",
- "funding_source",
- "available"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "shipping_authoritative": {
- "type": "boolean"
- },
- "shipping_cents": {
- "type": "number"
- },
- "shipping_source": {
- "enum": [
- "platform",
- "merchant_policy",
- "estimated"
- ],
- "type": "string"
- },
- "shipping_title": {
- "type": "string"
- },
- "status": {
- "enum": [
- "READY_FOR_PAYMENT",
- "PENDING_APPROVAL"
- ],
- "type": "string"
- },
- "store_name": {
- "type": "string"
- },
- "subtotal_cents": {
- "type": "number"
- },
- "tax_cents": {
- "type": "number"
- },
- "tax_status": {
- "enum": [
- "included",
- "not_calculated"
- ],
- "type": "string"
- },
- "total_cents": {
- "type": "number"
- },
- "total_is_final": {
- "type": "boolean"
- },
- "total_note": {
- "type": "string"
- }
- },
- "required": [
- "checkout_session_id",
- "store_name",
- "items",
- "subtotal_cents",
- "shipping_cents",
- "discount_cents",
- "total_cents",
- "currency",
- "tax_cents",
- "tax_status",
- "total_is_final",
- "total_note",
- "status"
- ],
- "type": "object"
-}New value: +nullucp_update_checkout1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "approval_url": {
- "type": "string"
- },
- "created_at": {
- "type": "string"
- },
- "currency": {
- "type": "string"
- },
- "expires_at": {
- "description": "ISO-8601 UTC instant at which this checkout SESSION stops being usable. It is not a stock reservation and not a price guarantee.",
- "type": "string"
- },
- "expires_in_seconds": {
- "description": "Whole seconds left on this checkout SESSION at response time (0 when already past). It is not a stock reservation and not a price guarantee.",
- "minimum": 0,
- "type": "integer"
- },
- "extensions": {
- "additionalProperties": {},
- "description": "`warnings[]` with `code`, `message`, `severity`.",
- "type": "object"
- },
- "fulfillment": {
- "additionalProperties": {},
- "type": "object"
- },
- "id": {
- "type": "string"
- },
- "idempotency_key": {
- "type": "string"
- },
- "intent": {
- "additionalProperties": {},
- "type": "object"
- },
- "label": {
- "type": "string"
- },
- "line_items": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "product_id": {
- "type": "string"
- },
- "quantity": {
- "type": "number"
- },
- "title": {
- "type": "string"
- },
- "variant_id": {
- "type": "string"
- },
- "variant_title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "product_id",
- "title",
- "quantity",
- "price"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "next_action": {
- "additionalProperties": {},
- "description": "Only when a person must approve or pay: `url`, `kind`, `retry`.",
- "type": "object"
- },
- "next_step": {
- "description": "Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp.",
- "type": "string"
- },
- "next_step_message": {
- "type": "string"
- },
- "payment_options": {
- "description": "When present, ask the person which option they want; never choose for them.",
- "items": {
- "additionalProperties": {},
- "type": "object"
- },
- "type": "array"
- },
- "status": {
- "enum": [
- "incomplete",
- "requires_escalation",
- "ready_for_complete",
- "complete_in_progress",
- "completed",
- "canceled"
- ],
- "type": "string"
- },
- "totals": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- },
- "label": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "updated_at": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "status",
- "currency",
- "line_items",
- "totals",
- "created_at",
- "updated_at"
- ],
- "type": "object"
-}New value: +nullverify_trust_receipt1 field changedOutput schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": true,
- "properties": {
- "chain_covered": {
- "type": [
- "boolean",
- "null"
- ]
- },
- "independent": {
- "const": false,
- "type": "boolean"
- },
- "independent_verification": {
- "type": "string"
- },
- "key_id": {
- "type": [
- "string",
- "null"
- ]
- },
- "reason": {
- "type": "string"
- },
- "revoked": {
- "type": [
- "boolean",
- "null"
- ]
- },
- "signature_valid": {
- "type": [
- "boolean",
- "null"
- ]
- },
- "status": {
- "enum": [
- "verified",
- "invalid",
- "unsupported_profile",
- "not_this_store"
- ],
- "type": "string"
- },
- "verified_by": {
- "const": "issuer",
- "type": "string"
- }
- },
- "required": [
- "status",
- "signature_valid",
- "key_id",
- "revoked",
- "chain_covered",
- "verified_by",
- "independent",
- "independent_verification"
- ],
- "type": "object"
-}New value: +nullucp_preview_checkout2 fields changedOutput schema / properties / next_step / constRemoved value: -"complete_ucp_checkout"Output schema / properties / next_step / enumAdded value: +[
+ "ask_user_payment_method",
+ "complete_ucp_checkout"
+]ucp_cancel_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp."ucp_complete_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp."ucp_create_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp."ucp_get_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp."ucp_preview_checkoutucp_update_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, preview_ucp_checkout, review_not_available_in_ucp."get_checkout_statequote_checkoutucp_cancel_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."ucp_complete_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."ucp_create_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."ucp_get_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."ucp_update_checkout1 field changedOutput schema / properties / next_step / descriptionPrevious value: -"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."New value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, review_not_available_in_ucp."verify_trust_receiptcreate_sandbox_key1 field changedOutput schema / properties / declared_cap_templateAdded value: +{
+ "additionalProperties": true,
+ "properties": {
+ "aud": {
+ "type": "string"
+ },
+ "currency": {
+ "type": "string"
+ },
+ "exp": {
+ "type": "string"
+ },
+ "mandate_id": {
+ "type": "string"
+ },
+ "max_amount_cents": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "sub": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mandate_id",
+ "max_amount_cents",
+ "currency",
+ "exp",
+ "sub",
+ "aud",
+ "note"
+ ],
+ "type": "object"
+}get_merchant_profile1 field changedOutput schema / properties / policies / properties / importedAdded value: +{
+ "additionalProperties": true,
+ "description": "Pages IMPORTED from the merchant's store platform (link, title, last-modified date only; no page content). These are NOT policies declared by the merchant and are not verified or summarised here: read the linked page for the actual terms. Absent = nothing imported.",
+ "properties": {
+ "privacy": {
+ "$ref": "#/properties/policies/properties/imported/properties/terms"
+ },
+ "terms": {
+ "additionalProperties": true,
+ "properties": {
+ "fetched_at": {
+ "type": "string"
+ },
+ "page_modified_at": {
+ "type": "string"
+ },
+ "provenance": {
+ "const": "imported_from_store_page",
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "page_modified_at",
+ "source",
+ "fetched_at",
+ "provenance"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}search_docs3 fields changedInput schema / properties / type / descriptionPrevious value: -"Filter results by type: page, blog, or faq. Omit to search all types."New value: +"Filter results by type: page, blog, faq, error (error codes), guide (checkout guide sections) or tool (tools served by this endpoint). Omit to search all types."Input schema / properties / type / enumPrevious value: -[
- "page",
- "blog",
- "faq"
-]New value: +[
+ "page",
+ "blog",
+ "faq",
+ "error",
+ "guide",
+ "tool"
+]Output schema / properties / results / items / properties / type / enumPrevious value: -[
- "page",
- "blog",
- "faq"
-]New value: +[
+ "page",
+ "blog",
+ "faq",
+ "error",
+ "guide",
+ "tool"
+]select_shipping_option2 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"REQUIRED as an argument in this tool: the `Idempotency-Key` header or `_meta` alone is not enough. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."New value: +"REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta[\"trusteed/idempotency-key\"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."Input schema / requiredPrevious value: -[
- "cart_id",
- "shipping_handle",
- "idempotency_key"
-]New value: +[
+ "cart_id",
+ "shipping_handle"
+]apply_discount3 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Idempotency key for this call (UUID-v4 or bounded ASCII token, 1-128 chars). Equivalent to the `Idempotency-Key` header — send it here if your client cannot set headers."New value: +"REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta[\"trusteed/idempotency-key\"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."Input schema / properties / idempotency_key / maxLengthAdded value: +128Input schema / properties / idempotency_key / patternAdded value: +"^[A-Za-z0-9._:/-]{1,128}$"complete_checkout3 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Unique key to prevent duplicate charges on retry. Generate once per purchase attempt. Replay is enforced primarily on checkout_session_id (the existing order is returned). The first key seen for a session is recorded; reusing the same key short-circuits to the existing order."New value: +"REQUIRED as an argument in this tool: the `Idempotency-Key` header or `_meta` alone is not enough. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."Input schema / properties / idempotency_key / maxLengthAdded value: +128Input schema / properties / idempotency_key / patternAdded value: +"^[A-Za-z0-9._:/-]{1,128}$"create_cart3 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Idempotency key for this cart creation (UUID-v4 or bounded ASCII token, 1-128 chars). Equivalent to the `Idempotency-Key` header — send it here if your client cannot set headers. Retrying with the same key returns the same cart instead of creating a second one."New value: +"REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta[\"trusteed/idempotency-key\"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."Input schema / properties / idempotency_key / maxLengthAdded value: +128Input schema / properties / idempotency_key / patternAdded value: +"^[A-Za-z0-9._:/-]{1,128}$"get_shipping_rates1 field changedInput schema / properties / shipping_address / properties / province_code / descriptionPrevious value: -"Province or state code (optional)"New value: +"Province or state code (optional): the subdivision part only, without the country prefix and not the full ISO 3166-2 code (e.g. \"CA\" for California, \"ON\" for Ontario, \"B\" for Barcelona; never \"US-CA\" or \"ES-B\"). Only the Shopify checkout prefill reads it."select_shipping_option2 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Required. Reuse this key only when retrying the same cart and shipping option; use a new key if either changes."New value: +"REQUIRED as an argument in this tool: the `Idempotency-Key` header or `_meta` alone is not enough. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."Input schema / properties / idempotency_key / minLengthRemoved value: -1ucp_cancel_checkout5 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"REQUIRED for this write unless sent as the `Idempotency-Key` header or `_meta`. Reuse the same value when retrying the same operation."New value: +"REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta[\"trusteed/idempotency-key\"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."Input schema / properties / idempotency_key / maxLengthPrevious value: -255New value: +128Input schema / properties / idempotency_key / minLengthRemoved value: -1Input schema / properties / idempotency_key / patternAdded value: +"^[A-Za-z0-9._:/-]{1,128}$"Output schema / properties / next_step / descriptionAdded value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."ucp_complete_checkout4 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Unique key to prevent duplicate completions. Generate once per attempt."New value: +"REQUIRED as an argument in this tool: the `Idempotency-Key` header or `_meta` alone is not enough. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."Input schema / properties / idempotency_key / maxLengthAdded value: +128Input schema / properties / idempotency_key / patternAdded value: +"^[A-Za-z0-9._:/-]{1,128}$"Output schema / properties / next_step / descriptionAdded value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."ucp_create_checkout4 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Required by the checkout bucket (UUID-v4 or bounded ASCII token). Choose one per purchase attempt and reuse it to retry safely. Alternatively send it as the Idempotency-Key header or params._meta[\"trusteed/idempotency-key\"]."New value: +"REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta[\"trusteed/idempotency-key\"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."Input schema / properties / idempotency_key / maxLengthAdded value: +128Input schema / properties / idempotency_key / patternAdded value: +"^[A-Za-z0-9._:/-]{1,128}$"Output schema / properties / next_step / descriptionAdded value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."ucp_get_checkout1 field changedOutput schema / properties / next_step / descriptionAdded value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."ucp_update_checkout5 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"REQUIRED for this write unless sent as the `Idempotency-Key` header or `_meta`. Reuse the same value when retrying the same operation."New value: +"REQUIRED for this write unless sent as the `Idempotency-Key` header or `params._meta[\"trusteed/idempotency-key\"]`. 1-128 chars from [A-Za-z0-9._:/-]. Reuse the same value when retrying the same operation."Input schema / properties / idempotency_key / maxLengthPrevious value: -255New value: +128Input schema / properties / idempotency_key / minLengthRemoved value: -1Input schema / properties / idempotency_key / patternAdded value: +"^[A-Za-z0-9._:/-]{1,128}$"Output schema / properties / next_step / descriptionAdded value: +"Next-action code, not a tool name: provide_shipping_destination, refresh_shipping_rates, choose_shipping_option, ask_user_payment_method."ucp_cancel_checkout3 fields changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Optional idempotency key to prevent duplicate cancellations."New value: +"REQUIRED for this write unless sent as the `Idempotency-Key` header or `_meta`. Reuse the same value when retrying the same operation."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1ucp_update_checkout1 field changedInput schema / properties / idempotency_keyAdded value: +{
+ "description": "REQUIRED for this write unless sent as the `Idempotency-Key` header or `_meta`. Reuse the same value when retrying the same operation.",
+ "maxLength": 255,
+ "minLength": 1,
+ "type": "string"
+}create_cart1 field changedInput schema / properties / agent_token / descriptionPrevious value: -"JWS compact (EdDSA/Ed25519) signed by the agent. Required for Shopify enforcement rules R001/R002/R004. The token is embedded as a server-authoritative cart attribute — Trusteed does NOT verify the signature here; that is done offline by the Shopify Function WASM."New value: +"JWS compact (EdDSA/Ed25519) signed by the agent. Required for Shopify enforcement rules R001/R002/R004. A malformed token fails with AGENT_TOKEN_INVALID on any platform. On Shopify stores Trusteed also verifies the signature on receipt against a registered key that must belong to the calling agent (otherwise AGENT_TOKEN_INVALID and no cart is created), and the checkout Function verifies it again offline at payment. On other platforms Trusteed checks its structure only and forwards it to the store."complete_checkout1 field changedInput schema / properties / payment_mandate / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "type": "object"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "aud": {
+ "description": "This store's slug (the one in the URL you are calling) — not a domain.",
+ "maxLength": 256,
+ "minLength": 1,
+ "type": "string"
+ },
+ "currency": {
+ "description": "Three-letter currency code; must match the cart's currency.",
+ "maxLength": 3,
+ "minLength": 3,
+ "type": "string"
+ },
+ "exp": {
+ "description": "Expiry as an INTEGER of Unix seconds, in the future — not an ISO 8601 date string.",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "mandate_id": {
+ "description": "Your identifier for this mandate.",
+ "maxLength": 128,
+ "minLength": 1,
+ "type": "string"
+ },
+ "max_amount_cents": {
+ "description": "Spending limit the buyer gave you, as an integer in minor units (cents).",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "sub": {
+ "description": "The identity you authenticate as — it is compared against it. When the credential tool returns a `mandate_subject`, use that value.",
+ "maxLength": 256,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "mandate_id",
+ "max_amount_cents",
+ "currency",
+ "exp",
+ "sub",
+ "aud"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "string"
+ }
+]preview_checkout1 field changedInput schema / properties / payment_mandate / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "type": "object"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "aud": {
+ "description": "This store's slug (the one in the URL you are calling) — not a domain.",
+ "maxLength": 256,
+ "minLength": 1,
+ "type": "string"
+ },
+ "currency": {
+ "description": "Three-letter currency code; must match the cart's currency.",
+ "maxLength": 3,
+ "minLength": 3,
+ "type": "string"
+ },
+ "exp": {
+ "description": "Expiry as an INTEGER of Unix seconds, in the future — not an ISO 8601 date string.",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "mandate_id": {
+ "description": "Your identifier for this mandate.",
+ "maxLength": 128,
+ "minLength": 1,
+ "type": "string"
+ },
+ "max_amount_cents": {
+ "description": "Spending limit the buyer gave you, as an integer in minor units (cents).",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "sub": {
+ "description": "The identity you authenticate as — it is compared against it. When the credential tool returns a `mandate_subject`, use that value.",
+ "maxLength": 256,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "mandate_id",
+ "max_amount_cents",
+ "currency",
+ "exp",
+ "sub",
+ "aud"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "string"
+ }
+]ucp_cancel_checkout17 fields changedOutput schema / properties / extensions / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / extensions / descriptionAdded value: +"`warnings[]` with `code`, `message`, `severity`."Output schema / properties / extensions / propertiesRemoved value: -{
- "warnings": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "code": {
- "type": "string"
- },
- "disclosure_url": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "severity": {
- "enum": [
- "info",
- "caution",
- "critical"
- ],
- "type": "string"
- }
- },
- "required": [
- "code",
- "message",
- "severity"
- ],
- "type": "object"
- },
- "type": "array"
- }
-}Output schema / properties / fulfillment / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / fulfillment / propertiesRemoved value: -{
- "destination": {
- "additionalProperties": true,
- "properties": {
- "city": {
- "type": "string"
- },
- "country_code": {
- "type": "string"
- },
- "province_code": {
- "type": "string"
- },
- "zip": {
- "type": "string"
- }
- },
- "required": [
- "city",
- "country_code",
- "zip"
- ],
- "type": "object"
- },
- "options": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "authoritative": {
- "type": "boolean"
- },
- "estimated_delivery": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "source": {
- "enum": [
- "platform",
- "merchant_policy",
- "estimated"
- ],
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "title",
- "price",
- "source",
- "authoritative"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "selected_option_id": {
- "type": "string"
- }
-}Output schema / properties / intent / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / intent / propertiesRemoved value: -{
- "action": {
- "type": "string"
- },
- "context": {
- "type": "string"
- },
- "locale": {
- "type": "string"
- }
-}Output schema / properties / intent / requiredRemoved value: -[
- "action"
-]Output schema / properties / next_action / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / next_action / descriptionAdded value: +"Only when a person must approve or pay: `url`, `kind`, `retry`."Output schema / properties / next_action / propertiesRemoved value: -{
- "actor": {
- "const": "buyer",
- "type": "string"
- },
- "do": {
- "enum": [
- "approve",
- "pay"
- ],
- "type": "string"
- },
- "instruction": {
- "type": "string"
- },
- "reuse_arguments": {
- "items": {
- "enum": [
- "checkout_session_id",
- "checkout_id",
- "idempotency_key"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "then_call": {
- "maxLength": 64,
- "minLength": 1,
- "type": "string"
- },
- "url": {
- "type": "string"
- }
-}Output schema / properties / next_action / requiredRemoved value: -[
- "actor",
- "do",
- "url",
- "instruction"
-]Output schema / properties / next_step / constRemoved value: -"ask_user_payment_method"Output schema / properties / payment_options / descriptionAdded value: +"When present, ask the person which option they want; never choose for them."Output schema / properties / payment_options / items / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / payment_options / items / propertiesRemoved value: -{
- "available": {
- "type": "boolean"
- },
- "charges_without_approval": {
- "const": true,
- "type": "boolean"
- },
- "funding_source": {
- "anyOf": [
- {
- "enum": [
- "platform_test_card",
- "platform_test_wallet",
- "buyer_wallet"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "enum": [
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "paypal",
- "kyapay"
- ],
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "rail": {
- "enum": [
- "stripe",
- "x402",
- "kyapay",
- "paypal"
- ],
- "type": "string"
- },
- "reason_unavailable": {
- "enum": [
- "coming_soon",
- "not_enabled",
- "currency_not_supported",
- "unsupported_on_this_tool"
- ],
- "type": "string"
- }
-}Output schema / properties / payment_options / items / requiredRemoved value: -[
- "id",
- "label",
- "rail",
- "funding_source",
- "available"
-]ucp_complete_checkout18 fields changedInput schema / properties / payment_mandate / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "type": "object"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "aud": {
+ "description": "This store's slug (the one in the URL you are calling) — not a domain.",
+ "maxLength": 256,
+ "minLength": 1,
+ "type": "string"
+ },
+ "currency": {
+ "description": "Three-letter currency code; must match the cart's currency.",
+ "maxLength": 3,
+ "minLength": 3,
+ "type": "string"
+ },
+ "exp": {
+ "description": "Expiry as an INTEGER of Unix seconds, in the future — not an ISO 8601 date string.",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "mandate_id": {
+ "description": "Your identifier for this mandate.",
+ "maxLength": 128,
+ "minLength": 1,
+ "type": "string"
+ },
+ "max_amount_cents": {
+ "description": "Spending limit the buyer gave you, as an integer in minor units (cents).",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "sub": {
+ "description": "The identity you authenticate as — it is compared against it. When the credential tool returns a `mandate_subject`, use that value.",
+ "maxLength": 256,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "mandate_id",
+ "max_amount_cents",
+ "currency",
+ "exp",
+ "sub",
+ "aud"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "string"
+ }
+]Output schema / properties / extensions / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / extensions / descriptionAdded value: +"`warnings[]` with `code`, `message`, `severity`."Output schema / properties / extensions / propertiesRemoved value: -{
- "warnings": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "code": {
- "type": "string"
- },
- "disclosure_url": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "severity": {
- "enum": [
- "info",
- "caution",
- "critical"
- ],
- "type": "string"
- }
- },
- "required": [
- "code",
- "message",
- "severity"
- ],
- "type": "object"
- },
- "type": "array"
- }
-}Output schema / properties / fulfillment / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / fulfillment / propertiesRemoved value: -{
- "destination": {
- "additionalProperties": true,
- "properties": {
- "city": {
- "type": "string"
- },
- "country_code": {
- "type": "string"
- },
- "province_code": {
- "type": "string"
- },
- "zip": {
- "type": "string"
- }
- },
- "required": [
- "city",
- "country_code",
- "zip"
- ],
- "type": "object"
- },
- "options": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "authoritative": {
- "type": "boolean"
- },
- "estimated_delivery": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "source": {
- "enum": [
- "platform",
- "merchant_policy",
- "estimated"
- ],
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "title",
- "price",
- "source",
- "authoritative"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "selected_option_id": {
- "type": "string"
- }
-}Output schema / properties / intent / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / intent / propertiesRemoved value: -{
- "action": {
- "type": "string"
- },
- "context": {
- "type": "string"
- },
- "locale": {
- "type": "string"
- }
-}Output schema / properties / intent / requiredRemoved value: -[
- "action"
-]Output schema / properties / next_action / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / next_action / descriptionAdded value: +"Only when a person must approve or pay: `url`, `kind`, `retry`."Output schema / properties / next_action / propertiesRemoved value: -{
- "actor": {
- "const": "buyer",
- "type": "string"
- },
- "do": {
- "enum": [
- "approve",
- "pay"
- ],
- "type": "string"
- },
- "instruction": {
- "type": "string"
- },
- "reuse_arguments": {
- "items": {
- "enum": [
- "checkout_session_id",
- "checkout_id",
- "idempotency_key"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "then_call": {
- "maxLength": 64,
- "minLength": 1,
- "type": "string"
- },
- "url": {
- "type": "string"
- }
-}Output schema / properties / next_action / requiredRemoved value: -[
- "actor",
- "do",
- "url",
- "instruction"
-]Output schema / properties / next_step / constRemoved value: -"ask_user_payment_method"Output schema / properties / payment_options / descriptionAdded value: +"When present, ask the person which option they want; never choose for them."Output schema / properties / payment_options / items / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / payment_options / items / propertiesRemoved value: -{
- "available": {
- "type": "boolean"
- },
- "charges_without_approval": {
- "const": true,
- "type": "boolean"
- },
- "funding_source": {
- "anyOf": [
- {
- "enum": [
- "platform_test_card",
- "platform_test_wallet",
- "buyer_wallet"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "enum": [
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "paypal",
- "kyapay"
- ],
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "rail": {
- "enum": [
- "stripe",
- "x402",
- "kyapay",
- "paypal"
- ],
- "type": "string"
- },
- "reason_unavailable": {
- "enum": [
- "coming_soon",
- "not_enabled",
- "currency_not_supported",
- "unsupported_on_this_tool"
- ],
- "type": "string"
- }
-}Output schema / properties / payment_options / items / requiredRemoved value: -[
- "id",
- "label",
- "rail",
- "funding_source",
- "available"
-]ucp_create_checkout17 fields changedOutput schema / properties / extensions / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / extensions / descriptionAdded value: +"`warnings[]` with `code`, `message`, `severity`."Output schema / properties / extensions / propertiesRemoved value: -{
- "warnings": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "code": {
- "type": "string"
- },
- "disclosure_url": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "severity": {
- "enum": [
- "info",
- "caution",
- "critical"
- ],
- "type": "string"
- }
- },
- "required": [
- "code",
- "message",
- "severity"
- ],
- "type": "object"
- },
- "type": "array"
- }
-}Output schema / properties / fulfillment / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / fulfillment / propertiesRemoved value: -{
- "destination": {
- "additionalProperties": true,
- "properties": {
- "city": {
- "type": "string"
- },
- "country_code": {
- "type": "string"
- },
- "province_code": {
- "type": "string"
- },
- "zip": {
- "type": "string"
- }
- },
- "required": [
- "city",
- "country_code",
- "zip"
- ],
- "type": "object"
- },
- "options": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "authoritative": {
- "type": "boolean"
- },
- "estimated_delivery": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "source": {
- "enum": [
- "platform",
- "merchant_policy",
- "estimated"
- ],
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "title",
- "price",
- "source",
- "authoritative"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "selected_option_id": {
- "type": "string"
- }
-}Output schema / properties / intent / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / intent / propertiesRemoved value: -{
- "action": {
- "type": "string"
- },
- "context": {
- "type": "string"
- },
- "locale": {
- "type": "string"
- }
-}Output schema / properties / intent / requiredRemoved value: -[
- "action"
-]Output schema / properties / next_action / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / next_action / descriptionAdded value: +"Only when a person must approve or pay: `url`, `kind`, `retry`."Output schema / properties / next_action / propertiesRemoved value: -{
- "actor": {
- "const": "buyer",
- "type": "string"
- },
- "do": {
- "enum": [
- "approve",
- "pay"
- ],
- "type": "string"
- },
- "instruction": {
- "type": "string"
- },
- "reuse_arguments": {
- "items": {
- "enum": [
- "checkout_session_id",
- "checkout_id",
- "idempotency_key"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "then_call": {
- "maxLength": 64,
- "minLength": 1,
- "type": "string"
- },
- "url": {
- "type": "string"
- }
-}Output schema / properties / next_action / requiredRemoved value: -[
- "actor",
- "do",
- "url",
- "instruction"
-]Output schema / properties / next_step / constRemoved value: -"ask_user_payment_method"Output schema / properties / payment_options / descriptionAdded value: +"When present, ask the person which option they want; never choose for them."Output schema / properties / payment_options / items / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / payment_options / items / propertiesRemoved value: -{
- "available": {
- "type": "boolean"
- },
- "charges_without_approval": {
- "const": true,
- "type": "boolean"
- },
- "funding_source": {
- "anyOf": [
- {
- "enum": [
- "platform_test_card",
- "platform_test_wallet",
- "buyer_wallet"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "enum": [
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "paypal",
- "kyapay"
- ],
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "rail": {
- "enum": [
- "stripe",
- "x402",
- "kyapay",
- "paypal"
- ],
- "type": "string"
- },
- "reason_unavailable": {
- "enum": [
- "coming_soon",
- "not_enabled",
- "currency_not_supported",
- "unsupported_on_this_tool"
- ],
- "type": "string"
- }
-}Output schema / properties / payment_options / items / requiredRemoved value: -[
- "id",
- "label",
- "rail",
- "funding_source",
- "available"
-]ucp_get_checkout17 fields changedOutput schema / properties / extensions / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / extensions / descriptionAdded value: +"`warnings[]` with `code`, `message`, `severity`."Output schema / properties / extensions / propertiesRemoved value: -{
- "warnings": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "code": {
- "type": "string"
- },
- "disclosure_url": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "severity": {
- "enum": [
- "info",
- "caution",
- "critical"
- ],
- "type": "string"
- }
- },
- "required": [
- "code",
- "message",
- "severity"
- ],
- "type": "object"
- },
- "type": "array"
- }
-}Output schema / properties / fulfillment / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / fulfillment / propertiesRemoved value: -{
- "destination": {
- "additionalProperties": true,
- "properties": {
- "city": {
- "type": "string"
- },
- "country_code": {
- "type": "string"
- },
- "province_code": {
- "type": "string"
- },
- "zip": {
- "type": "string"
- }
- },
- "required": [
- "city",
- "country_code",
- "zip"
- ],
- "type": "object"
- },
- "options": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "authoritative": {
- "type": "boolean"
- },
- "estimated_delivery": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "source": {
- "enum": [
- "platform",
- "merchant_policy",
- "estimated"
- ],
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "title",
- "price",
- "source",
- "authoritative"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "selected_option_id": {
- "type": "string"
- }
-}Output schema / properties / intent / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / intent / propertiesRemoved value: -{
- "action": {
- "type": "string"
- },
- "context": {
- "type": "string"
- },
- "locale": {
- "type": "string"
- }
-}Output schema / properties / intent / requiredRemoved value: -[
- "action"
-]Output schema / properties / next_action / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / next_action / descriptionAdded value: +"Only when a person must approve or pay: `url`, `kind`, `retry`."Output schema / properties / next_action / propertiesRemoved value: -{
- "actor": {
- "const": "buyer",
- "type": "string"
- },
- "do": {
- "enum": [
- "approve",
- "pay"
- ],
- "type": "string"
- },
- "instruction": {
- "type": "string"
- },
- "reuse_arguments": {
- "items": {
- "enum": [
- "checkout_session_id",
- "checkout_id",
- "idempotency_key"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "then_call": {
- "maxLength": 64,
- "minLength": 1,
- "type": "string"
- },
- "url": {
- "type": "string"
- }
-}Output schema / properties / next_action / requiredRemoved value: -[
- "actor",
- "do",
- "url",
- "instruction"
-]Output schema / properties / next_step / constRemoved value: -"ask_user_payment_method"Output schema / properties / payment_options / descriptionAdded value: +"When present, ask the person which option they want; never choose for them."Output schema / properties / payment_options / items / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / payment_options / items / propertiesRemoved value: -{
- "available": {
- "type": "boolean"
- },
- "charges_without_approval": {
- "const": true,
- "type": "boolean"
- },
- "funding_source": {
- "anyOf": [
- {
- "enum": [
- "platform_test_card",
- "platform_test_wallet",
- "buyer_wallet"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "enum": [
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "paypal",
- "kyapay"
- ],
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "rail": {
- "enum": [
- "stripe",
- "x402",
- "kyapay",
- "paypal"
- ],
- "type": "string"
- },
- "reason_unavailable": {
- "enum": [
- "coming_soon",
- "not_enabled",
- "currency_not_supported",
- "unsupported_on_this_tool"
- ],
- "type": "string"
- }
-}Output schema / properties / payment_options / items / requiredRemoved value: -[
- "id",
- "label",
- "rail",
- "funding_source",
- "available"
-]ucp_update_checkout17 fields changedOutput schema / properties / extensions / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / extensions / descriptionAdded value: +"`warnings[]` with `code`, `message`, `severity`."Output schema / properties / extensions / propertiesRemoved value: -{
- "warnings": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "code": {
- "type": "string"
- },
- "disclosure_url": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "severity": {
- "enum": [
- "info",
- "caution",
- "critical"
- ],
- "type": "string"
- }
- },
- "required": [
- "code",
- "message",
- "severity"
- ],
- "type": "object"
- },
- "type": "array"
- }
-}Output schema / properties / fulfillment / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / fulfillment / propertiesRemoved value: -{
- "destination": {
- "additionalProperties": true,
- "properties": {
- "city": {
- "type": "string"
- },
- "country_code": {
- "type": "string"
- },
- "province_code": {
- "type": "string"
- },
- "zip": {
- "type": "string"
- }
- },
- "required": [
- "city",
- "country_code",
- "zip"
- ],
- "type": "object"
- },
- "options": {
- "items": {
- "additionalProperties": true,
- "properties": {
- "authoritative": {
- "type": "boolean"
- },
- "estimated_delivery": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "price": {
- "additionalProperties": true,
- "properties": {
- "amount": {
- "type": "number"
- },
- "currency": {
- "type": "string"
- }
- },
- "required": [
- "amount",
- "currency"
- ],
- "type": "object"
- },
- "source": {
- "enum": [
- "platform",
- "merchant_policy",
- "estimated"
- ],
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "title",
- "price",
- "source",
- "authoritative"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "selected_option_id": {
- "type": "string"
- }
-}Output schema / properties / intent / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / intent / propertiesRemoved value: -{
- "action": {
- "type": "string"
- },
- "context": {
- "type": "string"
- },
- "locale": {
- "type": "string"
- }
-}Output schema / properties / intent / requiredRemoved value: -[
- "action"
-]Output schema / properties / next_action / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / next_action / descriptionAdded value: +"Only when a person must approve or pay: `url`, `kind`, `retry`."Output schema / properties / next_action / propertiesRemoved value: -{
- "actor": {
- "const": "buyer",
- "type": "string"
- },
- "do": {
- "enum": [
- "approve",
- "pay"
- ],
- "type": "string"
- },
- "instruction": {
- "type": "string"
- },
- "reuse_arguments": {
- "items": {
- "enum": [
- "checkout_session_id",
- "checkout_id",
- "idempotency_key"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "then_call": {
- "maxLength": 64,
- "minLength": 1,
- "type": "string"
- },
- "url": {
- "type": "string"
- }
-}Output schema / properties / next_action / requiredRemoved value: -[
- "actor",
- "do",
- "url",
- "instruction"
-]Output schema / properties / next_step / constRemoved value: -"ask_user_payment_method"Output schema / properties / payment_options / descriptionAdded value: +"When present, ask the person which option they want; never choose for them."Output schema / properties / payment_options / items / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / payment_options / items / propertiesRemoved value: -{
- "available": {
- "type": "boolean"
- },
- "charges_without_approval": {
- "const": true,
- "type": "boolean"
- },
- "funding_source": {
- "anyOf": [
- {
- "enum": [
- "platform_test_card",
- "platform_test_wallet",
- "buyer_wallet"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "enum": [
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "paypal",
- "kyapay"
- ],
- "type": "string"
- },
- "label": {
- "type": "string"
- },
- "rail": {
- "enum": [
- "stripe",
- "x402",
- "kyapay",
- "paypal"
- ],
- "type": "string"
- },
- "reason_unavailable": {
- "enum": [
- "coming_soon",
- "not_enabled",
- "currency_not_supported",
- "unsupported_on_this_tool"
- ],
- "type": "string"
- }
-}Output schema / properties / payment_options / items / requiredRemoved value: -[
- "id",
- "label",
- "rail",
- "funding_source",
- "available"
-]complete_checkout2 fields changedInput schema / properties / save_payment_methodAdded value: +{
+ "description": "Only with PayPal at a store that charges into its own PayPal account, for a signed-in buyer (not guest access), and only when the person asked for it: true asks PayPal to save this PayPal account during this purchase, so later purchases at this store can be charged without a new approval, within per-charge and daily limits. Never set it on your own initiative. In any other case it is ignored and the response says so in details; it never causes an error.",
+ "type": "boolean"
+}Output schema / properties / detailsAdded value: +{
+ "additionalProperties": true,
+ "properties": {
+ "save_payment_method": {
+ "additionalProperties": true,
+ "properties": {
+ "reason": {
+ "type": "string"
+ },
+ "status": {
+ "const": "ignored",
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "reason"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}preview_checkout1 field changedOutput schema / properties / payment_options / items / properties / charges_without_approvalAdded value: +{
+ "const": true,
+ "type": "boolean"
+}ucp_cancel_checkout1 field changedOutput schema / properties / payment_options / items / properties / charges_without_approvalAdded value: +{
+ "const": true,
+ "type": "boolean"
+}ucp_complete_checkout1 field changedOutput schema / properties / payment_options / items / properties / charges_without_approvalAdded value: +{
+ "const": true,
+ "type": "boolean"
+}ucp_create_checkout1 field changedOutput schema / properties / payment_options / items / properties / charges_without_approvalAdded value: +{
+ "const": true,
+ "type": "boolean"
+}ucp_get_checkout1 field changedOutput schema / properties / payment_options / items / properties / charges_without_approvalAdded value: +{
+ "const": true,
+ "type": "boolean"
+}ucp_update_checkout1 field changedOutput schema / properties / payment_options / items / properties / charges_without_approvalAdded value: +{
+ "const": true,
+ "type": "boolean"
+}complete_checkout1 field changedInput schema / properties / payment_option / enumPrevious value: -[
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card"
-]New value: +[
+ "demo_card",
+ "demo_wallet",
+ "own_wallet",
+ "merchant_card",
+ "paypal"
+]preview_checkout3 fields changedOutput schema / properties / payment_options / items / properties / id / enumPrevious value: -[
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "kyapay"
-]New value: +[
+ "demo_card",
+ "demo_wallet",
+ "own_wallet",
+ "merchant_card",
+ "paypal",
+ "kyapay"
+]Output schema / properties / payment_options / items / properties / rail / enumPrevious value: -[
- "stripe",
- "x402",
- "kyapay"
-]New value: +[
+ "stripe",
+ "x402",
+ "kyapay",
+ "paypal"
+]Output schema / properties / payment_options / items / properties / reason_unavailable / enumPrevious value: -[
- "coming_soon",
- "not_enabled",
- "currency_not_supported"
-]New value: +[
+ "coming_soon",
+ "not_enabled",
+ "currency_not_supported",
+ "unsupported_on_this_tool"
+]ucp_cancel_checkout3 fields changedOutput schema / properties / payment_options / items / properties / id / enumPrevious value: -[
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "kyapay"
-]New value: +[
+ "demo_card",
+ "demo_wallet",
+ "own_wallet",
+ "merchant_card",
+ "paypal",
+ "kyapay"
+]Output schema / properties / payment_options / items / properties / rail / enumPrevious value: -[
- "stripe",
- "x402",
- "kyapay"
-]New value: +[
+ "stripe",
+ "x402",
+ "kyapay",
+ "paypal"
+]Output schema / properties / payment_options / items / properties / reason_unavailable / enumPrevious value: -[
- "coming_soon",
- "not_enabled",
- "currency_not_supported"
-]New value: +[
+ "coming_soon",
+ "not_enabled",
+ "currency_not_supported",
+ "unsupported_on_this_tool"
+]ucp_complete_checkout4 fields changedInput schema / properties / payment_option / enumPrevious value: -[
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card"
-]New value: +[
+ "demo_card",
+ "demo_wallet",
+ "own_wallet",
+ "merchant_card",
+ "paypal"
+]Output schema / properties / payment_options / items / properties / id / enumPrevious value: -[
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "kyapay"
-]New value: +[
+ "demo_card",
+ "demo_wallet",
+ "own_wallet",
+ "merchant_card",
+ "paypal",
+ "kyapay"
+]Output schema / properties / payment_options / items / properties / rail / enumPrevious value: -[
- "stripe",
- "x402",
- "kyapay"
-]New value: +[
+ "stripe",
+ "x402",
+ "kyapay",
+ "paypal"
+]Output schema / properties / payment_options / items / properties / reason_unavailable / enumPrevious value: -[
- "coming_soon",
- "not_enabled",
- "currency_not_supported"
-]New value: +[
+ "coming_soon",
+ "not_enabled",
+ "currency_not_supported",
+ "unsupported_on_this_tool"
+]ucp_create_checkout3 fields changedOutput schema / properties / payment_options / items / properties / id / enumPrevious value: -[
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "kyapay"
-]New value: +[
+ "demo_card",
+ "demo_wallet",
+ "own_wallet",
+ "merchant_card",
+ "paypal",
+ "kyapay"
+]Output schema / properties / payment_options / items / properties / rail / enumPrevious value: -[
- "stripe",
- "x402",
- "kyapay"
-]New value: +[
+ "stripe",
+ "x402",
+ "kyapay",
+ "paypal"
+]Output schema / properties / payment_options / items / properties / reason_unavailable / enumPrevious value: -[
- "coming_soon",
- "not_enabled",
- "currency_not_supported"
-]New value: +[
+ "coming_soon",
+ "not_enabled",
+ "currency_not_supported",
+ "unsupported_on_this_tool"
+]ucp_get_checkout3 fields changedOutput schema / properties / payment_options / items / properties / id / enumPrevious value: -[
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "kyapay"
-]New value: +[
+ "demo_card",
+ "demo_wallet",
+ "own_wallet",
+ "merchant_card",
+ "paypal",
+ "kyapay"
+]Output schema / properties / payment_options / items / properties / rail / enumPrevious value: -[
- "stripe",
- "x402",
- "kyapay"
-]New value: +[
+ "stripe",
+ "x402",
+ "kyapay",
+ "paypal"
+]Output schema / properties / payment_options / items / properties / reason_unavailable / enumPrevious value: -[
- "coming_soon",
- "not_enabled",
- "currency_not_supported"
-]New value: +[
+ "coming_soon",
+ "not_enabled",
+ "currency_not_supported",
+ "unsupported_on_this_tool"
+]ucp_update_checkout3 fields changedOutput schema / properties / payment_options / items / properties / id / enumPrevious value: -[
- "demo_card",
- "demo_wallet",
- "own_wallet",
- "merchant_card",
- "kyapay"
-]New value: +[
+ "demo_card",
+ "demo_wallet",
+ "own_wallet",
+ "merchant_card",
+ "paypal",
+ "kyapay"
+]Output schema / properties / payment_options / items / properties / rail / enumPrevious value: -[
- "stripe",
- "x402",
- "kyapay"
-]New value: +[
+ "stripe",
+ "x402",
+ "kyapay",
+ "paypal"
+]Output schema / properties / payment_options / items / properties / reason_unavailable / enumPrevious value: -[
- "coming_soon",
- "not_enabled",
- "currency_not_supported"
-]New value: +[
+ "coming_soon",
+ "not_enabled",
+ "currency_not_supported",
+ "unsupported_on_this_tool"
+]complete_checkout2 fields changedInput schema / properties / kyapay_token / descriptionPrevious value: -"Skyfire pay or kya-pay JWT for autonomous payment via Skyfire (payment_method=KYAPAY). This argument is the only channel for the token; no request header carries it. Claims required: sub, jti, amount (USD), cur=USD, sps."New value: +"Not available for payment: charging with KYApay is switched off, because KYApay is identity verification here, not a payment rail. A call that passes this token is rejected with PAYMENT_METHOD_NOT_CONFIGURED before anything is charged or written. The Skyfire KYA token is used for identity on the REST API, not in this tool."Input schema / properties / payment_method / descriptionPrevious value: -"Payment method to use. PAYPAL creates a PayPal order and presents approval URL. KYAPAY requires kyapay_token. ACP (Stripe-native settlement) returns a 'not enabled' response unless this deployment enables native settlement; when enabled it charges the Stripe Shared Payment Token passed as shared_payment_token. X402 is available through the configured x402 protocol flow, not this checkout tool. MOCK moves no money: it completes the order without charging. Whether a store accepts it depends on the store's configuration (it is the default on demo-store). Defaults to MOCK if not specified."New value: +"Payment method to use. PAYPAL creates a PayPal order and presents approval URL. KYAPAY is not available for payment: KYApay is identity verification here, so a request with KYAPAY is rejected without charging anything. ACP (Stripe-native settlement) returns a 'not enabled' response unless this deployment enables native settlement; when enabled it charges the Stripe Shared Payment Token passed as shared_payment_token. X402 is available through the configured x402 protocol flow, not this checkout tool. MOCK moves no money: it completes the order without charging. Whether a store accepts it depends on the store's configuration (it is the default on demo-store). Defaults to MOCK if not specified."complete_checkout1 field changedInput schema / properties / kyapay_token / descriptionPrevious value: -"Skyfire pay or kya-pay JWT for autonomous payment via Skyfire (payment_method=KYAPAY). Alternative to passing the token in the skyfire-pay-id request header — the header takes precedence if both are provided. Claims required: sub, jti, amount (USD), cur=USD, sps."New value: +"Skyfire pay or kya-pay JWT for autonomous payment via Skyfire (payment_method=KYAPAY). This argument is the only channel for the token; no request header carries it. Claims required: sub, jti, amount (USD), cur=USD, sps."Agent Commerce MCP — agent-native A2A storefront. Discovery, Stripe checkout, affiliate program.
Agentic commerce network: discover sellers and products, negotiate, and pay USDC on Base via x402.
Agentic commerce with 58 MCP tools for product search, checkout, A2A negotiation, C-Suite analytics.
The independent agent-commerce protocol for AI-agent checkout on any online store.
Add one secure layer between your agents and this server.
