@cmssy/mcp-server

MCP server for Cmssy, a hosted headless CMS with built-in commerce. Lets an AI agent work with pages, records, media, forms, products, orders, refunds and discounts in a Cmssy workspace.

Hosted server (no install)

https://api.cmssy.io/mcp serves the same tools over HTTP. Claude (web, desktop, Code) and Codex connect by signing in to cmssy. A client that asks for a server URL and an API key - v0, Lovable, Bolt or your own - sends a cs_ token instead:

URL:    https://api.cmssy.io/mcp
Header: Authorization: Bearer cs_YOUR_TOKEN

A token scoped to one workspace reaches only that workspace; an unscoped token reaches every workspace you belong to. Every tool takes a workspace (<orgSlug>/<workspaceSlug>), and list_workspaces names the ones the token may use. It reads and writes with your role in each workspace. Changing your password does not revoke it - delete it under Dashboard > API Tokens. Details: cmssy.com/docs/api/mcp.

Setup

Prerequisites

1. A Cmssy workspace - the free plan works; cart and checkout need Pro
2. An API token (Dashboard > API Tokens, starts with cs_)
3. Your workspace ID (Workspace Settings > General)

The server talks to https://api.cmssy.io by default. Pass --api-url only for another backend.

Add to Claude Code

Add to .mcp.json in your project root:

{
  "mcpServers": {
    "cmssy": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@cmssy/mcp-server@latest",
        "--token",
        "cs_YOUR_TOKEN",
        "--workspace-id",
        "YOUR_WORKSPACE_ID"
      ]
    }
  }
}

Environment Variables

Instead of CLI args, you can set:

• CMSSY_API_TOKEN — API token (cs_xxx)
• CMSSY_WORKSPACE_ID — Workspace ID
• CMSSY_API_URL — API URL (optional; defaults to https://api.cmssy.io, so set it only for a self-hosted backend)

Checking which build is running

--version and --help need no token, so they answer even when the server is not configured. Run the flag against the same spec your client launches, copied out of your mcp.json:

npx -y @cmssy/mcp-server --version          # what an unpinned config runs
npx -y @cmssy/mcp-server@latest --version   # what the registry serves today
npm view @cmssy/mcp-server version          # the newest published version

The first two can disagree, and that disagreement is the answer: a warm npx cache holds the build an unpinned spec resolved to earlier, while @latest re-resolves and reports the newest one. So @latest --version cannot diagnose a stale cache - it is the command that hides it. Ask the unpinned spec first when a tool fails on a field the API should serve, then compare.

Clearing the cache is npx clear-npx-cache, or pin the version in your config so nothing has to be diagnosed.

Privacy Policy

Full policy: https://www.cmssy.com/privacy. Contact: [email protected].

• What this server collects: nothing of its own. It keeps no local database, writes no files and sends nothing to any analytics service.
• What it sends, and where: each tool call becomes a GraphQL request to the Cmssy API (https://api.cmssy.io unless you set CMSSY_API_URL), carrying your API token, your workspace ID, the tool's arguments, the client name and version, and the name of the tool being run. The Cmssy API records one usage event per tool call from those last two.
• Files and URLs: upload_media reads only the local file path or downloads only the URL you pass it, then uploads the bytes to the Cmssy storage URL the API returns. It touches no other file.
• Usage and storage: the Cmssy API stores workspace content (pages, records, media, orders, customers) as described in the policy above, in the European Union. Content is not sold and not used to train AI models.
• Third-party sharing: the server talks to the Cmssy API and the Cmssy storage URL only, plus any URL you hand to upload_media. Third parties the Cmssy service itself uses are listed in the policy.
• Data retention: the server keeps nothing after a call returns. Workspace data stays until you delete it or close your account; retention periods are in the policy.
• Your token: it acts with the permissions of the member who created it. Revoke it under Dashboard > API Tokens at any time.

Response shape (write tools)

As of 0.6.0, most write tools accept an optional response arg:

• response: "minimal" (default) - returns a small ack (~200 bytes): {id, slug, hasUnpublishedChanges, updatedAt} for page tools, {pageId, blockId, hasUnpublishedChanges, updatedAt} for block tools, {id, slug, status, updatedAt} for form tools, {id, slug, updatedAt} for model tools, {id, status, updatedAt} for record tools, {id, orderNumber, status, paymentStatus, fulfillmentStatus, total, balanceDue, currency, updatedAt} for order tools, {id, code, type, value, enabled, updatedAt} for discount tools.
• response: "full" - returns the full mutation response (pre-0.6 behavior).

Use "full" only if you need the post-write state inline; otherwise issue a follow-up get_page/get_form/get_model/get_record. This keeps agent context windows from being eaten by echoed content.

Tools that accept response: create_page, update_page_blocks, update_page_settings, publish_page, unpublish_page, revert_to_published, update_page_layout, add_block_to_page, update_block_content, remove_block_from_page, create_form, update_form, create_model, update_model, create_record, update_record, create_manual_order, edit_order, update_order_details, mark_order_paid, record_order_payment, refund_order, cancel_order, close_order, reopen_order, create_return, approve_return, reject_return, cancel_return, receive_return, refund_return, complete_return, update_return_tracking, create_shipment, update_shipment, set_order_pipeline_stage, record_order_invoice, record_order_invoice_correction, create_discount, update_discount, set_discount_enabled.

patch_block_content and the various delete_* / status-only tools (update_form_submission_status, import_records) already returned a compact ack and don't take response.

Building a site

On connect the server sends instructions that send an agent (v0, Lovable, Bolt, Claude) to get_site_setup first. It returns the files cmssy init writes for Next.js - catch-all page, editor route, proxy, config, block registry, header/footer regions - with the workspace's env vars filled in. The agent then deploys, calls set_preview_url, creates the content.changed webhook for /api/revalidate, has the user open the editor once so the block types register, creates the pages with header and footer in their layout regions, and publishes them.

Available Tools

Read Tools

Write Tools

Block Helper Tools

update_region_settings

Region (layout position) settings are declared by the workspace's layout manifest and validated against it on write. The tool reads the page's current layoutRegionSettings, replaces only the named region and writes the whole list back, so sibling regions keep their values (entries for regions the manifest no longer declares, and keys a region's schema no longer has, are dropped on the way - the same pruning the admin editor does). The backend's own BAD_USER_INPUT message is returned verbatim for an unknown region, an unknown key, or a non-empty values on a region that declares no settings (such a region accepts values: {} only); blockWarnings are surfaced when present.

{ "pageId": "...", "region": "sidebar", "values": { "width": "wide" } }

Child pages inherit a region's settings unless they set their own - get_page shows the effective value per region in resolvedRegions (settingsAreInherited, settingsSourcePageId).

patch_block_content

For small edits on long HTML content strings (e.g. a docs-article body), patch_block_content is ~10x cheaper in tokens than update_block_content and catches marker mistakes before anything writes to the DB.

{
  "pageId": "...",
  "blockId": "...",
  "locale": "en",
  "operations": [
    {
      "op": "insert_before",
      "marker": "<h2>Environment Variables</h2>",
      "html": "<hr><h2>cmssy skills install</h2><p>...</p>",
    },
  ],
}

Four ops: insert_before, insert_after, replace_section, replace_all. Every marker must match exactly once - 0 or 2+ matches error out with the actual count (no silent half-applied state). For replace_section, startMarker is inclusive and endMarker is exclusive. replace_all sets the whole string and takes expected, the current value - refused if it moved.

Requires @cmssy/cli-registered workspace with PAGES_EDIT permission. Default fieldPath is "content" (the HTML body on docs-article); override if patching a different string field. Dot segments reach a nested string, e.g. tabs.0.label for the first tab's label.

Model Tools (Custom Data Models)

AI agents can define ModelDefinitions and CRUD their records. Schema/fields follow PropertyField from @cmssy/types; records are validated against the model on every write.

Requires workspace permissions MODELS_VIEW (read) / MODELS_CREATE / MODELS_EDIT / MODELS_DELETE depending on the operation.

Commerce Tools (Orders, Carts, Discounts)

Manage the storefront's orders, carts, and discount codes. All money fields are integer minor units (cents). Order/discount write tools accept the response arg (see Response shape).

Products are records of a Custom Data Model; these tools add product-aware stock/variant reads and bulk writes on top of the generic record tools. The bulk tools target an explicit ids list or everything matching a filter (allMatching: true). There is no per-variant stock write and no standalone inventory mutation - stock is set/adjusted in bulk via patch.setStock / patch.adjustStock.

Requires workspace permissions ORDERS_VIEW / ORDERS_MANAGE (orders), CARTS_VIEW (carts), DISCOUNTS_VIEW / DISCOUNTS_MANAGE (discounts), MODELS_VIEW / MODELS_EDIT / MODELS_DELETE (products).

Customer Tools

Customers are the accounts that sign in to the site - records of a model with accounts enabled - not the team that manages the workspace (list_team).

Price List Tools

A price list (Gold, Silver, dealer tiers) prices a buyer at a percent off the catalogue plus fixed prices per product or variant. Each buyer has one list: a company's members pay the company's list, a customer without a company their own.

Sales Channel Tools

A sales channel (retail, horeca, b2b) is a key a storefront sends to be priced from the price lists published to it: per product the buyer's own or company list wins, then the channel's dated list, then its base list, then the catalogue. Lists are published with create_price_list / update_price_list channels.

Webhook Tools

Manage outbound event webhooks. create_webhook and rotate_webhook_secret return the signing secret once - it cannot be retrieved again.

Requires workspace permissions WEBHOOKS_VIEW (read) / WEBHOOKS_MANAGE (create, update, rotate, delete).

Email Tools

Requires workspace permission EMAIL_CONFIG_VIEW.

Resources

Example Workflow

> List all pages in my workspace
> Search for pages matching "blog"
> Show me the available block types
> Which pages still use block types the site no longer registers?
> Create a new "Features" page with content in English and Polish
> Add a hero block to the Features page
> Publish the Features page

Hosting the server (library)

createHostedServer serves the same tools from a host that holds no token and no disk. Every tool takes a workspace (<orgSlug>/<workspaceSlug>); list_workspaces names the ones a connection may use. The package checks only the shape of workspace - everything below is the host's job:

• resolveWorkspace(workspace) is the authorization. Check, on every call, that the caller is still a member of that workspace and that the connection was granted it. Throw the same message for "does not exist" and "not yours", so a refusal does not reveal which workspaces exist.
• The executor is the scope. The CmssyApi it returns (createCmssyApi(execute, workspaceId)) runs every document as that user in that workspace; the package sends nothing that would scope it.
• fetchUrl is the SSRF boundary. Refuse private, loopback and link-local addresses and re-check every redirect. The package caps the body at 50MB while reading.

Development

pnpm install
pnpm dev -- --token cs_xxx --workspace-id xxx --api-url http://localhost:4000