Dodo Payments Agent Plugin
OfficialThis server lets you search Dodo Payments SDK docs and execute TypeScript/JavaScript against the Dodo Payments API.
Search SDK documentation for methods, parameters, and usage examples across HTTP, Python, Go, TypeScript, JavaScript, Terraform, Ruby, Java, and Kotlin, with optional verbose detail.
Run TypeScript/JavaScript code in an async
run(client)function using an initialized Dodo Payments SDK client.Use the SDK client to perform Dodo Payments API operations such as creating checkout sessions and managing payments, subscriptions, customers, products, refunds, licenses, and usage.
Return or log results from executed code; variables do not persist between calls and external network access is restricted to the provided SDK client.
Provides skills and MCP servers to integrate Dodo Payments payment processing into Next.js applications, including webhook handling, checkout sessions, subscriptions, and more.
Provides skills for integrating Dodo Payments billing components using the BillingSDK React library, enabling credit-based and usage-based billing in React applications.
This server has a remotely hosted endpoint. Open its connector listing for connection details, authentication requirements, and setup instructions:
Dodo Payments Agent Plugin
The official Dodo Payments plugin for AI coding agents. Installs the Dodo Payments integration skills and two MCP servers across Claude Code, Codex CLI, Cursor, VS Code / GitHub Copilot, Grok Build, Meta Muse Code, Gemini CLI, Antigravity, Junie, OpenCode, and more, from a single source of truth.
This plugin conforms to the Agent Plugins 1.0.0 specification: a root plugin.json, skills as immediate children of skills/, and MCP servers in mcp.json. Clients with native Agent Plugins support load it directly; the provider-specific manifests in this repo are generated compatibility shims for clients that do not.
What you get
Dodo Payments API MCP server - Live API access (payments, subscriptions, customers, products, refunds, licenses, usage). Authenticates via browser OAuth, no local credentials required.
Dodo Knowledge MCP server - No credentials. Semantic search over the current Dodo Payments documentation.
Agent skills - Integration guides (listed below), written as
SKILL.mdfiles with YAML frontmatter. Your agent loads the relevant skill on its own when a task calls for it.
Related MCP server: YooKassa MCP Server
Install
Client | Skills | MCP | How |
Claude Code | ✅ | ✅ | |
Codex CLI / ChatGPT | ✅ | ✅ | |
Cursor (and Grok Bot) | ✅ | ✅ | |
VS Code / GitHub Copilot | ✅ | ✅ | |
Grok Build | ✅ | ✅ | |
grok.com, xAI API | — | ✅ | |
Meta Muse Code | ✅ | ✅ | |
Gemini CLI | ✅ | ✅ | |
Google Antigravity | ✅ | ✅ | |
JetBrains Junie | ✅ | ✅ | |
Kiro | ✅ | ✅ | |
OpenCode | ✅ | ✅ | |
Qwen Code, Devin, Goose, Factory Droid, Augment, OpenHands, OpenClaw, Hermes | ✅ | ✅ | |
Cline, Kilo, Zed, Warp, Amp, Continue, Kimi, … | ✅ | ✅ | |
Claude.ai, ChatGPT, Perplexity, Mistral | — | ✅ |
Claude Code
claude plugins marketplace add dodopayments/dodo-agent-plugin
claude plugins install dodopayments@dodopaymentsThe API MCP server signs in with OAuth, so there is no API key to paste. The first time your agent calls a Dodo tool, a Dodo Payments consent page opens in your browser: pick the business, mode and permissions. See Sign-in and access.
Codex CLI
Register the marketplace, then install the plugin:
codex plugin marketplace add dodopayments/dodo-agent-plugin
codex plugin add dodopayments@dodopaymentsVerify:
codex plugin list # dodopayments installed, enabled
codex mcp list # dodo-knowledge, dodopayments-api
codex mcp login dodopayments-api # browser OAuth, only needed for the API serverYou can also install from inside the TUI: run codex, type /plugins, select the Dodo Payments marketplace and the dodopayments plugin, then choose Install plugin.
If you added the marketplace previously and the plugin doesn't appear, refresh it:
codex plugin marketplace upgrade dodopaymentsCursor
Manual install:
git clone https://github.com/dodopayments/dodo-agent-plugin.git ~/.cursor/plugins/local/dodo-agent-pluginRestart Cursor. The plugin loads skills from skills/ and MCP servers from .mcp.json, as declared in .cursor-plugin/plugin.json.
Cursor 3.14.27 also recognises Agent Plugins 1.0.0 directly: its agent host carries both spec schema URLs and the spec's own
nameregex, and accepts either.cursor-plugin/marketplace.jsonor.claude-plugin/marketplace.jsonas a marketplace source. The generated.cursor-plugin/plugin.jsonis kept as belt-and-braces for older builds.
Prior to v0.5.0 this clone produced a plugin with no working skills:
skills/contained symlinks into a git submodule that a plaingit clonedoes not fetch. Skills are now vendored as real files, so the command above works as documented. If you installed an earlier version, re-clone.
Kiro
Kiro reads the Agent Plugins manifest natively and loads this as a Power:
git clone https://github.com/dodopayments/dodo-agent-plugin.gitPoint Kiro at the cloned folder. Skills load from skills/, MCP servers from mcp.json, and Kiro-specific presentation comes from the dev.kiro extension namespace in plugin.json.
Gemini CLI
gemini extensions install https://github.com/dodopayments/dodo-agent-plugingemini-extension.json at the repo root is the manifest, and Gemini auto-discovers the skills/ directory next to it. Verified on Gemini CLI 0.63.0: gemini skills list shows every skill and gemini mcp list shows both servers.
VS Code / GitHub Copilot
git clone https://github.com/dodopayments/dodo-agent-plugin.gitThen open the Chat view, go to Plugins, and add the cloned folder. Skills load from skills/, and both MCP servers load from .mcp.json.
VS Code 1.125.1 does not key off the Agent Plugins
$schema- the string appears nowhere in its bundle. Its loader picks a manifest by probing, in order,.plugin/plugin.json, then.claude-plugin/plugin.json, then a rootplugin.json, and defaults MCP to.mcp.jsonrather thanmcp.json. Because this repo ships a generated.claude-plugin/plugin.json, VS Code loads it through that branch. Everything works - all skills and both MCP servers - via the compatibility manifests rather than the spec ones.
OpenCode
OpenCode distributes via npm. Add the plugin to your opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"plugin": ["@dodopayments/opencode-plugin"]
}Restart OpenCode. Both MCP servers (dodopayments-api, dodo-knowledge) are registered automatically via the plugin's config hook as native remote servers. No manual mcp block required. Run opencode mcp auth dodopayments-api to open the Dodo Payments consent page for the API server.
Skills need the package installed locally plus one extra line. OpenCode does not scan installed packages for skills, so point it at the package's skills/ directory yourself. skills.paths entries resolve against the project directory, so the package must be present in the project's node_modules - OpenCode's own plugin cache is not the same location:
npm install --save-dev @dodopayments/opencode-plugin{
"$schema": "https://opencode.ai/config.json",
"plugin": ["@dodopayments/opencode-plugin"],
"skills": {
"paths": ["node_modules/@dodopayments/opencode-plugin/skills"]
}
}An absolute path works too, and avoids the local-install requirement.
Verify with opencode run "List every skill available to you by name." - you should see every skill listed under Included Skills. A skills path that does not exist is ignored silently, so check rather than assume.
Versions before 0.5.0 documented these skills as auto-discovered. They were not: nothing in OpenCode scans an installed package, so OpenCode users had MCP servers but no skills. Setting
config.skillsfrom the plugin'sconfighook does not fix this either - the skill index is built beforeconfighooks run, so it never registers anything.
Included Skills
Getting started
Skill | Description |
| SDK setup, environments, API keys, and the canonical checkout-to-webhook architecture |
| Official |
| Test mode, test payment methods, webhook testing, production launch checklist |
| When to use the documentation vs API MCP servers, test-mode safety rules, auth, troubleshooting |
Accepting payments
Skill | Description |
| Checkout Sessions, payment links, and overlay checkout |
| Subscription lifecycle, trials, plan changes, proration, on-demand charges |
| In-app checkout for React Native, Flutter, iOS, and Android |
| Receiving and verifying webhooks via the Standard Webhooks spec |
Billing models
Skill | Description |
| Credit entitlements, balances, ledger, rollover, overage, meter-based deduction |
| Meters, event ingestion, aggregation, and per-unit pricing |
| License key activation, validation, and instance management |
Catalog and pricing
Skill | Description |
| Products, pricing, add-ons, collections, images, digital delivery |
| Discount codes, eligibility, stacking, subscription-cycle limits |
| Localized pricing, adaptive currency, and purchasing power parity |
Customers and operations
Skill | Description |
| Customers, self-service portal, payment methods, wallets |
| Refunds, disputes and chargebacks, access reconciliation |
UI and integrations
Skill | Description |
| BillingSDK React components for pricing tables and billing UI |
| The |
Skills source: dodopayments/skills, vendored into skills/ as real files. Provenance (upstream commit and applied transforms) is recorded in .skills-source.json.
Included MCP Servers
Server | Purpose | Auth |
| Live API access (payments, subscriptions, customers, products, refunds, licenses, usage) | OAuth (browser) |
| Semantic search over the Dodo Payments documentation | None |
Both servers speak Streamable HTTP over HTTPS, and every manifest dials them natively - no npx mcp-remote bridge and no Node dependency. The canonical mcp.json uses the spec's type: "streamable-http"; the generated .mcp.json (Claude Code, Cursor, VS Code, Grok Build, Devin, Goose, Droid) uses the same endpoints spelled type: "http", the name that dialect uses; Muse, Antigravity, Junie and Gemini get their own spellings from the generator.
Sign-in and access
The API MCP server signs in with OAuth. No config in this plugin holds an API key, and no step asks you to paste one.
The first tool call on
dodopayments-apiopens a Dodo Payments consent page in your browser. Some clients start the sign-in from a command instead:codex mcp login dodopayments-api,opencode mcp auth dodopayments-api,muse mcp login dodopayments-api, or/mcpin Claude Code.Sign in, then pick the business, the mode (test or live) and the permissions to grant.
The client stores the token. To switch to another business or mode, sign out of the server in your client and sign in again.
To review or revoke access, open the Dodo Payments dashboard at Settings > Connected Apps.
Every client config in this repo dials https://mcp.dodopayments.com/mcp directly, sets no headers, and lets the client run OAuth discovery itself. A host that cannot run MCP OAuth gets dodo-knowledge only - today that is the xAI API (see Grok).
Dodo CLI
The skills use the Dodo CLI for local webhook testing. It uses the same OAuth sign-in:
npm i -g dodopayments-cli # browser sign-in needs v3.7.0 or later
dodo login # sign in with the browser
dodo whoami # show the stored sign-inOver SSH or with no browser, run dodo login --device in place of dodo login, and enter the code on another device. To sign out when you finish, run dodo logout all.
Enable / disable individual MCP servers
Both MCPs ship enabled by default. You can turn either one off independently.
OpenCode
The npm plugin reads two environment variables before registering MCPs:
Env var | Effect |
| Skips registering |
| Skips registering |
Truthy values: 1, true, yes, on (case-insensitive). Export the var in your shell profile or set it inline:
DODO_DISABLE_API_MCP=1 opencodeClaude Code, Codex CLI, Cursor
These clients load MCPs from the static .mcp.json shipped with the plugin. To disable a server, override its entry in your own project-level config and set "enabled": false.
Claude Code - edit .mcp.json at your project root (or run claude mcp disable dodopayments-api):
{
"mcpServers": {
"dodopayments-api": {
"type": "http",
"url": "https://mcp.dodopayments.com/mcp",
"enabled": false
}
}
}Run /reload-plugins to apply.
Codex CLI / Cursor - the same enabled: false pattern works in any project-level .mcp.json that overrides the plugin's bundled file. Restart the client after editing.
Per-MCP toggles inside the Claude Code
/pluginUI are tracked upstream in anthropics/claude-code#27105 and #46373. Until those land, theenabled: falseoverride above is the supported path.
A prompt to try first
Once the plugin is active, try:
Set up Dodo Payments webhook handlers in my Next.js app for payment.succeeded and subscription.active events.Your agent will load the webhook-integration skill, use the dodo-knowledge MCP to pull the latest payload shapes, and write a handler with signature verification following the Standard Webhooks spec.
Local development
git clone https://github.com/dodopayments/dodo-agent-plugin.git
cd dodo-agent-pluginNo submodules, no build step - skills/ is vendored as real files.
Validate the Claude Code plugin and marketplace:
claude plugin validate .Load the plugin directly for a dev session:
claude --plugin-dir ./dodo-agent-pluginVerify everything before pushing:
npm run verify # generated artifacts in sync + Agent Plugins conformanceRepository layout
Path | Role |
| Canonical. Agent Plugins v1.0.0 manifest and the version source of truth |
| Canonical. Agent Plugins v1.0.0 MCP config |
| Canonical. Skills, vendored as real files; the declared set lives in |
| Hand-authored provider extras the closed spec schema cannot express |
| Generated. Do not hand-edit - run |
| The single generator ( |
| Agent Plugins conformance validator |
| Upstream provenance for the vendored skills |
Skills are authored in dodopayments/skills and vendored here. A weekly workflow re-syncs them and opens a PR; run it on demand with the Sync skills from upstream workflow dispatch.
For maintainers
The repo is configured to publish the OpenCode npm package on every GitHub Release.
One-time setup (already done for this repo):
npm scope
@dodopaymentsexists and is owned by Dodo Payments.npm Trusted Publishing (OIDC) is configured for
@dodopayments/opencode-pluginagainstpublish-opencode.yml. No npm token is stored in the repo.
Release workflow:
Bump
versioninplugin.json(the single source of truth).Run
npm run buildto propagate it to every generated manifest.Run
npm run verify, then commit and tag.Create a GitHub Release - the
Publish @dodopayments/opencode-pluginworkflow publishes to npm with provenance.
Manual dry-run:
Workflow dispatch with
dry_run: trueto validate the release pipeline without publishing.
CI checks:
Verifyruns on every pull request and push tomain: artifact drift, Agent Plugins conformance, live JSON Schema validation, an "every declared skill, zero symlinks" assertion, per-client manifest checks (Muse, Antigravity, Junie, Gemini), and an npm payload check.The release workflow re-runs the same gates before publishing.
Resources
License
MIT - see LICENSE.
Available Tools
2 toolsexecuteAInspect
Runs JavaScript code to interact with the Dodo Payments API.
You are a skilled TypeScript programmer writing code to interface with the service. Define an async function named "run" that takes a single parameter of an initialized SDK client and it will be run. For example:
async function run(client) {
const checkoutSessionResponse = await client.checkoutSessions.create({ product_cart: [{ product_id: 'pdt_example', quantity: 1 }] });
console.log(checkoutSessionResponse.session_id);
}You will be returned anything that your function returns, plus the results of any console.log statements. Do not add try-catch blocks for single API calls. The tool will handle errors for you. Do not add comments unless necessary for generating better code. Code will run in a container, and cannot interact with the network outside of the given SDK client. Variables will not persist between calls, so make sure to return or log any data you might need later. Remember that you are writing TypeScript code, so you need to be careful with your types. Always type dynamic key-value stores explicitly as Record<string, YourValueType> instead of {}.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code to execute. | |
| intent | No | Task you are trying to perform. Used for improving the service. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns function return and console.log, handles errors, runs in container, no network outside SDK, and variable non-persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for a complex tool, front-loaded with purpose, then example, then clear bullet points. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains return values (function return and console.log). It covers all necessary context for a complex code execution tool, including environment constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even with 100% schema coverage, the description enriches parameter semantics with code structure requirements (async function named 'run'), typing advice, and example usage, going beyond the simple schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Runs JavaScript code to interact with the Dodo Payments API,' providing a specific verb and resource. It includes an example and distinguishes from the sibling tool 'search_docs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed usage guidelines: 'Do not add try-catch blocks...', 'Variables will not persist between calls,' and 'Cannot interact with network outside...', explicitly guiding when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_docsARead-onlyInspect
Search SDK documentation to find methods, parameters, and usage examples for interacting with the API. Use this before writing code when you need to discover the right approach.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The query to search for. | |
| detail | No | The amount of detail to return. | |
| language | Yes | The language for the SDK to search for. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description confirms it is a search action but adds no additional behavioral details beyond that, such as output format, pagination, or rate limits. Since annotations cover the safety profile, the description adds minimal extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no redundant wording. Every sentence contributes useful information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with a fully documented schema and no output schema, this description is sufficiently complete. It states what the tool searches for, what it returns (methods, parameters, usage examples), and when to use it, which covers the necessary context given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (query, detail, language). The description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a search of SDK documentation to find methods, parameters, and usage examples. The verb 'search' and specific resource 'SDK documentation' are explicit, and it distinguishes from the sibling 'execute' by focusing on discovery rather than running code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this before writing code when you need to discover the right approach.' This establishes a clear usage context. However, it does not explicitly mention when not to use it or name alternatives like 'execute', so it lacks full exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.3.3- First observed
execute - First observed
search_docs
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: execute runs JavaScript to interact with the API, while search_docs retrieves documentation. There is no ambiguity between them.
Both tool names use a verb-based pattern: 'execute' and 'search_docs'. This is consistent and clear, following a simple imperative style.
With only 2 tools, the set is minimal but well-scoped for its design: a single execute tool covers all API operations via code, and search_docs provides necessary documentation. This unconventional approach earns a slightly reduced score but is still reasonable.
The execute tool can perform any CRUD operation on the Dodo Payments API through TypeScript code, providing full coverage of the domain. The search_docs tool ensures agents can discover the correct methods. No obvious gaps exist.
Maintenance
Related MCP Connectors
MCP server for Lemon Squeezy — stores, products, orders, subscriptions, license keys.
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
Official MCP server for twitterapis.com. Twitter/X search, users, DMs, Grok, monitoring and writes.
Official BlindPay MCP server: stablecoin payouts, payins, quotes and customers for global payments.
Related MCP Servers
AlicenseNot gradedqualityBmaintenanceThe Dodo Payments MCP Server integrates with agentic frameworks to provide a lightweight, serverless-compatible interface for AI-driven payment operations like billing, subscriptions, and customer management. It enables autonomous agents to securely act on behalf of users using the Dodo Payments1,956 npm54Apache 2.0- AlicenseNot gradedqualityDmaintenanceMCP server for the YooKassa payment API, enabling AI assistants to manage payments, refunds, receipts, webhooks, and saved payment methods through natural language.MIT
- AlicenseNot gradedqualityBmaintenanceUnofficial MCP server for the Apps API that enables managing customers, payments, plans, coupons, and Discord integration through natural language.47 npm2MIT

OrcaRail MCPofficial
AlicenseBqualityBmaintenanceOfficial MCP server for accepting crypto payments through OrcaRail. It enables AI agents to create payment intents, manage subscriptions, handle product catalogs, and get exchange rates via natural language.26252 npmMIT