A Tuesday Afternoon

A customer writes in: the mug arrived broken. Here is what fixing it usually takes in a headless setup:

1. Refund the money at the payment provider.
2. Record the refund in the commerce backend so stock and reports agree.
3. Create a discount code so the customer comes back.
4. While you're at it, the homepage banner still advertises last week's promotion. Change it in the CMS and publish.

That's three or four admin panels, and with most headless CMSs at least two vendors, because the CMS holds the copy and something else holds the orders.

In cmssy the orders, discounts and pages live in one workspace, and the MCP server exposes all of them. Every step after the first fits into one conversation with an agent.

The Same Afternoon, in One Conversation

This is Claude Code connected to a cmssy workspace over MCP. The prompts are what you type; the tool names are what Claude calls.

1. Find the order

Find the latest order from anna@example.com and show me its lines.

Claude calls list_orders with search (it matches the customer email), then get_order for the lines, payments, parcels and totals.

2. Record the refund

I refunded the mug in Stripe, refund id re_3Q... for 24.00 EUR.
Record it on the order.

Claude calls refund_order with the order id, amount: 2400 (money is in minor units) and the Stripe refund id as reference.

Note what this does and doesn't do. cmssy doesn't move money. Payments are taken and returned by your own provider. cmssy records the result. The refund id is required, and sending the same id twice records nothing twice. A full refund also returns the units that hadn't shipped yet to stock and cancels parcels that were still waiting for dispatch. Either way, cmssy fires an order.refunded or order.partially_refunded webhook, so your accounting or email service hears about it.

3. Create the apology code

Create a 15% code SORRY-ANNA, one use, valid for 30 days.

create_discount with type: "percentage", value: 15, maxUses: 1 and an endsAt. The storefront applies it at checkout through the delivery API, like any other code.

4. Update the promo block

On the homepage, change the promo banner to announce free shipping
this weekend, in every language we have.

Claude reads the page with get_page, finds the banner block and changes it with update_block_content. Claude takes the field names from your site's block manifest (list_block_types), and the server warns when content doesn't match it, so the banner gets the fields your component renders. The change sits in the draft.

5. Publish

Publish the homepage.

publish_page. If your site has a revalidate route subscribed to content.changed, the new banner is live seconds later. cmssy doesn't render the page; your app does, on your host.

What the Server Covers

The same server, with the same token:

• Content: pages, blocks, layout regions, page types, media, forms and their submissions, custom data models and records.
• Commerce: orders (manual orders, edits, payments recorded, refunds, cancellations, invoices, the order pipeline), returns, shipments, carts, discounts, products and stock, price lists and sales channels.
• Customers: the accounts that sign in to your site. Claude can list them, suspend or unlock one, or send a password reset.
• Webhooks: create, update and rotate endpoints, and read their delivery log.

The full list, with the permission each tool needs, is in the MCP server docs.

How This Compares

Contentful, Sanity and Storyblok all have official MCP servers, and they're good at what those products store: entries and documents, assets, content types and schemas, releases. If all you need is an agent that writes and publishes content, any of them will do, and so will we.

The difference shows up when the task touches money. Those platforms don't hold your orders; a store built on them keeps orders in a separate commerce system. Steps 1 and 2 above then go through another vendor's API, with another MCP server or an integration you maintain. In cmssy the order, the discount and the banner sit in the same workspace, under the same roles, behind the same server.

And to be clear about the edges: cmssy isn't a payment processor and doesn't want to be. Your checkout talks to Stripe or another provider, your backend verifies the provider's webhook, and only then is the payment recorded in cmssy.

Guardrails

An agent that can refund an order deserves more care than one that edits a heading. What actually limits it:

• Roles. A token or a hosted connection acts as the person who created it, with that person's role in the workspace. A refund needs the orders-manage permission. A member without it gets an error, not a refund.
• Read-only connections. When you connect Claude through the hosted server you can grant read only. Every write is then refused on the server, whatever the prompt says.
• Approval in the client. The server marks every tool that deletes, publishes, refunds or cancels as destructive. Claude Code asks before it runs any tool you haven't allowed, so keep refund_order, cancel_order, publish_page and delete_page off your allowlist and you approve each one as it comes.
• The in-admin assistant asks too. When the same tools run in the admin's assistant, the server itself holds the destructive ones until you approve them with a button.

Try It

The setup is an API token, a .mcp.json and two environment variables. The Claude Code tutorial walks through it with a Next.js app. Content works on every plan; cart and checkout need Pro.