Stripe Fraud MCP

TypeScript Model Context Protocol (MCP) server that wraps the official stripe SDK. The server focuses on fraud and Radar operations while still exposing a raw request tool that lets an LLM call any Stripe REST endpoint. It is designed to run locally or inside Smithery for hosting.

Features

stripe_fraud_insight – Given a payment_intent_id or charge_id, pulls Radar early fraud warnings, risk scores, disputes, refunds, and reviews, then returns a recommendation (refund, manual_review, or monitor).
stripe_create_refund – Creates refunds against a charge or payment intent, supporting partial amounts, reasons, and metadata.
stripe_raw_request – Full access to the Stripe API via stripe.rawRequest, so you can reach any endpoint that is not yet wrapped in a specialized tool.
Built for Smithery (stdio + Streamable HTTP builds) so you can host it as a managed MCP service without writing glue code.

Prerequisites

Node.js 20+
Stripe secret key with the necessary permissions.
Smithery CLI (npx @smithery/cli) for local builds and development.

Smithery Configuration

The Smithery runtime picks up the configuration schema that lives in src/index.ts. When you install or run the server you will be prompted for:

Config key	Required	Description
`stripe_api_key`	✅	Secret key used to authenticate Stripe requests.
`stripe_api_version`	❌	Optional API version override (defaults to your account version).
`default_stripe_account`	❌	Optional connected account ID used when a request does not specify one.
`log_level`	❌	Minimum log level to emit ( `debug` , `info` , `warn` , `error` ). Defaults to `info` .

The repository includes smithery.yaml, so Smithery knows to treat it as a TypeScript project and to compile from src/index.ts.

Local Development

npm install npm run dev # wraps `smithery dev`

smithery dev will prompt for your configuration values (or you can provide a --config file). It spins up both stdio and SHTTP transports so you can test with smithery proxy, Claude Desktop, or any MCP client.

Building for Deployment

npm run build:stdio – Produces .smithery/stdio/index.cjs for stdio transport.
npm run build:shttp – Produces .smithery/shttp/index.cjs for Streamable HTTP transport.
npm run build – Builds both artefacts.

When you push to Smithery, it runs the same build pipeline and hosts the generated artefact automatically.

Tool Reference

`stripe_status`

Input: Optional stripe_account override.
Output: Current server time, effective configuration (API version, log level, default account), and key flags from the Stripe account (charges/payouts enabled). Useful for quick health checks in Smithery.

`stripe_fraud_insight`

Input: payment_intent_id or charge_id (one required), include_events (boolean, default true).
Output: Structured fraud/risk summary with Stripe Radar data and an automated recommendation.

`stripe_create_refund`

Input: payment_intent_id or charge_id, optional amount, reason, metadata.
Output: Created refund plus Stripe response metadata.

`stripe_raw_request`

Input: HTTP method (GET, POST, DELETE), path, optional query, payload, idempotency_key, stripe_account, api_version.
Output: Raw response body and headers so you can reach any Stripe endpoint from the LLM.

Project Scripts

npm run dev – Runs smithery dev for interactive local development.
npm run build – Builds stdio and SHTTP bundles under .smithery/.
npm run build:stdio / npm run build:shttp – Build individual transports.
npm run typecheck – TypeScript diagnostics without emitting files.

Logging

The server emits structured JSON logs with timestamps, logger names, and context to make triage in Smithery or other observability tooling straightforward.
Set log_level in the Smithery configuration to control verbosity; debug includes every Stripe call and fraud-analysis step, while info surfaces tool invocations and outcomes.
Sensitive values (Stripe API keys, tokens, etc.) are automatically redacted from logged context.

Next Steps

Add additional purpose-built tools for dispute responses, Radar rule management, value list operations, etc., by wrapping the official SDK in new MCP handlers.
Implement optional caching or memoization if you anticipate repeated lookups.
Instrument with logging/observability before production use.