Skip to main content
Glama

Pay with a card the user approves

writ_payment
Destructive

Pay on a website without card numbers reaching the chat: request user approval, then Writ fills the card and places the order after confirmation.

Instructions

Pay on a website with one of the user's cards, without the card number ever reaching this conversation: the AI never sees or asks for card numbers. action='request' (site, max_amount, purpose) returns a tell_user and an open_url: a Writ window where the user picks or adds a card (or makes a virtual card) and approves it. A purchase needs that approval. action='wait' grant_id= is ONE held call (up to 60s) that answers when they approve, with the card's brand and last four digits only. PLACING THE ORDER: action='checkout' (session on the final checkout page, commit_selector = the place-order button, total_selector = the order total, grant_id, or max_amount when the store uses its own saved card) pauses the session and the user confirms (emailed link, the Writ app, or an auto-confirm rule they turned on); then Writ types the card, checks the total and clicks the order button itself: a real purchase. You never click an order button yourself (refused). action='wait' confirmation_id= returns the outcome. action='fill' types an approved virtual card early (multi-page checkouts). Card use is limited to the site and amount granted; an unused grant expires after 15 minutes. action='list' shows the user's payment methods as handles (kind, brand, last4, id), never numbers; a handle goes into writ_wire_monitor buy.payment {kind, ref}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteNorequest: the store's domain, e.g. 'store.example.com'. The card is typed only on this site and its payment frames.
stepsNocheckout: steps Writ runs after confirmation, before the order button, e.g. [{"type":"fill_card"}, {"type":"click","selector":"#continue"}, {"type":"wait","seconds":2}] for a card page followed by a review page. Default: fill the granted card, then the order button.
actionYesrequest = ask the user to approve a card for one purchase; wait = hold until they answer (grant_id) or until a checkout is settled (confirmation_id); checkout = pause at the order button for the user's confirmation, then Writ places the order; fill = type an approved virtual card early; list = the user's payment methods as handles.
fieldsNorequest, for live browsing: card field -> CSS selector on the checkout page (read them with writ_browser_context), or {selector, frame_url} for a field inside a payment provider's frame (frame_url = part of the frame's URL, e.g. 'js.stripe.com'). Keys: number, exp (MM/YY), exp_month, exp_year, exp_year2, cvc, name, zip. Writ types into exactly these.
purposeNorequest: one line the user reads when approving, e.g. 'Buy Nike Dunk Low, size 10'.
sessionNocheckout / fill (required) / request: the session_id of the writ_browser_use session on the checkout page.
summaryNocheckout: one line the user reads when confirming, e.g. '1 x Nike Dunk Low, size 10, shipped to home'.
currencyNorequest: three-letter ISO code (default 'usd').
grant_idNowait / fill / checkout: the grant_id action='request' returned.
max_amountNorequest / checkout: the most this purchase may charge, tax and shipping included (e.g. 129.99). checkout without grant_id needs it.
automation_idNorequest: the automation the card is for, when the purchase is a saved automation.
total_selectorNorequest / checkout: CSS selector of the order total on the checkout page. Writ reads it and never clicks on when it is above the maximum. Needed for an auto-confirm rule to apply.
commit_selectorNocheckout (required): CSS selector of the button that places the order. Writ clicks it after the user confirms.
confirmation_idNowait: the confirmation_id action='checkout' returned.
payment_method_idNorequest: a handle id from action='list' to pre-select that card; the user still approves.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, openWorldHint=true), the description discloses critical behavior: card numbers never reach the conversation, card use is scoped to site and amount granted, grants expire after 15 minutes, wait is a single held call up to 60s, and checkout pauses for user confirmation before Writ places a real purchase. This is unusually rich context that annotations cannot convey.

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

Conciseness4/5

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

The opening clause front-loads the key constraint (no card numbers) and the request flow, and every sentence carries substantive information. It is dense and long, but for a 15-parameter, five-action tool this density is largely earned; slightly tighter per-action grouping would improve scanning.

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?

For a complex mutation tool with 15 parameters, nested objects, and no output schema, the description covers the entire workflow from approval to order placement and explains the return shape (brand and last four digits, confirmation outcome). Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics: which action consumes grant_id versus confirmation_id, that checkout without grant_id requires max_amount, and how commit_selector/total_selector gate the auto-confirm rule. It enriches schema-level info rather than merely repeating it.

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?

The description names a specific verb and resource (pay on a website using the user's cards) and enumerates all five actions with their distinct functions. It clearly differentiates from siblings by routing card handles into writ_wire_monitor and by referencing writ_browser_context for selector reading.

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?

Each action's use case is stated explicitly: request to obtain approval, wait to hold for a grant/confirmation, checkout to place the order, fill for multi-page checkouts, list to enumerate payment methods. It also names alternatives (writ_wire_monitor for buy.payment, writ_browser_context for reading selectors) and an exclusion ('You never click an order button yourself (refused)').

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