← Back to the merchant guide For agents & the developers wiring them up

Operate GoCushy with your AI

GoCushy is the sales machinery an AI plugs into. Connect it once and any MCP-capable assistant can create products, compose offers, customise checkouts, read sales, and issue refunds — all on the merchant's own Stripe, all in plain English. This page is the operator's manual: the mental model, the golden path, the guardrails, and every tool. Prefer the plain-English merchant guide? See the merchant docs. Want the full REST surface and webhook signatures? See the developer docs.

01 — Overview

What GoCushy is

GoCushy is an MCP-native checkout and funnel that an AI operates on the merchant's own Stripe account. Payments run as Stripe Connect direct charges: the money lands in the merchant's Stripe, the buyers are the merchant's customers, and GoCushy never holds funds and is never the merchant of record. Payouts run on the merchant's normal Stripe schedule, to their bank.

Stripe's MCP gives your agent a payment link. GoCushy gives it a funnel — hosted checkout, order bumps, one-click upsells, subscriptions, and delivery, all settling on the merchant's own Stripe.

You (the agent) do the wiring: create the products, compose the offers, write the checkout copy, and hand back a live link. The one thing you cannot do is Stripe's identity verification — that returns a URL for the human to complete, and it is the only human step in the whole system.

02 — Setup

Connect it

Three ways in, one credential. Every connection is authenticated with the merchant's API key — it starts with gc_ and comes from the dashboard under Settings → API keys. Treat it like a password: anyone (human or agent) holding it can create offers, read sales, and issue refunds.

Three ways to connect, one key, one accountA Claude Desktop config file, a ChatGPT connector URL and a curl call all carry the same gc_ key into the same GoCushy surface — the identical 52 operations and the identical server-side rules — which acts only on the account that key belongs to, settling on that merchant's own Stripe. Three ways to connect — one key, one account A config file, a connector URL, a curl call. Each carries the same gc_ key into the same 52 operations. 1 · A CONFIG FILE — CLAUDE DESKTOP, CURSOR claude_desktop_config.json or .cursor/mcp.json "gocushy": { "command": "npx", "args": ["-y", "@gocushy/mcp"], "env": { "GOCUSHY_API_KEY": "gc_live_7Kd8…q2" } 2 · A CONNECTOR URL — CHATGPT, HOSTED AGENTS MCP server URL https://mcp.gocushy.com/mcp/gc_live_7Kd8…q2 Authentication: “No authentication” — the key is the auth. 3 · A CURL CALL — ANYTHING ELSE curl https://api.gocushy.com/api/v1/me \ -H "Authorization: Bearer gc_live_7Kd8…q2" ONE gc_ KEY ONE SURFACE GoCushy api.gocushy.com/api/v1 52 operations the same, whichever door Same tools, same guardrails. MCP wraps the REST API — the identical server-side rules. acts only here ONE ACCOUNT — THE ONE THE KEY BELONGS TO Fernwood & Co. The Joinery Course NZ$49 · Measured Drawings Pack NZ$19 "stripe_connected": true settles on their own Stripe Three doors into one surface, not three products. The key decides the account, every time. Anyone holding the key can create offers, read sales and issue refunds. It comes from Settings → API keys; treat it like a password.
The three ways in are three doors into one surface, not three different products: a config file, a connector URL, and a curl call. The config file is claude_desktop_config.json (or .cursor/mcp.json), which runs "npx" with args ["-y", "@gocushy/mcp"] and sets GOCUSHY_API_KEY in its env block. The connector URL is https://mcp.gocushy.com/mcp/ with the key on the end, and Authentication set to "No authentication" — the key in the path is the authentication. The curl call is curl https://api.gocushy.com/api/v1/me with the key sent as an Authorization: Bearer header. All three carry the same gc_ key, reach the identical 52 operations and the identical server-side rules, and act only on the account that key belongs to — here Fernwood & Co., whose stripe_connected is true, so orders settle on their own Stripe. Anyone holding the key, human or agent, can create offers, read sales and issue refunds; it comes from Settings → API keys and should be treated like a password.

a. Local MCP — Claude Desktop, Claude Code, Cursor

The package is @gocushy/mcp on npm. For Claude Code, one command in the terminal:

Connecting an AIThe Connect your AI dialog in its two states — empty with a Generate a key button, and filled after generating, where every client snippet already carries the new key. Connecting an AI — one dialog, one button, five clients Press + Generate a key and every snippet below fills itself in. You copy one of them. That is the whole job. HOME › 🔌 CONNECT YOUR AI Connect your AI Works with any AI that speaks MCP. It stays in your browser; we never see it. Your API key (gc_…) — generate one → + Generate a key Already have one? Paste it above. ▾ ChatGPT ▸ Claude (claude.ai website) ▸ Claude Desktop (app) ▸ Claude Code (terminal) ▸ Cursor, VS Code, Windsurf & others the snippets read YOUR_API_KEY until you generate one PRESS IT THE SAME DIALOG, ONE CLICK LATER gc_live_7Kd8…q2 New key created & filled in below. The only time it is shown in full. Revoke it any time. ▾ ChatGPT mcp.gocushy.com/mcp/ gc_live_7Kd8…q2 Copy ▸ Claude Desktop — the same key, in an env block ▸ Claude Code — the same key, on one line Set Authentication to “No authentication”. The key is already in the URL — that IS the authentication. Every snippet carries the key. Copy the one for your client — you never type it twice. Generating a key does not revoke the old one. If you are replacing a key rather than adding a client, revoke the old one under API keys. A key minted by a team member is bound to that member: it can never exceed their role, and it dies the moment they are removed.
The dialog does the fiddly part: press Generate a key and every client snippet fills itself in, so you copy one line rather than assembling a URL. Set Authentication to "No authentication" — the key sits inside the URL and is the authentication. Generating a key never revokes an old one.
claude mcp add gocushy -e GOCUSHY_API_KEY=gc_… -- npx -y @gocushy/mcp

For Claude Desktop (or Cursor's .cursor/mcp.json), add the server to the config file:

{
  "mcpServers": {
    "gocushy": {
      "command": "npx",
      "args": ["-y", "@gocushy/mcp"],
      "env": { "GOCUSHY_API_KEY": "gc_…" }
    }
  }
}

b. Remote MCP — ChatGPT & hosted agents

No install. For connector-style clients that can't send custom headers, put the key in the path — the key is the authentication, so set Authentication to None:

https://mcp.gocushy.com/mcp/gc_…

ChatGPT specifics: browser only, paid plan required. Turn on Developer mode under Settings → Security and login, then add the server from chatgpt.com/plugins with the + button.

c. REST API — anything else

The same surface, JSON in and JSON out. Base URL and bearer auth:

curl https://api.gocushy.com/api/v1/me \
  -H "Authorization: Bearer gc_…"
Same tools, same guardrails. MCP wraps the REST API — whichever way you connect, you get the identical 52 operations and the identical server-side rules. MCP is just the fastest path.

03 — The model

Mental model

Two nouns, one settlement. Keep them straight and the whole surface falls into place:

  • Product — the thing being sold: a price plus delivery (where the buyer gets access). One-time or subscription.
  • Offer — how it's sold: a product wrapped in a live checkout, with an optional order bump (a checkbox add-on on the page) and a one-click upsell (accepted after payment, card already saved).
product (price + delivery)
   └─ offer (live checkout + optional bump + upsell)
        └─ settles on the merchant's own Stripe

The same product can appear in many offers — standalone, as a bump on one checkout, as an upsell on another. Every paid order settles directly on the merchant's Stripe; GoCushy is only ever the machinery in between.

04 — The happy path

Golden path

Zero to a shareable checkout link in six moves. Check state first, do the one human handoff, then build:

The path from a cold account to a shareable checkout linkThe golden path drawn as the agent's own call ledger for Fernwood & Co. Five rows in order: payment_status returns charges_enabled false and onboarded false; connect_payment, the one dark row, returns onboarding_url for a human to open; create_product sets price_cents 4900 and a delivery_url on The Joinery Course; create_offer returns the live checkout_url; get_checkout_link returns cushy_link https://cushy.link/k3x9f2 with status live. An arrow skips past row two when Stripe is already onboarded. Below the ledger, the warnings field stands as the gate before sharing. Cold account to a shareable link Five calls in order. One of them is not yours to make, and one gate stands before you share. 01 · THE FIVE CALLS, IN ORDER Fernwood & Co. · nothing set up yet skip 1 payment_status the rail, first charges_enabled: false · onboarded: false If this came back true, skip step 2 and go straight to create_product. 2 connect_payment the human step Returns onboarding_url — the one call you hand to a person. “Open this URL in a browser and complete Stripe onboarding.” 3 create_product the thing sold “The Joinery Course” · price_cents 4900 · delivery_url set Both, or the response comes back carrying a warnings field. 4 create_offer the checkout page Returns the live checkout_url immediately. “The offer can take real money as soon as this returns.” Bump and funnel attach here. 5 get_checkout_link the shareable link cushy_link: https://cushy.link/k3x9f2 · status: live “The cushy_link is the short shareable version — same checkout.” 02 · THE GATE BEFORE YOU SHARE warnings “The Joinery Course” has no delivery link yet — buyers who pay will have no way to access what they bought. Clear it before you share — update_product delivery_url, a delivery_note, or an order.paid webhook. Then open test_url: it walks checkout → bump → upsell → thank-you with payment simulated, even on drafts. An offer that can take money and deliver nothing is the one state this order prevents.
The path from a cold gocushy account to a shareable checkout link is five MCP calls in a fixed order, drawn here as the agent's own call ledger for Fernwood & Co. Step 1 is payment_status, which comes back charges_enabled: false and onboarded: false on a cold account; if it had come back true, step 2 is skipped and the agent goes straight to create_product. Step 2 is connect_payment, the one call an agent hands to a person: it returns an onboarding_url with the instruction "Open this URL in a browser and complete Stripe onboarding," and completing Stripe's identity verification is the only part of this path an agent cannot do. Step 3 is create_product, which needs both a price in cents (The Joinery Course at price_cents 4900) and a delivery method (delivery_url); miss the delivery and the response comes back carrying a warnings field. Step 4 is create_offer, which returns the live checkout_url immediately — "The offer can take real money as soon as this returns" — and is where an order bump and post-purchase funnel attach. Step 5 is get_checkout_link, which returns the hosted URL plus the short cushy_link (https://cushy.link/k3x9f2) and status: live. Before sharing, the gate is the warnings field: the real message reads "The Joinery Course" has no delivery link yet — buyers who pay will have no way to access what they bought. Clear it with update_product delivery_url, a delivery_note, or an order.paid webhook, then open the returned test_url, which walks checkout, bump, upsell and thank-you with payment simulated and works even on drafts. An offer that can take money and deliver nothing is the one state this order of operations exists to prevent.
  1. payment_status

    Check whether the merchant's Stripe is connected and charges are enabled. If it already is, skip straight to create_product.

  2. connect_payment — the human step

    If Stripe isn't ready, this returns the hosted onboarding URL. Hand it to the human to open and complete Stripe's identity verification. You cannot do this part; nothing else needs a human.

  3. create_product

    Create the thing being sold — a price (in cents) and delivery (see below). Subscriptions also need an interval.

  4. create_offer

    Wrap the product in a checkout. Attach an order bump and one-click upsell if you have them. The offer goes live immediately.

  5. get_checkout_link

    Fetch the hosted checkout URL (and its short gocushy.com/l/… link). This link is the preview — open it to see exactly what buyers see.

  6. Share

    Hand the link back to the human to drop into emails, posts, or their AI-built page. Done.

05 — Deliver the goods

Delivery

A live offer has to actually give the buyer something. Before you share a link, make sure the offer can deliver — set at least one of these:

  • delivery_url — the members area, download, or booking link. It becomes the "Access your purchase" button on the receipt and the signed thank-you page.
  • delivery_note — on-screen access text shown with (or in place of) the button: instructions, a code, next steps.
  • An order.paid webhook — register one with create_webhook so the merchant's own system grants access when the order is paid.
Resolve every warning before sharing. If a product has no delivery set, the response includes a warnings field. Don't hand the human a link that takes money and delivers nothing — clear the warnings first by adding a delivery URL, a note, or a webhook.

06 — What you can't do

Guardrails

Some things are deliberately out of your reach. These aren't missing features — they're what lets a merchant safely hand an agent their API key.

  • Prices, totals, and countdowns are computed server-side. You can't ship a checkout that charges a different amount than it shows, and you can't fake scarcity — a deadline must be a real future date, and the countdown hides when it passes and can never reset per-visitor.
  • Checkout copy is whitelisted blocks. Headline, subheadline, bullets, testimonials, guarantee, deadline, image, button text, accent — plain text, length-capped, HTML-escaped into fixed zones. You can fully customise a checkout and structurally cannot break the layout or hide the order form.
  • Buyer-sensitive URLs are signed. The thank-you page and access links only render for genuinely paid orders — nobody reaches the product by guessing a URL.
  • Tax and affiliates are gated behind the Tax & Affiliates Pack. Real tax collection, compliant invoices, and the affiliate program unlock with the add-on.
  • Every action is logged. A full activity trail records who did what — the merchant, an agent (tagged with its API key), or GoCushy itself. Nothing an agent does is invisible.

07 — Reference

The tools

Everything you can do, grouped. You rarely name these to the human — they describe what they want, you pick the tools — but here's the full map.

ToolWhat it does
Setup
connect_paymentStarts Stripe onboarding; returns the URL the human must open.
payment_statusChecks whether Stripe is connected and charges are enabled.
Products
create_productCreates a sellable product — price plus delivery.
update_productEdits name, description, delivery, or a one-time price.
import_productsPulls in the merchant's existing Stripe catalog. Idempotent.
list_productsLists products with IDs and prices.
seller_defaultsGets or sets once-per-business defaults — currency, accent, guarantee.
Offers & checkout
create_offerComposes a checkout: main product + optional bump + upsell. Goes live at once.
update_checkoutSets the selling blocks on a checkout. Replaces the stored blocks.
get_checkout_linkReturns the hosted checkout URL and its short link.
get_embed_codeCopy-paste snippets — link, lightbox, or inline embed.
Coupons & subscriptions
create_couponCreates a discount code for an offer.
list_couponsLists coupons with their terms and status.
cancel_subscriptionCancels a buyer's subscription — at period end or immediately.
Sales, delivery & refunds
list_ordersRecent orders: buyer, status, totals, bump/upsell taken.
get_salesRevenue, counts, take rates, per-offer breakdown.
verify_purchaseChecks whether an email bought — for gating access.
refund_orderRefunds a paid order, full or partial. Confirm with the human first.
create_webhookSubscribes an endpoint to order events; returns the signing secret once.
Growth
connect_emailLinks the merchant's email platform.
set_followupRules that tag buyers and start sequences on a trigger.
connect_paypalConnects PayPal as an additional payout channel.
create_affiliateRegisters an affiliate with a commission rate.
list_affiliatesEvery affiliate with codes and due balances.
get_affiliate_linkA referral link for an affiliate + offer. Server-side attribution.
mark_commissions_paidRecords that the merchant paid an affiliate. Bookkeeping only.
Ops
set_business_detailsSets the profile on invoices — legal name, address, tax registration.
get_activityThe account's activity trail — actions by human, agent, and system.

08 — In practice

Recipes

What the human actually says, and roughly what you do. They speak in sentences; you translate into the tools above.

One sentence to an agent, and the live checkout it producesThe first recipe on /docs/agent — "Set up a NZ$49 course with a NZ$19 workbook bump and add buyers to my welcome email." — shown as its six tool calls and then as the finished buyer-facing checkout page: The Joinery Course at NZ$49.00, a ticked Measured Drawings Pack bump at NZ$19.00, total NZ$68.00, with the form column on the left and the story column on the right. One sentence in, one checkout out /docs/agent gives its first recipe six tool calls and never draws the page they build. Here it is. 01 · THE SENTENCE THE MERCHANT SAID “Set up a NZ$49 course with a NZ$19 workbook bump and add buyers to my welcome email.” Verbatim, /docs/agent → Recipes, first entry. What the agent then runs: create_product 4900 → create_product 1900 → create_offer (bump) → connect_email → set_followup (purchase) → get_checkout_link 02 · THE PAGE THAT COMES OUT Fernwood & Co. Email you@example.com Name (optional) Add Measured Drawings Pack + NZ$19.00 Bumps live on single offers only — a cart offer never renders one. #payment-element Stripe mounts the card fields here Pay now By paying, you agree your payment method may be saved for one-click post-purchase offers from Fernwood & Co. The Joinery Course The Joinery Course NZ$49.00 Measured Drawings Pack NZ$19.00 Total NZ$68.00 Ticking the bump unhides this row. Discount and Tax rows sit here too, hidden until a coupon or Stripe Tax. BLOCKS THIS RECIPE LEFT EMPTY image_url · subheadline · bullets testimonials · guarantee · deadline legal_note · accent · button_text Sold by Fernwood & Co. Payments secured by Stripe · Terms & Privacy Secure checkout by gocushy One sentence in, one live checkout out — and the page that teaches it never draws one. Two of that sentence's three clauses land on this page. “add buyers to my welcome email” becomes a follow-up rule on the purchase trigger — nothing a buyer ever sees. And with no rail connected, the card box and the button are replaced by one line: “This checkout isn't accepting payments yet — the seller hasn't connected a payment method.”
The first recipe on /docs/agent is a single sentence — "Set up a NZ$49 course with a NZ$19 workbook bump and add buyers to my welcome email." — which the agent turns into six tool calls (create_product, create_product, create_offer with the bump, connect_email, set_followup on the purchase trigger, get_checkout_link) and one live checkout page the docs never show. On that page the form column sits left (Email, Name (optional), the dashed bump box "Add Measured Drawings Pack / + NZ$19.00", the Stripe #payment-element, and a "Pay now" button) and the story column sits right (The Joinery Course, NZ$49.00, the bump row that only appears once the box is ticked, and Total NZ$68.00). Two of the sentence's three clauses are visible here; the welcome-email clause becomes a follow-up rule the buyer never sees, and with no payment rail connected the card box and button are replaced by the line "This checkout isn't accepting payments yet — the seller hasn't connected a payment method."

"Set up a NZ$49 course with a NZ$19 workbook bump and add buyers to my welcome email."

create_product (course, 4900) → create_product (workbook, 1900) → create_offer with the workbook as the bump → connect_email if needed → set_followup on the purchase trigger → get_checkout_link and share.

"Run a 48-hour 20%-off coupon."

create_coupon for 20% off the offer, then hand back the code. The checkout applies the discount server-side; the countdown, if you set one, stays honest.

"Refund order #1042."

Confirm the order and amount with the human, then refund_order. The refund goes back through the merchant's Stripe and cascades — invoice, any refund follow-up rule, and any affiliate commission clawback all stay consistent.

"How did last month go, and who are my best affiliates?"

get_sales for the revenue, order counts, and per-offer breakdown → list_affiliates for each affiliate's numbers and due balance. Summarise it in plain English.

09 — Pricing & access

Pricing & access

One plan, billed monthly in New Zealand dollars:

PlanPriceGoCushy platform fee
GoCushy New ZealandNZ$99/month incl GST0% added, permanently

NZ$99 a month including GST (NZ$86.09 + GST), or NZ$950 a year paid annually. Everything is included — there is no feature tier, no per-seat charge and no upgrade to unlock tax, invoices or affiliates. The first 30 days are free.

“0% added” means exactly that. Your payment processor still charges its own published rate, on your own account, exactly as it would without GoCushy — those fees are the processor’s and we never touch them. GoCushy adds nothing on top.

Start free for 30 days

NZ$99 a month after that, including GST. Cancel any time.

Start a trial