Skip to main content
Glama

Open a purchase hold

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.8/5.0
Behavior5/5

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

Annotations only convey readOnly/write, openWorld, idempotency, and destructiveness. The description adds substantial non-obvious behavior: funds sit in escrow and reach the shop only when the buyer acts; the platform cannot move them; a 72-hour default window auto-refunds; never-funded holds lapse; multi-recipient splits are sealed at open; the release code goes only to the buyer's email; mandate ceilings are checked before opening; holds cannot be topped up. This is exactly the kind of behavioral disclosure agents need beyond the structured annotations, and it does not contradict them.

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

Conciseness1/5

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

This is a ~350-word unbroken wall of text with excessive ALL-CAPS emphasis, run-on sentences, and repeated points ('This is not a purchase' and 'the money stays the buyer's' each appear twice). It reads as a defensive legal lecture rather than a tool specification. The tool's actual purpose appears only near the end, violating front-loading, and the opening 'WHAT BECOMES OF THE MONEY...' is the last thing an agent needs first. Nearly every sentence could be cut by half without losing meaning.

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?

Despite its poor structure, the description is substantively complete for a tool with 8 parameters, nested objects, and no output schema. It covers prerequisites (concierge_ask, shipping_options/rate_token), failure modes (lapse, refusal, expiry), output expectations ('You get back the order reference, the escrow address, the amount and a funding transaction'), and funding responsibility. It lacks error-case details and idempotency caveats, but the operational context an agent needs to call it correctly is present.

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

Parameters3/5

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 all 8 parameters thoroughly — including buyer_wallet ('your own purse... you fund it yourself'), rate_token requirements, and buyer_email routing. The description mostly restates these points (e.g., 'FUND IT YOURSELF when buyer_wallet is your own PURSE') rather than adding new parameter-level meaning. It adds minor safety color ('Hand the funding transaction over ONLY when the wallet is your human's own') but does not compensate beyond the 100% coverage baseline.

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 does state a specific verb and resource — 'Open a REVERSIBLE escrow hold on goods' — and differentiates from siblings with 'This is not a purchase: the money stays the buyer's until THEY act.' However, this core statement is buried deep in the middle of the text rather than front-loaded, and the opening paragraph is about money mechanics rather than function. Sibling differentiation is implicit ('not a purchase') but no sibling is named directly.

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

Usage Guidelines4/5

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

Gives explicit when-to-use guidance naming siblings: 'Use concierge_ask first to know stock and fit' and 'Anything PHYSICAL needs a rate_token from shipping_options first.' It also provides a when-not boundary ('This is not a purchase') and funding-responsibility context. It doesn't explicitly contrast checkout_intent against booking_intent/booking_offer, but the prerequisites and exclusions it names are actionable.

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