Human-in-the-loop payment boundaries for MCP agents

The boundary is a handoff, not an agent-completed card charge

For OfflineCreator Studio, a connected MCP agent can inspect models and credits and start generation work, but the published MCP tool list does not give that agent a card payment instrument. The current `@offlinecreator/mcp@0.1.2` README lists tools for model discovery, credit reads, generation, upload, status, waiting, output download, cancellation, and recent-generation listing. That published tool list does not include Stripe Checkout creation, so card funding remains outside the MCP action set. Returning a purchase link from an approved surface means a human payment flow may be available; it does not mean money moved or credits were granted.

Keep a separate exception for the optional x402 rail. When a deployment enables x402 and a stdio MCP or CLI session has a local buyer wallet configured, an HTTP 402 that carries `PAYMENT-REQUIRED` can be settled in USDC without a browser. That is still not card checkout inside the MCP client: the wallet key stays in the agent environment, API-key auth still runs first, and a client-side spend cap limits each payment. Stripe Checkout and Studio Buy actions remain the human rail.

Machine action

Detect a shortfall and present an approved handoffA balance read or purchase URL is not settlement proof.

Human action

Review the destination and complete or decline paymentPayment details stay in the out-of-band browser flow.

Later verification

Re-read account creditsUse a later balance read as a separate observation; this research establishes no fulfillment interval.

Payment credentials belong outside the MCP client

This separation is also a protocol-level security boundary, not merely a user-interface preference. The current MCP 2026-07-28 elicitation specification says servers must not use form-mode elicitation to request passwords, API keys, access tokens, or payment credentials. Sensitive interactions must use URL mode, which directs the user to an external location so those details do not pass through the MCP client. The specification describes payment processing as a direct use case for that out-of-band pattern.

URL mode still requires scrutiny. The specification requires a client to show the full URL before consent, forbids opening it without explicit user consent, and requires a secure opening method that does not let the client or model inspect the page content or user inputs. A safe agent can explain why a top-up is being proposed, show the destination, and wait. It should not ask the person to paste card data, bank credentials, one-time codes, or the completed payment form back into chat.

Safe context

Reason, observed shortfall, expected destinationEnough information for the person to evaluate the proposed handoff.

Excluded context

Payment credentials and secure-page inputsThese must not be collected through MCP form elicitation or model conversation.

Pin the package version before assuming a CLI checkout path

Top-up CLI and API evidence is version-sensitive. The immutable published `@offlinecreator/mcp@0.1.1` README stated that top-up discovery and Checkout creation were CLI/API features rather than MCP tools, returned a URL for a human browser action, and did not let agents charge a payment method directly. That release’s CLI exposed `topups` and `topup --id …`, and its client methods mapped those commands to `GET /api/v1/topups` and `POST /api/v1/checkout/topup`. That is historical package evidence for a handoff path, not permission for an MCP agent to operate a payment instrument.

The current `@offlinecreator/mcp@0.1.2` thin CLI help and command switch expose only `models`, `balance`/`credits`, and `generate [--wait]`. The 0.1.2 client no longer includes `listTopUps` or `createTopUpCheckout`. Do not tell operators that latest `npx @offlinecreator/mcp topup` is a verified current path. If an operator still runs 0.1.1, pin that version explicitly before using its documented checkout-link commands, then treat any returned URL as a human browser handoff rather than settlement.

0.1.1 handoff (version-pinned)

`topups` / `topup --id …`Immutable 0.1.1 client paths: GET /api/v1/topups and POST /api/v1/checkout/topup.

0.1.2 thin CLI

`models`, `balance`/`credits`, `generate`No published top-up or Checkout subcommands in the current package surface.

Do not invent MCP payment tools from a CLI package name

The package starts an MCP stdio server when it is launched without a CLI command, but that server registers a different surface from any CLI parser. In 0.1.2, the published MCP tool roster covers model discovery, credit reads, generation submission and input upload, generation status and waiting, output download, cancellation, and recent-generation listing. There is no top-up-discovery or Checkout-creation tool in that roster. The same exclusion held in the immutable 0.1.1 README, which named top-ups as CLI/API features rather than MCP tools even while that older CLI still exposed checkout-link commands.

That distinction prevents a misleading shortcut. Running the same npm package in stdio mode does not make every CLI branch discoverable through `tools/list`, and possession of a `generate` scope does not imply a payment capability. An MCP client should use `get_credits` to inspect the balance it is authorized to read. If the result is insufficient, it can stop and direct the operator to an approved human-facing path; it cannot invent `list_topups` or `create_topup_checkout` as server tools.

MCP account signal

`get_credits`Reads the current balance when the exposed tool and scope permit it.

Not in the published MCP registry

Top-up discovery and Checkout creationUse a human Studio purchase surface or a version-pinned older CLI handoff; do not fabricate tools.

Consent to open a URL is not confirmation of payment

MCP’s URL-mode elicitation model draws another useful line: an `accept` response records consent to the interaction, but the specification says it does not mean the out-of-band interaction is complete. The client is not directly informed of the outcome merely because the user accepted the handoff. On retry, the server must determine whether the external interaction finished and may return another input-required result. Clients should provide controls to retry or cancel.

OfflineCreator’s published 0.1.2 package excludes top-up discovery and Checkout creation from its MCP tools and does not document an MCP elicitation implementation for top-ups. Apply the protocol pattern here only as guidance: do not convert “link opened,” “user accepted,” or “browser returned” into “payment succeeded.” A later `get_credits` call can provide a separate balance observation, but the reviewed sources establish neither when OfflineCreator grants credits nor how quickly a changed balance should appear. Until the operator independently confirms the outcome, report an unresolved state instead of repeatedly creating links.

Accepted

The user agreed to enter the external flowThis is not a settlement or balance-change signal.

Completed

The out-of-band system confirms its own resultVerify account state separately before resuming paid work.

Use a bounded decision path when credits are insufficient

The following is a recommended workflow, not a checkout sequence tested during this research. Begin with the intended generation requirement and a fresh balance read. If the observed balance is insufficient, inspect whether the 402 carries `PAYMENT-REQUIRED`. Without that header, stop before submission, state the shortfall, and ask whether the operator wants to review current Studio or Stripe purchase options. Keep the operator’s choice explicit before any card handoff.

If `PAYMENT-REQUIRED` is present and the operator intentionally configured a wallet for stdio MCP or CLI, follow the x402 settlement path instead of inventing a card tool. After either browser completion or wallet settlement, a later `get_credits` call can produce another balance observation before generation resumes. Do not loop on Checkout creation or assume fulfillment from a returned Stripe URL alone.

Canonical boundary for MCP payment guidance

This page owns the narrow question `mcp human in the loop payments`: why a Stripe Checkout URL or Studio Buy suggestion is a controlled human handoff rather than evidence that an MCP agent completed a card charge, and how that differs from optional x402 USDC settlement outside the MCP tool list. OfflineCreator’s published package supports the MCP exclusion by listing generation and account-read tools without Stripe Checkout tools. Outcome checking language on this page is guidance, not a claim that an OfflineCreator payment workflow was executed during research.

Research limitation: the degraded last30days run supplied no OfflineCreator-specific community evidence for payment preferences or outcomes. Product dual-rail language on this refresh is aligned with the public x402 agent-payments page. Consolidation into the parent remains an editorial instruction if future first-party evidence no longer supports a distinct payment-boundary page.