Whop MCP Tools Reference
This is not a replacement for Whop's API docs. It is a field guide for deciding which Whop MCP tool family to expose, which calls should stay read-only, and what an agent should prove before touching live seller data.
The local @whop/mcp package currently documents explicit endpoint tools, dynamic meta-tools, and code-mode tools. Exact tool availability can change by package version, client capability, transport, and filtering flags, so use this page as the planning layer and run npx -y @whop/mcp@latest --list in your environment before publishing a workflow.
Tool exposure modes
The first choice is not which endpoint to call. The first choice is how much of the Whop API surface your MCP client should see at once.
| Mode | Confirmed tools or behavior | Use when | Risk control |
|---|---|---|---|
| Explicit tools | One MCP tool per endpoint, such as list_payments or create_checkout_configurations. | The workflow needs strong schemas and a small set of known endpoints. | Filter by resource and operation before connecting a broad client. |
| Dynamic tools | list_api_endpoints, get_api_endpoint_schema, invoke_api_endpoint. | The API surface is too large for the client context window. | Require the agent to list and inspect a schema before invoking an endpoint. |
| Code mode | search_docs and execute against the TypeScript client in a Deno sandbox. | The task needs multiple API calls or a small script rather than one endpoint. | Ask for the plan, read calls, write calls, and output shape before execution. |
npx -y @whop/mcp@latest --client=cursor --tools=dynamic --operation=readCheckout tools
Checkout tools are the highest-value Whop MCP surface because they connect products, plans, payment method setup, redirect URLs, affiliate attribution, and customer-facing purchase links. Keep the first pass read-only, then gate any create or update call.
| Confirmed tool names | Read/write | Good MCP job | Approval gate |
|---|---|---|---|
list_checkout_configurations, retrieve_checkout_configurations | Read | Find active checkout configurations and verify the ch_ ID, plan, metadata, redirect URL, and purchase URL. | None beyond read-only confirmation. |
create_checkout_configurations | Write | Draft a checkout configuration for a known company and plan. | Confirm company ID, plan ID, mode, redirect URL, metadata, affiliate code, and production versus sandbox. |
list_setup_intents, retrieve_setup_intents | Read | Inspect whether a payment method setup flow completed or requires action. | Keep the agent from treating setup intent state as proof of fulfillment. |
list_payment_methods, retrieve_payment_methods | Read | Debug saved-payment-method flows without charging a customer. | Do not pair with off-session charge tools unless explicitly approved. |
For the create-checkout-configuration workflow, Whop documents required permissions including checkout_configuration:create, plan:create, access_pass:create, access_pass:update, and checkout_configuration:basic:read.
Related guide: Whop checkout via MCP.
Products and plans
Products and plans decide what a customer can buy. In MCP workflows, they are usually inspection targets: the agent should help find the right IDs and statuses before anyone changes checkout code.
| Confirmed tool names | Read/write | Use for | Permission hints |
|---|---|---|---|
list_products, retrieve_products | Read | Confirm product IDs, route-based lookup, status, and attached plan assumptions. | access_pass:basic:read |
create_products, update_products, delete_products | Write | Product creation or cleanup workflows. | Gate these behind a human review because they change what can be sold or discovered. |
list_plans, retrieve_plans | Read | Compare codebase plan_ IDs against live prices and billing behavior. | plan:basic:read |
create_plans, update_plans, delete_plans | Write | Pricing, billing interval, and availability changes. | Confirm customer-facing price, interval, currency, and product relationship. |
Payments
Payment tools are useful for support and reporting, but they need stricter controls than product lookup. A read-only failed-payment report is low risk. Refunds, retries, voids, and off-session charges are customer-impacting actions.
| Confirmed tool names | Read/write | Use for | Approval gate |
|---|---|---|---|
list_payments, retrieve_payments, list_fees_payments | Read | Revenue summaries, failed-payment diagnosis, fee review, support context. | Keep reports aggregated unless customer-level detail is needed. |
create_payments | Write | Charge an existing member off-session using a stored payment method. | Confirm member, plan, amount, payment method, and why this is allowed. |
refund_payments, retry_payments, void_payments | Write | Support operations after human review. | Show payment ID, amount, customer impact, and rollback path before calling. |
retrieve_disputes, list_disputes, update_evidence_disputes, submit_evidence_disputes | Mixed | Dispute review and evidence handling. | Submitting evidence is final enough to require explicit approval. |
Memberships
Membership tools are support tools: they explain who has access, what billing state they are in, and what might need manual action. They can also revoke or change access, so separate diagnosis from mutation.
| Confirmed tool names | Read/write | Use for | Approval gate |
|---|---|---|---|
list_memberships, retrieve_memberships, list_members, retrieve_members | Read | Support queues, access checks, account lookup, failed billing context. | Confirm the lookup target before showing private customer data. |
update_memberships, cancel_memberships, pause_memberships, resume_memberships | Write | Support actions that change access or billing state. | Confirm member ID, membership ID, timing, access effect, and customer communication plan. |
check_access_users | Read | Answer whether a user has access to a resource. | Use before changing access manually. |
Marketing and attribution
Marketing work around Whop MCP is mostly checkout attribution and promo-code inspection. The current @whop/mcp --list output exposes promo-code tools; affiliate attribution is better treated as a checkout field until a generated affiliate endpoint is visible in your local tool list.
| Surface | Confirmed tools or fields | Use for | Approval gate |
|---|---|---|---|
| Affiliate attribution | affiliate_code, affiliateCode, ?a= | Verify that checkout links, checkout configurations, and embeds preserve partner attribution. | Confirm the partner code and where attribution is stored before changing checkout. |
| Promo codes | list_promo_codes, retrieve_promo_codes, create_promo_codes, delete_promo_codes | Promo-code setup and checkout testing. | Confirm code, discount, product or plan scope, and whether archive is intended. |
| Product affiliate fields | Product response fields such as affiliate status and percentage fields. | Audit whether product-level affiliate settings match the seller's public offer. | Use product reads first; gate product updates separately. |
Finance and payout tools
Finance tools should default to read-only summaries. Transfers, withdrawals, fee markups, and payout changes should be treated as finance operations, not normal agent convenience calls.
| Confirmed tool names | Read/write | Use for | Approval gate |
|---|---|---|---|
retrieve_ledger_accounts, list_transfers, retrieve_transfers, list_withdrawals, retrieve_withdrawals, list_payout_methods | Read | Balance, transfer, payout, and withdrawal diagnosis. | Use summaries before exposing detailed ledger rows. |
create_transfers, create_withdrawals | Write | Move or withdraw funds. | Require owner approval, exact amount, origin, destination, and reason. |
create_fee_markups, list_fee_markups, delete_fee_markups | Mixed | Connected-account fee configuration. | Confirm connected account, fee type, and downstream customer impact. |
Courses and community
Course and community tools are operationally useful when support or content teams need context. Creation, deletion, moderation, and messaging should stay behind explicit approval because they change what customers see.
| Family | Confirmed examples | Good MCP job | Gate |
|---|---|---|---|
| Courses | list_courses, create_course_lessons, update_course_chapters, delete_course_lessons | Audit course structure or identify missing lessons. | Gate content changes and deletes. |
| Community | list_forum_posts, create_forum_posts, list_messages, create_messages, update_chat_channels | Summarize forum or chat context for support. | Gate posting, messaging, and moderation. |
| Notifications | create_notifications | Draft an announcement payload. | Confirm audience, message text, timing, and rollback plan. |
Apps and platform
App and platform tools matter when MCP is helping with app development, not just seller operations. They can affect API keys, app builds, webhooks, access tokens, and connected-account experiences.
| Confirmed tool names | Read/write | Use for | Approval gate |
|---|---|---|---|
list_apps, retrieve_apps, list_app_builds, retrieve_app_builds | Read | Inspect app state, builds, and debugging context. | None beyond read-only confirmation. |
create_apps, update_apps, create_app_builds, promote_app_builds | Write | Create, update, or promote app assets. | Confirm app ID, build ID, environment, and production impact. |
| Webhook receiver planning | Use Docs MCP and codebase inspection unless webhook tools appear in --list. | Audit event delivery and handler code. | Confirm URL, event list, secret handling, signature verification, and API version. |
create_access_tokens, create_account_links | Write | Generate embedded-component or account-portal access paths. | Confirm target company or user and lifetime expectations. |
Related guide: Whop API keys for MCP.
Safe prompts for tool discovery
List the available Whop MCP tools. Group them by resource family and mark each as read-only, write-capable, or unclear. Do not call any tool yet.For the checkout-related tools only, identify the exact tool name, required arguments, required permissions, and whether each call can affect a customer purchase. Do not create or update anything.Before calling a write-capable Whop MCP tool, show me the exact tool name, JSON arguments, target resource, expected customer-facing effect, and rollback or cleanup option.Use dynamic tools to list relevant endpoints first. Then fetch the schema for the single endpoint you intend to call. Stop before invoke_api_endpoint until I approve.FAQ
Is this the complete Whop API reference?
No. The official Whop docs are the canonical endpoint reference. This page is a safety and workflow map for MCP users.
Why do some tool names end in plural nouns?
The local @whop/mcp package is generated from the API client. Confirm exact names with --list because names can differ from human-readable API page titles.
Which mode should I start with?
Start with dynamic read-only discovery for broad audits, explicit tools for a known narrow workflow, and code mode only when a task needs multiple API calls in sequence.