cmssy stellt deine Inhalte über zwei programmatische Schnittstellen bereit. Die Delivery-API liest veröffentlichte Inhalte, damit dein Frontend sie rendern kann. Der MCP-Server liest und schreibt alles Übrige - und mit ihm verbinden sich KI-Clients wie Claude.

Delivery-API

Jede veröffentlichte Seite, jedes Layout und jede Site-Einstellung ist über einen einzigen GraphQL-Endpunkt lesbar:

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

Das SDK baut diesen Pfad aus deinem apiUrl, org und workspaceSlug - du setzt drei Config-Werte und stellst nie selbst eine URL zusammen. Weil die Organisation im Pfad steht, muss ein Workspace-Slug nur innerhalb seiner Organisation eindeutig sein.

Abfragen unter der Wurzel public brauchen kein Token - cmssy liefert dort ausschließlich veröffentlichte Inhalte. Genau das ruft @cmssy/next beim Rendern einer Seite auf, du fragst also selten von Hand ab. Greif direkt darauf zu, wenn du etwas baust, das das SDK nicht abdeckt: eine Sitemap, einen RSS-Feed, einen Suchindex.

Die Operationen, die dein Frontend tatsächlich nutzt:

• public.page.list - jede veröffentlichte Seite: id, slug, updatedAt, publishedAt.
• public.page.get - eine Seite per Slug, mit SEO-Titel, Beschreibung und Keywords.
• public.page.getById - die publishedBlocks einer Seite: die Block-Instanzen, aus denen ihr Body besteht.
• public.page.layouts - die Header- und Footer-Layoutblöcke einer Seite.
• public.siteConfig - Site-Name, Standard- und aktivierte Sprachen, Branding.

Eine minimale Query - dieselbe, die in jedem cmssy-Frontend hinter Static Params und Sitemap steckt:

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

Block-Inhalte kommen als JSON nach Sprache verschlüsselt zurück, content.de.title ist also der deutsche Titel dieser Block-Instanz. Relationsfelder speichern Record-IDs; die Delivery-API löst sie beim Rendern zu vollständigen Records auf.

Schreibzugriffe sind hier bewusst eng gefasst. Die einzige öffentliche Mutation ist das Absenden eines Formulars:

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

MCP-Server

Seiten anlegen, Blockinhalte bearbeiten, Medien hochladen, Modelle und Records verwalten, veröffentlichen - all das läuft über den MCP-Server. Er spricht das Model Context Protocol, ein KI-Client verbindet sich also damit und bearbeitet deine Inhalte direkt. Deinen Code rührt er nie an: Block-Schemas bleiben im Repo, Inhalte bleiben in cmssy.

Auch ohne KI ist er ein gutes Skripting-Ziel - dieselben Tools lassen sich aus jedem MCP-Client aufrufen.

Was nehme ich wofür?

• Deine Site rendern - Delivery-API, über @cmssy/next.
• Sitemaps, Feeds, Suchindizes - Delivery-API, direkt aufgerufen.
• Inhalte anlegen oder bearbeiten - MCP-Server.
• Migrationen und Content-Skripte - MCP-Server mit API-Token.

Authentifizierung

Öffentliche Lesezugriffe brauchen keine Credentials. Alles, was schreibt oder unveröffentlichte Entwürfe liest, braucht ein Workspace-API-Token - siehe API-Tokens zum Erstellen und Einschränken.