Is a Stripe refund the same as undoing a payment?

No. A refund is a separate, new transaction with its own record; the original charge still happened, and processing fees on the original charge are generally not returned. So refunding a bad charge leaves two real transactions and a net fee cost. It is compensation, not reversal — which is exactly why a human-approval gate before an agent moves money matters.

What can an AI agent do with the Stripe MCP server?

It can search Stripe docs, read account and payments data, and perform documented writes — create/update customers, invoices, products, prices, payment links, coupons, and issue refunds — bounded by the Restricted API Key or OAuth scopes it was given. Its permissions are governed by that credential, not a client-side tool list. Deeper money movement (Treasury/outbound transfers) is in preview and gated behind a waitlist.

MCP field guide / Stripe

// mcp field guide · fintech

Stripe MCP server

This is the one where an agent touches real money on a live account. The reads are harmless; the writes issue refunds and change billing state — and a refund is a new transaction, not an undo. For payments, a human checkpoint before money moves isn't optional polish; it's the control your auditor already asks for.

Maintainer: Stripe, Inc. (official) Endpoint: mcp.stripe.com · @stripe/agent-toolkit License: MIT

GUARD FIT · READ SURFACE

PASS-THROUGH

Doc search, account/balance/report reads via stripe_api_read. Genuinely low-risk — a guard should not add friction here.

GUARD FIT · FINANCIAL WRITES

STRONG

Refunds, subscription cancels, invoice void/finalize — real money and billing state. Highest blast radius and compliance weight of any MCP here.

Overall fit: STRONG — for a payments surface, unambiguously so.

What it is

Stripe ships an official integration in two shapes that expose the same tools: a hosted remote MCP server at mcp.stripe.com (OAuth or a Bearer API key) and the Stripe Agent Toolkit (@stripe/agent-toolkit) that wires those tools into function-calling frameworks. The local @stripe/mcp launcher is now a thin bridge that forwards to the hosted server. Source lives in Stripe's stripe/ai monorepo (MIT).¹²

Rather than one named tool per endpoint, the current server centers on generic stripe_api_read / stripe_api_write tools (plus a dedicated create_refund and discovery/doc-search tools), scoped to a documented list of supported API methods. Crucially, what an agent can actually do is governed by its credential — OAuth consent scopes, or a Restricted API Key (RAK) — not by a client-side allowlist. Stripe removed the old --tools flag; permissions now come from the RAK's scopes.¹⁴

Tools by risk surface

Tool / action	Risk	What it does
stripe_api_read, stripe_api_search, get_stripe_account_info, get_balance_summary, search_stripe_documentation, stripe_report	read-only	Read account, customers, charges, invoices, subscriptions, balance, payouts; search docs/API. No side effects.
stripe_api_write → create/update customer, product, price, payment link, coupon, promo code, webhook	mutating	Create/update billing objects. Mostly correctable, but real account state.
invoice: finalize / void / mark uncollectible	billing-state	Change the billable state of money owed. Not a clean undo.
cancel subscription	billing-state	Stops future billing; does not reverse charges already made.
create_refund	money moves	A first-class tool. Issues a refund — a new transaction against the original charge (see below).

Two things we did not assert (because the docs don't): (1) creating a charge / PaymentIntent is not a documented, named write capability — PaymentIntents and Charges appear as read (list/retrieve) in the supported-method set; a permissive RAK plus the generic stripe_api_write could reach further, but that's credential-dependent, not a documented named tool. (2) Treasury / outbound money movement (transfers, bill pay) is behind an agentic_treasury_preview waitlist — preview, not GA. We'd rather under-claim than overstate what an agent can do with your money.

Real use cases

Customer-service refund. Agent looks up a charge (stripe_api_read), confirms eligibility, and calls create_refund — full or partial.

Spin up a checkout. Given a product and price, the agent creates a payment link (or an invoice) and returns the URL.

Reconciliation (read-only). Pull balance, balance transactions, payouts and Checkout Sessions to answer "what did we collect yesterday" — no write risk.

Where a human-approval guard fits

For a payments surface this is unambiguously strong, and honestly so:

Highest blast radius + compliance weight. These tools move real money and mutate billing state on a live account. A wrong refund, an errant cancel, or a voided invoice has direct financial and customer impact — exactly the class of action finance and compliance want a human in front of.
Irreversibility is real. A refund does not reverse the original charge — it's a separate transaction with its own record, and processing fees on the original charge are generally not returned. "Refund to fix a bad charge" leaves two real transactions plus a fee cost. That's compensation, not reversal.
A pre-action gate is the control auditors ask for. Human sign-off before the agent moves money — with a tamper-evident record of who approved what, when — maps directly onto the maker-checker / segregation-of-duties controls payments compliance already runs on. It's materially stronger than after-the-fact detection: the money hasn't moved yet.
Stripe's own posture agrees. Stripe's docs recommend "enabling human confirmation of tools," warn about prompt injection, and push RAK-scoped least-privilege keys.¹ A guard complements that by classifying each tools/call (read vs. write vs. financial), showing the diff, and gating the financial ones — while leaving the read surface unblocked.

The honest core: for money, "we'll just undo it" is never true — a refund, a reversal, a corrective transfer are all new actions with their own fees, timing, and record. The right control is the one that acts before the money moves. That's compensation-is-not-undo, at its highest stakes.

Put a human before the money moves

Gate create_refund, cancels and invoice voids on a human; keep a tamper-evident record of every approval. Reads pass straight through.

Read the quickstart → More MCP profiles

Sources

Stripe — official MCP docs (tool table, supported API methods, auth, "enable human confirmation"): docs.stripe.com/mcp
Stripe — stripe/ai monorepo (source of truth; tools/modelcontextprotocol): github.com/stripe/ai
npm — @stripe/mcp · @stripe/agent-toolkit
Stripe — Restricted API Keys (the permission mechanism): docs.stripe.com/keys/restricted-api-keys

Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with Stripe. Capabilities reflect Stripe's docs current as of Aug 2026 and can change — check the source links for the latest. Nothing here is financial or compliance advice.