MCP Spotlight: Dodo Payments — The First MCP Plugin That Ships 8 Skills + 2 MCP Servers Across 4 Coding Agents

Plugin: dodopayments/dodo-agent-plugin by Dodo Payments License: MIT · MCP servers: 2 · Skills: 8 · Targets: Claude Code, Codex CLI, Cursor, OpenCode MCP Tracker: glama.ai/mcp/servers/dodopayments/dodo-payments-agent Docs: docs.dodopayments.com/developer-resources/mcp-server

Every payments platform says they have an "AI integration." Most ship a thin REST wrapper, call it an MCP server, and call it a day. Dodo Payments took a different approach: they built a full plugin that distributes 8 agent skills + 2 MCP servers across 4 major coding agents from a single source of truth — Claude Code, Codex CLI, Cursor, and OpenCode. One repo, one version, four installs.

It's also the first MCP server I've seen that uses browser OAuth as the default authentication flow — no API key required at install time, no local credentials. Your agent calls a Dodo tool, you sign in once in a browser window, and the agent has scoped access. This is the pattern that will define the next generation of consumer-facing MCP integrations.

What You Get

The Dodo Payments agent plugin installs two MCP servers and eight skills:

Two MCP Servers

Server	Purpose	Auth
dodopayments-api	Live API access — payments, subscriptions, customers, products, refunds, license keys, usage-based billing	Browser OAuth (no API key required)
dodo-knowledge	Semantic search over the current Dodo Payments documentation	None (public docs)

The API server is the working surface — your agent can create checkout sessions, manage subscriptions, list customers, issue refunds, and handle license keys. The knowledge server is the documentation lookup — when the agent doesn't remember a payload shape or parameter, it queries dodo-knowledge for the current answer.

Eight Skills

Skill	Description
best-practices	Comprehensive guide to integrating Dodo Payments with best practices
checkout-integration	Creating checkout sessions and payment flows
subscription-integration	Implementing subscription billing flows
webhook-integration	Setting up and handling webhooks for payment events
usage-based-billing	Implementing metered billing with events and meters
credit-based-billing	Credit entitlements, balances, and metered credit deduction
license-keys	Managing license keys for digital products
billing-sdk	Using BillingSDK React components

Skills are written as SKILL.md files with YAML frontmatter. Your agent loads the relevant skill on its own when a task calls for it. This means the agent doesn't need to know Dodo Payments' full API surface — it reads the relevant skill, follows the pattern, and consults dodo-knowledge for parameter details.

The Browser OAuth Default

The most interesting design choice: dodopayments-api uses browser OAuth by default. No API key in your MCP config, no environment variable with a secret, no service account JSON.

1. claude plugins marketplace add dodopayments/dodo-agent-plugin
2. claude plugins install dodopayments@dodopayments
3. (first time the agent calls a Dodo tool)
4. Browser opens → you sign in → token issued → agent has scoped access

This is significant for two reasons:

1. Security: No long-lived secrets in your config files, your shell history, your MCP client config, or your dotfiles. The OAuth token is short-lived and scoped to your account.

2. Onboarding: "Install a payments MCP" stops being "create an account, generate an API key, copy-paste a 64-character string, set the right env var" and becomes "click install, sign in once." For SaaS founders evaluating payment integrations, this changes the demo flow entirely.

For users who prefer local API keys, the plugin supports both modes — you can configure dodo_api_key, dodo_webhook_key, and dodo_environment (test/live) via /plugins in Claude Code or by editing .mcp.json.

Single Source of Truth, Four Clients

The architectural innovation: one plugin repo distributes to four coding agents. The repo is structured around a dodopayments/skills git submodule (the source of truth for skill content) and a sync script (scripts/sync-manifests.mjs) that propagates version bumps to all four clients' manifest files:

Client	Install Method	Format
Claude Code	claude plugins marketplace add / claude plugins install	Marketplace + plugin JSON
Codex CLI	codex plugin marketplace add + in-TUI /plugins flow	Marketplace + plugin JSON
Cursor	git clone to ~/.cursor/plugins/local/	Local plugin directory
OpenCode	npm package @dodopayments/opencode-plugin referenced in opencode.json	npm package with config hooks

When the version bumps, the sync script ensures all four manifests stay aligned. CI runs sync-manifests.mjs --check and fails the release if anything is out of sync. The result: a single commit updates Claude Code, Codex, Cursor, and OpenCode at the same version.

This is the pattern every "integrate with our SaaS" team should copy. The current state — where every coding agent has its own plugin format, its own marketplace, its own install path — is the browser wars of agentic IDEs. The Dodo Payments plugin is one of the first I've seen that takes "write once, install four places" seriously.

Facio Integration

For the Facio HITL-first runtime, the plugin pattern is interesting because the read-side and write-side are clearly separated:

• dodo-knowledge is read-only — your agent can query the docs
• dodopayments-api is mixed — read operations (list customers, list subscriptions) are safe; write operations (issue refund, cancel subscription) are destructive and require review

For HITL gating, the destructive operations are the ones that should be confirmation-gated:

Operation	Severity	Suggested HITL Gate
List customers / products / subscriptions	Read	None — autonomous
Create checkout session	Write, idempotent	None — test mode requires confirmation, live mode requires review
Issue refund	Write, destructive	Hard confirm — irreversible
Cancel subscription	Write, destructive	Hard confirm — has user-facing consequences
Update license key	Write, destructive	Soft confirm — review intent
List usage events	Read	None

Facio's audit trail captures every Dodo call with the OAuth user identity, the tool, the parameters, the result, and the timestamp. For a payments workflow, this creates a complete chain: "Agent issued this refund at this time, for this reason, and the human approved before the call went out."

Quickstart

# Claude Code
claude plugins marketplace add dodopayments/dodo-agent-plugin
claude plugins install dodopayments@dodopayments

# Codex CLI
codex plugin marketplace add dodopayments/dodo-agent-plugin
# Then in the TUI: /plugins → select Dodo Payments → install

# Cursor
git clone https://github.com/dodopayments/dodo-agent-plugin.git \
  ~/.cursor/plugins/local/dodo-agent-plugin
# Restart Cursor

# OpenCode
npm install -D @dodopayments/opencode-plugin
# Add to opencode.json:
#   "plugin": ["@dodopayments/opencode-plugin"]

# First prompt (any client):
# "Set up Dodo Payments webhook handlers in my Next.js app
#  for payment.succeeded and subscription.active events."
#
# → Agent loads webhook-integration skill
# → Queries dodo-knowledge for payload shapes
# → Writes a Standard Webhooks-spec handler with signature verification

For local stdio mode with API keys instead of OAuth, configure via /plugins (Claude Code) or edit .mcp.json:

{
  "mcpServers": {
    "dodopayments-api": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "dodopayments-mcp@latest"],
      "env": {
        "DODO_PAYMENTS_API_KEY": "${credentials.DODO_PAYMENTS_API_KEY}",
        "DODO_PAYMENTS_WEBHOOK_KEY": "${credentials.DODO_PAYMENTS_WEBHOOK_KEY}",
        "DODO_PAYMENTS_ENVIRONMENT": "test_mode"
      }
    }
  }
}

Use Cases

SaaS checkout flow: "Add a pricing page with monthly and annual plans using Dodo Payments." Agent loads checkout-integration skill, queries dodo-knowledge for current API params, generates the checkout component, wires up webhook handlers, tests in test mode.

Subscription management dashboard: "Build an admin dashboard to view active subscriptions, cancel them, and issue refunds." Agent loads subscription-integration skill, generates the data layer using dodopayments-api MCP tools, and the UI for cancellation/refund flows with confirmation gates.

License key generation for a digital product: "I sell a desktop app. Generate license keys on purchase and validate them on app launch." Agent loads license-keys skill, generates the issue/validate endpoints, wires up the webhook for license creation.

Usage-based billing for an API product: "Charge customers per API call. Implement metered billing with monthly aggregation." Agent loads usage-based-billing skill, sets up the event ingestion, defines the meter, and tests the billing cycle.

Credit system for a generative AI product: "Customers buy credit packs, deduct credits per generation, and get notified when low." Agent loads credit-based-billing skill, sets up the entitlement model, integrates the deduction events.

Bottom Line

Dodo Payments is the first payments integration that takes "ship a real AI integration" seriously — not a thin REST wrapper, but a full plugin architecture with 8 skills + 2 MCP servers + browser OAuth + multi-client distribution from a single source of truth. The pattern is replicable: any SaaS that wants a serious AI coding agent integration should look at how this is structured.

For founders and engineers building SaaS products with payment flows, the answer to "how do I integrate payments with my agent" is no longer "write a custom integration" — it's claude plugins install dodopayments@dodopayments.

---

MCP Spotlight is a series covering servers that give AI agents real capabilities. Every server is evaluated for tool quality, distribution architecture, and integration fit with Facio's HITL-first agent runtime.