@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: contact@cmssy.com.

• 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 onl

... View full README on GitHub