stripe-mcp
Stripe's official agent toolkit, which includes an MCP server. Read customer / charge / subscription data; create products and prices; refund. Restricted-key authenticated.
Default for any agent that touches payment data. Use restricted keys per agent scope; never give an agent access to live full keys.
What it does
Stripe’s agent-toolkit package ships an MCP server alongside framework SDKs. Tools cover customer search, charge / payment / subscription queries, product / price management, refund creation, and dispute responses. Auth is a restricted Stripe API key.
When you actually need it
Three patterns I’ve seen work:
- Customer support copilot. Agent reads recent charges + subscription state, drafts a customer-facing reply. Read-only key. Drafts go into a CRM tool (not auto-sent).
- Refund triage. Agent reads a refund-request thread, pulls relevant charges, drafts the refund + amount. Human approves before the agent calls the actual refund API.
- Subscription analysis. Agent answers “how many subscribers signed up this month, by tier” from real Stripe data.
Setup
Create a restricted key at dashboard.stripe.com/apikeys → “Create restricted key”. Pick the minimum scopes:
- Read-only analyst: Customers Read, Charges Read, Subscriptions Read. Nothing else.
- Refund operator: plus Refunds Write, plus a host-level approval gate.
- Test-mode-only: restricted key from test environment. Always start here.
"stripe": {
"command": "npx",
"args": ["-y", "@stripe/agent-toolkit-mcp"],
"env": {
"STRIPE_SECRET_KEY": "rk_test_…"
}
}
The catch
Restricted keys are the safety lever. Stripe makes it easy to do the right thing — if you take five minutes to scope the key properly. Common mistakes:
- Reusing your full secret key “just for development”. No. Always restricted, even in test mode.
- Granting Refunds Write without approval gates. A compromised agent can refund millions of dollars in a script.
- Test-mode keys in production agents. Stripe test mode doesn’t move real money — but it also doesn’t see real customers. Once you’re past development, switch to a live restricted key, not the test full key.
For PCI-sensitive deployments: Stripe handles cardholder data; the MCP server itself doesn’t touch card numbers (you don’t get them). PII (customer names, emails) does flow through tool results. Treat tool output as protected data — log appropriately, don’t post to public channels.
FOR: Stripe operations using a properly-scoped restricted key, with destructive tools gated by host-level approval.
Use restricted keys exclusively. Start with read-only scopes; add Write scopes only when you genuinely need them. Test in test mode first. Add a 'never refund > $X' rule for unsupervised agents that have refund authority.
Stripe restricted keys are best-in-class for fine-grained scoping. Use them — never live full secret keys.
api.stripe.com only.
Restricted keys are scoped per-resource and per-permission (Customers:Read, Refunds:Write, etc.).
Per the restricted key scope. Defaults are narrow if you scope properly.
Customer descriptions, charge metadata, dispute reason fields can contain user-authored text. Treat as untrusted.
Stripe SDK + MCP SDK as direct deps.
Stripe rate limits per API key — typically generous, but bulk operations can throttle.
npm package with provenance attestations.
Stripe's responsible disclosure policy applies.
Stripe's API request logs apply (governed by Stripe's privacy policy + PCI compliance).
Stripe's infrastructure. PCI-regulated for cardholder data.
4 present · human approval optional
create_refundcancel_subscriptionupdate_customercreate_dispute_response
NOT A FORMAL SECURITY AUDIT · Adoption posture based on public-source review · See methodology for what's measured and what isn't