Skip to main content
Glama

Request a purchase

request_purchase

Submit a purchase request. Returns approved, pending_review, denied (with reason), or failed (a recoverable error, safe to retry, though some failures such as a missing Privacy.com key need the account owner to fix a setting first). A request that looks like a duplicate of another recent purchase on the account (same merchant and amount) is NOT auto-approved — it is escalated to pending_review for the account owner to approve, so poll check_status rather than retrying. IMPORTANT for retries: pass a stable idempotency_key that identifies this one distinct purchase intent, and reuse the SAME key if you retry after a timeout or error. Retries with the same key never issue a second card or charge a second fee — they return the original request's result. Use a fresh key only for a genuinely new, separate purchase. After every checkout attempt with a card from retrieve_card, call report_purchase_outcome with the result, whether it went through or not.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "merchant_url": "<merchant_url>",
      "amount": "<amount>",
      "description": "<description>",
      "justification": "<justification>",
      "merchant_country_code": "<merchant_country_code>"
    },
    "name": "request_purchase"
  }
}

Input Schema

NameRequiredDescriptionDefault
amountYesPurchase amount in the specified currency
currencyNoISO 4217 currency code, defaults to USD
descriptionYesWhat is being purchased
merchant_urlYesThe merchant's full URL, including https:// (e.g. https://amazon.com, https://aws.amazon.com). Required. A bare domain such as amazon.com is still accepted and treated as https://amazon.com. Its hostname is used for whitelist/blacklist matching with subdomain support, so 'amazon.com' on the whitelist allows https://aws.amazon.com.
category_hintNoMerchant category slug (e.g. cloud_compute, software_saas)
justificationYesWhy this purchase is needed. Required for all requests
merchant_nameNoOptional human-readable merchant name (e.g. 'AWS', 'GitHub')
idempotency_keyNoStable key for this one purchase intent. Reuse the SAME key when retrying so retries don't double-charge or double-issue a card (the server dedups on it atomically). Generate a fresh key only for a genuinely new purchase. Independent of the key, the server also runs a best-effort near-duplicate check on (merchant, amount) across the whole account and escalates suspected duplicates to pending_review for the account owner to decide; passing a stable key is still strongly recommended because it is the only fully atomic protection against concurrent double-submits.
merchant_country_codeYesISO 3166-1 alpha-2 country code of the MERCHANT (the store being purchased from, not the user's country). Required. Examples: 'US', 'GB', 'DE', 'CA', 'AU'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / category_hint / maxLength
      Added value: +64
    • addedInput schema / properties / currency / pattern
      Added value: +"^[A-Za-z]{3}$"
    • addedInput schema / properties / description / maxLength
      Added value: +500
    • addedInput schema / properties / justification / maxLength
      Added value: +2000
    • addedInput schema / properties / merchant_name / maxLength
      Added value: +200
    • addedInput schema / properties / merchant_url / maxLength
      Added value: +2048
  2. Changed1 schema field changed
    • changedInput schema / properties / merchant_url / description
      Previous value: -"Merchant domain (e.g. amazon.com, aws.amazon.com). Required. Used for whitelist/blacklist matching with subdomain support, so 'amazon.com' on the whitelist allows aws.amazon.com."New value: +"The merchant's full URL, including https:// (e.g. https://amazon.com, https://aws.amazon.com). Required. A bare domain such as amazon.com is still accepted and treated as https://amazon.com. Its hostname is used for whitelist/blacklist matching with subdomain support, so 'amazon.com' on the whitelist allows https://aws.amazon.com."
  3. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Stable key for this one purchase intent. Reuse the SAME key when retrying so retries don't double-charge or double-issue a card (the server dedups on it atomically). Generate a fresh key only for a genuinely new purchase. Independent of the key, the server also runs a best-effort near-duplicate check on (merchant, amount) across the whole account and escalates suspected duplicates to owner approval; passing a stable key is still strongly recommended because it is the only fully atomic protection against concurrent double-submits."New value: +"Stable key for this one purchase intent. Reuse the SAME key when retrying so retries don't double-charge or double-issue a card (the server dedups on it atomically). Generate a fresh key only for a genuinely new purchase. Independent of the key, the server also runs a best-effort near-duplicate check on (merchant, amount) across the whole account and escalates suspected duplicates to pending_review for the account owner to decide; passing a stable key is still strongly recommended because it is the only fully atomic protection against concurrent double-submits."
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare openWorldHint and readOnlyHint=false; the description adds substantial behavior: the full outcome taxonomy, that 'failed' is retry-safe except for account-owner-fixable problems like a missing Privacy.com key, and that same-key retries return the original result without issuing a second card or fee. The near-duplicate (merchant, amount) escalation rule is a non-obvious side effect disclosed upfront.

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

Conciseness4/5

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

Front-loaded with purpose and return values, then retry guidance and follow-up call — a sensible order. It is dense and each sentence carries operational weight, though the idempotency explanation is repeated between description and schema and could be trimmed.

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

Completeness5/5

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

No output schema exists, yet the description covers return values, failure classification, retry safety, duplicate-escalation behavior, and the mandatory follow-up call to report_purchase_outcome. For a 9-parameter mutation tool with real-money consequences, this is complete enough to call correctly on the first try.

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 every parameter, including idempotency_key's atomic dedup and the merchant_url hostname matching rule. The description's parameter talk largely restates the idempotency semantics in workflow language rather than adding new field-level meaning, so baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Submit a purchase request') and immediately enumerates the four possible outcomes (approved, pending_review, denied, failed). This makes it clearly distinct from siblings retrieve_card, check_status, and report_purchase_outcome, which are named in the workflow.

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

Usage Guidelines5/5

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

Gives explicit when/when-not routing: duplicate-looking requests are escalated, so 'poll check_status rather than retrying', and after any checkout with a card from retrieve_card the agent must call report_purchase_outcome. Retry policy is spelled out concretely, including when to reuse versus mint a fresh idempotency_key.

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.