Stripe MCP server: setup, auth, production

What is the Stripe MCP server?

A Stripe MCP server implements the Model Context Protocol and exposes Stripe's capabilities as typed tools an agent can discover and call in the middle of a task. A first-party server is commonly available, so the build effort goes into scoping and audit rather than into the protocol. What this setup has in common with every other integration in the Payments & business category is covered under Payments & business on the MCP index.

A real Stripe workflow

A billing question — “why did this customer get charged twice?” — becomes a real answer: the agent reads the customer’s payment and subscription history against live data, and drafts (never executes) the refund for a human to approve.

What an agent can do with Stripe

• Let an agent answer a billing question against real data
• Investigate a failed payment or subscription state
• Draft a refund for human approval (never auto-execute)

Read-only is the right default: let the agent observe and reason first, then grant specific write actions deliberately — each behind audit logging and, for anything high-impact, human approval.

Setting up the Stripe MCP server

Use a restricted Stripe API key, read-only by default. Stripe’s restricted keys let you allow specific resources; grant read on customers/charges/subscriptions and nothing that can move money.

Auth: A restricted Stripe API key, read-only by default. Credentials belong in the environment or a secret store — never in the repo or the agent's sandbox. Wiring a server into Claude Code or Cursor is the same for every tool; the step-by-step lives in the MCP connection guide.

The risk to watch with Stripe

This is money. A key that can create refunds or modify subscriptions in an agent’s hands is unacceptable — read-only key, and any money-moving action is a human decision, full stop.

Scoping a Stripe server down

Use a restricted key with read permissions on the specific resources the agent needs, and point it at test mode first for as long as the work allows. Financial data is unusually sensitive in this context because a single charge object carries a customer identifier, an amount, and often an email address, all of which then sit in your trace store as well as in the model provider's context. Anything that moves money — refunds, charges, subscription changes — should be unreachable rather than approved, because the recovery from an agent's mistake there involves your customers rather than your engineers.

More broadly, a production-grade Stripe integration needs restricted keys, read-only defaults, and a hard gate on money-moving actions. The MCP security checklist applies to every integration — we build servers with these controls baked in.