Refunds, subscriptions and license keys from the assistant instead of the dashboard -- and the guardrails that matter once a model can move money.
Most MCP servers read something. This category spends money. A Lemon Squeezy server can refund an order, cancel a subscription, disable a customer's license key and create a discount code, which makes the interesting question not "how many tools" but "what happens when the model gets it wrong". This post compares the four realistic ways to wire a Lemon Squeezy store to an agent, and is specific about what the platform will not let any of them do. Inline code is styled like npx -y @yawlabs/lemonsqueezy-mcp.
Stripe acquired Lemon Squeezy in 2024, so it is fair to ask whether tooling for it is worth installing. From the vendor's own 2026 update: Stripe Managed Payments now supports merchants in 35 or more countries, and "Very soon we will announce public access for Stripe Managed Payments allowing users to sign up without needing an invite." On existing stores, the stated intention is "Our goal is to provide Lemon Squeezy users an easy way to migrate to Stripe Managed Payments." No shutdown or sunset date appears anywhere in that post. So: an established store with an active API, a migration path being built, and no announced end date. Tool it if you run one; do not start a new store on it without reading that page first.
This trips up every server in the category equally, so it is worth stating before any comparison. The Lemon Squeezy API reference documents products and variants as read-only: retrieve and list, with no create or update endpoint for either. No MCP server can make your agent build a product -- that happens in the dashboard, and the best any tool can do is read the resulting IDs back. Customers, discounts, checkouts, webhooks and usage records do have create endpoints, and refunds, subscription cancellations, subscription updates and license-key changes all have write endpoints. Those are the ones to be careful about.
The second constraint is authentication. The API takes a bearer token, and keys are valid for a year. What the docs do not document is any way to narrow one: searching the API reference, the requests page and the developer guide for scope, permission, read-only or per-store turns up nothing, and the guide's own key-creation walkthrough asks for exactly one thing, a name. Whatever limits you want on an agent, they cannot come from the key.
That is the design our server is built around. Every tool is tagged with an authority class -- read, pii, mutate, money, recurring, key, webhook -- because the read/write split is too coarse here. Listing products and listing customers are both reads; only one returns personal data. Creating a checkout and issuing a refund are both writes; only one moves money. The classes are what the rate limits and kill switches operate on:
LEMONSQUEEZY_API_KEY_COMMAND="op read op://vault/lemonsqueezy/key"
LEMONSQUEEZY_ALLOWED_STORE_IDS=12345
LEMONSQUEEZY_MAX_REFUND_AMOUNT_CENTS=5000
LEMONSQUEEZY_RATE_LIMIT_PER_CLASS=money:2/h,recurring:5/h,key:10/m
LEMONSQUEEZY_DISABLE_CLASSES=pii
LEMONSQUEEZY_LOG=auditA refund above the cap is rejected before the API call is built, and before it consumes any rate-limit budget. Setting the cap to 0 blocks every refund, which makes it a kill switch rather than a misconfiguration. Destructive calls land in a bounded audit log exposed as an MCP Resource at lemonsqueezy://audit-log, redacted for credential-shaped keys, for clients that cannot read stderr.
Two honest caveats. These guardrails are in-process: anyone who can edit the server's environment can remove them, so they are a seatbelt, not a vault. And the store allowlist has documented holes -- ls_list_stores and ls_list_affiliates take no store ID at all, so they return rows from every store the key can see, allowlist or not. If an agent must never see a second store, the only real boundary is a separate Lemon Squeezy account whose key it never gets.
Tool counts are each project's own figure, except ours, which is a tools/list probe of the published package on 11 September 2026: 64 tools, covering every resource in the vendor's API reference plus the License API, of which 3 bridge to an optional webhook sink. Downloads are the 30 days ending 2026-09-10.
| Capability | @yawlabs/lemonsqueezy-mcp |
@heysash/lemonsqueezy-mcp |
lemonsqueezy-mcp-server |
Composio toolkit |
|---|---|---|---|---|
| Tools | 64, probed | 44 | No count published | 32 |
| Where it runs | Local stdio, no deps | Local stdio, official SDK | Local stdio | Hosted by Composio |
| Refund amount cap | Yes, per call in cents | No | No | No refund tool listed |
| Read-only mode | Per authority class | Yes, one env var | No | Not documented |
| Rate limit on destructive calls | Global and per class | No | No | Not documented |
| Store allowlist | Yes, with documented gaps | Yes, destructive calls | No | Not documented |
| Audit log | MCP Resource, redacted | JSONL file plus stderr | No | Not documented |
| Affiliates, usage records, subscription invoices | Yes | No | Not documented | Read-only list tools |
| Notable extra | Webhook-sink reconciliation | Two Claude skills | Salesforce sync | Many other toolkits |
| License | MIT | MIT | MIT | Hosted service, free tier |
| Downloads, last 30 days | 1,214 | 152 | 272 | n/a |
A fifth exists and is the most-starred of the set: atharvagupta2003/mcp-lemonsqueezy, a Python server built on fastmcp with 17 tools and an audit-log resource. Its last commit was April 2025, so treat it as a working reference rather than a maintained dependency -- but if your stack is Python and you intend to fork anyway, it is the natural starting point.
@heysash/lemonsqueezy-mcp has the better simple answer. LEMONSQUEEZY_READ_ONLY=true is one variable that disables every mutating tool. Getting the same guarantee from ours means listing six authority classes correctly, and a typo in that list is a silently wider blast radius. If what you want is "let the assistant look, never touch", theirs is easier to get right. It is also a thin wrapper over the official @lemonsqueezy/lemonsqueezy.js SDK, so it inherits vendor fixes rather than reimplementing the client, and it ships two Claude skills -- one of which sends signature-valid synthetic webhooks at your handler, filling a gap the platform itself leaves open. We answer webhook reconciliation with a separate sink process, which is more moving parts for a smaller shop.
lemonsqueezy-mcp-server syncs to Salesforce. Set three Salesforce variables and a sync_customer_to_crm tool appears; it can also poll for failed payments and surface them as MCP resources so the model sees them without being asked. If your customer records need to land in a CRM, we do not do that at all, and no amount of tool count makes up for it.
Composio means nothing to run and nothing to store. It is a hosted MCP endpoint with a listed 32 tools, managed auth, and a free tier, and it routes many other SaaS toolkits through the same connection. Those 32 are mostly reads plus customer, discount and webhook CRUD -- the published list has no refund, cancellation or subscription-update tool at all, so this is not the one to reach for when the agent needs to move money. For a non-developer, or for a team that does not want an API key sitting in a local config file at all, it is still a genuinely better trade than any local process -- you are moving the key to a third party instead of the filesystem, which is a different risk, not automatically a worse one.
When an agent touches the store unattended and you need the blast radius bounded in ways the platform cannot express: a hard ceiling on any single refund, two money-class calls per hour, personal data switched off entirely for an analytics agent, an audit trail you can read back through MCP, and the key pulled from a vault at call time rather than pasted into a config file. It is also the widest of the four on coverage -- the only one that can create a usage record or refund a subscription invoice, which matters if you bill on metered usage -- though heysash covers order items and license-key instances too, and Composio lists read-only tools for affiliates, usage records and subscription invoices. If none of that describes you, one of the servers above is a smaller, simpler thing to own.
Add it to any MCP client, or let Yaw MCP fan one config out to every client on the machine:
npx -y @yawlabs/lemonsqueezy-mcpSet LEMONSQUEEZY_API_KEY and start with the guardrails above rather than adding them after an incident. Source: github.com/YawLabs/lemonsqueezy-mcp, MIT, version 0.13.2 at the time of writing; the card on our MCP servers page has the one-click install, and our config guide covers where each client keeps its file.
No. The Lemon Squeezy GitHub organization publishes an official JavaScript SDK, a Laravel package, a Swift library, an iOS app, the Wedges UI library and a few templates, but no MCP server as of September 2026. Every Lemon Squeezy MCP server available today is community-built and unofficial, including ours and including the ones that wrap the official SDK.
No. The API reference documents only retrieve and list operations for products and variants, with no create or update endpoint for either, so products have to be made in the dashboard no matter which MCP server you use. Customers, discounts, checkouts, webhooks and usage records do have create endpoints, and refunds, subscription cancellations and license key updates all have write endpoints.
Not with an API key, because Lemon Squeezy does not document any scope, permission or read-only option for one: creating a key asks only for a name. The limit has to live in the server, so set a maximum refund amount in cents, add a per-class rate limit such as two money-class calls per hour, or disable the money class outright. For a boundary an operator cannot edit away, issue the key from an account that hosts only the store the agent may touch.
Jeff Yaw, Yaw Labs. Follow along at tokenlimit.news for weekly notes on AI infrastructure.
Published by Yaw Labs.