Trusty Squire

Trusty Squire is an MCP server that lets Claude Code, Codex, Cursor, OpenCode, Goose, and other coding agents sign up, provision, and purchase on your behalf. It opens a real browser, works through signup, sign-in, setup, and checkout flows one step at a time, clears the bot-detection and email-verification steps that make operator tools stall, and hands the job back to a person only when one is actually required. That covers wiring up OAuth and API keys for the app you're building as much as it covers paying a checkout, sending a gift, or booking something — the same operator primitives drive all of it.

Provider secrets and payment cards are write-only: the agent's credential tools return references and authenticated results, never stored plaintext. The raw secret never needs to enter the agent's context, so it can't be pasted into a commit, leaked in a log, or read back out over chat. When a task genuinely needs the plaintext somewhere the agent controls, fetch_credential releases it — for one credential, once, and only after you sign that exact request with your passkey. Backend access is a host-scoped, rate-limited, independently revocable grant, so a leaked token is killed without rotating the provider key — and you connect Google or GitHub yourself in a real browser, so the agent never types your password. Full threat model below.

Direct payment observation

The agent drives the live checkout from ordinary browser evidence. It reads the amount, currency, DCC choice, card controls, validation errors, requests, and rendered state with operate_observe, operate_network, and operate_screenshot, then uses the ordinary click, type, select, press, scroll, and wait loop to advance the purchase. A spinner is evidence; the operator does not translate it into a payment stage.

When card fields are ready, call list_payment_cards and then inject_card with the addressed session, the purchase terms, the selected card_ref, and an observation ref for each field to fill. inject_card uses the existing single human approval for that purchase, verifies the signed release, and opens the card only inside the operator. A pending approval is resumed with the returned approval_id; retries may supply changed field refs under that same still-valid approval. The primitive fills only the named fields and returns a per-field filled, not_found, detached, or native_error result. It never searches for a provider, chooses a saved-card UI, rereads the total, submits, clears fields, or diagnoses the checkout.

Hosted-field providers can render decoy autofill or focus-helper inputs beside the actual field (notably Braintree and Stripe). Choose the ref for the visible card control, not a helper input. Before placing the order, re-observe and confirm that no competing merchant-saved-card radio or option remains selected. If a 3-D Secure challenge appears, the operator detects it on the next observation or action result, notifies the cardholder once through the purchase notification path, and reports three_ds with state challenge_detected; keep observing the live checkout while the cardholder completes it. three_ds can also carry state sdk_error_retryable: no challenge rendered and nothing notified, because the processor's own SDK failed to launch its challenge UI (e.g. THREEDS_CARDINAL_SDK_ERROR in the page's error telemetry). That failure is transient — the checkout re-arms, and resubmitting the payment is expected to launch the challenge. It is advisory only: nothing is gated, and a detected challenge always takes precedence. Once a challenge has rendered in the session, the advisory is never reported again, so a resubmit prompt can never ride a checkout that already completed one.