cmssy exposes your content through two programmatic surfaces. The delivery API reads published content so your frontend can render it. The MCP server reads and writes everything else, and is what AI clients like Claude connect to.

Delivery API

Every published page, layout and site setting is readable over a single GraphQL endpoint:

https://api.cmssy.io/public/{org}/{workspace}/graphql

The SDK builds that path from your apiUrl, org and workspaceSlug, so you set three config values and never assemble a URL yourself. Because the org sits in the path, a workspace slug only has to be unique within its organization.

Queries under the public root need no token - cmssy only returns published content there. This is exactly what @cmssy/next calls when it renders a page, so you rarely query it by hand. Reach for it directly when you build something the SDK does not cover: a sitemap, an RSS feed, a search index.

The operations your frontend actually uses:

• public.page.list - every published page: id, slug, updatedAt, publishedAt.
• public.page.get - one page by slug, with its SEO title, description and keywords.
• public.page.getById - a page's publishedBlocks: the block instances that make up its body.
• public.page.layouts - the header and footer layout blocks for a page.
• public.siteConfig - site name, default and enabled languages, branding.

A minimal query - the one behind static params and sitemaps in every cmssy frontend:

query PublicPages($workspaceSlug: String!) {
  public {
    page {
      list(workspaceSlug: $workspaceSlug) {
        id
        slug
        updatedAt
        publishedAt
      }
    }
  }
}

Block content comes back as JSON keyed by language, so content.en.title is the English title of that block instance. Relation fields store record ids; the delivery API resolves them to full records at render time.

Writes are deliberately narrow here. The only public mutation is form submission:

mutation SubmitForm($formId: ID!, $input: SubmitFormInput!) {
  public {
    form {
      submit(formId: $formId, input: $input) {
        success
        message
        submissionId
      }
    }
  }
}

MCP server

Creating pages, editing block content, uploading media, managing models and records, publishing - all of that goes through the MCP server. It speaks the Model Context Protocol, so an AI client connects to it and edits your content directly. It never touches your code: block schemas stay in your repo, content stays in cmssy.

It is also a perfectly good scripting target when no AI is involved - the same tools are callable from any MCP client.

Which one do I use?

• Rendering your site - delivery API, through @cmssy/next.
• Sitemaps, feeds, search indexes - delivery API, called directly.
• Creating or editing content - MCP server.
• Migrations and content scripts - MCP server with an API token.

Authentication

Public reads need no credentials. Anything that writes, or that reads unpublished drafts, needs a workspace API token - see API tokens for creating and scoping one.