Skip to main content
Glama

checkout_intent

WHAT BECOMES OF THE MONEY, so you can tell your human before they agree: it sits in an on-chain escrow that stays THEIRS, and it reaches the shop only when the buyer themselves acts on the link in their own mail — this platform cannot move it, by construction, which is why that link never comes to you. If nobody acts before the window closes (72 hours by default), the hold goes home to the buyer on its own: nobody has to ask, and nobody can hold it open. One never funded simply lapses. Where a shop divides a sale between people, those shares and addresses are SEALED when the hold opens and cannot be amended afterwards. Open a REVERSIBLE escrow hold on goods for the person you shop for. This is not a purchase: the money stays the buyer's until THEY act — the code that completes the order goes to the BUYER's email (never to you), and a hold nobody funds or confirms simply expires back to its owner. FUND IT YOURSELF when buyer_wallet is your own PURSE. You get back the order reference, the escrow address, the amount and a funding transaction, and paying it is YOUR job: then your human's only act is confirming or refusing from the mail — the money is already in escrow and they never touch a wallet. That is what the hold is for. A purse can only ever move money into a place a human decides, so funding a hold is not spending, which is why holding money is safe for you and not for a push payment. If a mandate covers your purse its per-order and per-period ceilings are checked BEFORE anything opens, and a refusal costs nothing. Hand the funding transaction over ONLY when the wallet is your human's own. Anything PHYSICAL needs a rate_token from shipping_options first — the hold is struck at an exact amount and cannot be topped up, so the postage has to be inside it. Use concierge_ask first to know stock and fit; quote prices honestly from what this returns.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
shopYesthe shop's slug
itemsYeswhat to hold — listing ids from the shop's public shelf (concierge_ask's live.goods rows carry them)
becauseNoone plain sentence naming the brief-line that drove this buy (e.g. 'within the tees ceiling of $40.00') — it rides the order email so your human reads WHY, in their own document's words
ship_toNoshipping address, REQUIRED for anything physical — pass it as an object, not as text
fund_assetNowhat the funding wallet SPENDS: 'xlm' (default), 'usdc' or 'eurc' — the hold itself is always denominated in XLM; a non-XLM choice funds it by path payment from that asset
rate_tokenNothe shipping token from shipping_options, for the service you picked. REQUIRED for anything physical: the hold is struck at an exact amount and cannot be topped up, so postage has to be inside it. It is bound to the address you priced against — pass the same `ship_to` object back.
buyer_emailYesthe buyer's REAL email — the release code lands there, and without it the order can never settle
buyer_walletYesthe wallet this hold REFUNDS to (G + 55 base32) — your own purse when you hold one, and then you fund it yourself; otherwise the buyer's own key

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

The description extensively discloses behavioral details beyond the annotations: funds sit in escrow, only the buyer's action releases the money, platform cannot move it, hold expires in 72 hours with automatic refund, shares are sealed at hold opening, and funding a hold is not spending. These side effects are not captured by the annotations (readOnlyHint=false, openWorldHint=true, etc.) and add significant transparency, though the presentation is somewhat chaotic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The description is excessively long, repetitive, and poorly structured. The same escrow mechanics are repeated multiple times (e.g., 'money stays the buyer's until THEY act' and the release code going to buyer email appear twice). The important purpose statement is not front-loaded; the description opens with a preamble about 'WHAT BECOMES OF THE MONEY' instead of stating the tool's function. This is not concise writing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description covers expected returns ('order reference, the escrow address, the amount and a funding transaction'), prerequisites (rate_token for physical goods, shopping_options), and edge cases (unfunded hold lapses, refusal costs nothing, shares cannot be amended). It provides a fairly complete picture for an agent to invoke the tool correctly, despite the disorganized exposition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description enriches several parameters: `buyer_wallet` is the refund address, `rate_token` is bound to the ship_to address, `fund_asset` determines what the wallet spends, and `buyer_email` receives the release code. This adds context beyond the schema's own field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Open a REVERSIBLE escrow hold on goods for the person you shop for' and explicitly contrasts it with a purchase ('This is not a purchase'). However, the key statement is buried deep in a long, rambling paragraph, and it does not explicitly differentiate from sibling tools like booking_intent or checkout_status, though the core function is discernible.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides useful prerequisites and conditions: 'Use concierge_ask first to know stock and fit', 'Anything PHYSICAL needs a rate_token from shipping_options first', and 'FUND IT YOURSELF when `buyer_wallet` is your own PURSE.' It does not, however, compare this tool to alternatives or state when to choose it over siblings, so usage guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources