Caelo CMS

io.github.caelo-cmsPublished by GitHub account caelo-cmsv0.11.21Updated Nov 6, 2026

Edit a self-hosted Caelo CMS site from your agent. Changes land in a draft; a human publishes.

VerifiedSTDIODesktop onlyFiles & StorageDeveloper Tools

Overview

AI-generated overview

Lets an AI assistant edit a self-hosted Caelo CMS site through chat or direct admin tools, with changes landing in a draft for a human to publish.

What you can do
  • Send messages to Caelo's own AI agent and continue chat sessions, with page context and image attachments
  • Browse, publish and propose site changes through the chat, with audit trail and Owner approval gates
  • Run the full chat-runner tool catalogue directly in admin mode so your own agent drives the tool loop
  • Upload images from local paths or base64 into the shared CMS media library
  • Export a CLAUDE.md and skills tree generated from the install's live context
When to use it
Useful when you run a self-hosted Caelo CMS install and want an agent to draft, edit or inspect site content while keeping a human in control of publishing. It fits desktop MCP clients such as Claude Code, Cursor or VS Code rather than browser-hosted assistants.
Requirements
A local runtime with bunx (Bun) to launch the stdio server, plus a reachable Caelo admin install. Requires CAELO_ADMIN_URL (https, http only for localhost) and a bearer token in CAELO_MCP_TOKEN minted at /settings/mcp by an Owner. Google Cloud IAP installs also need CAELO_IAP_SERVICE_ACCOUNT and Application Default Credentials via gcloud login. Desktop apps need the full path to bunx.
Before you install
The MCP token is a secret granting the owner's content.write permission; anyone holding it can act on the site, so keep it private and scope it. Tokens can carry an AI-spend cap, and chat turns report per-turn cost, so agent use may incur charges. Edits go to a shared draft and some actions wait for Owner approval, but content and uploaded images are stored in the CMS and sent to Caelo's AI when routed through chat. Uploads write to the media library.

Installation

In SourceWeft

  1. Open Caelo CMS in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

@caelo-cms/mcp-server

MCP servers for your Caelo CMS install. Two surfaces, selected by the token's scope:

  • caelo_chat (default mode, scope chat) — talks to Caelo's own AI agent. You describe an outcome; Caelo's chat-runner does the work.
  • Power-MCP (caelo-admin-mcp binary / caelo-mcp-server admin, scope admin) — the full chat-runner tool catalogue exposed directly, so YOUR agent (Claude Code et al.) drives the tool loop and Caelo makes no provider calls of its own. caelo-mcp-server export additionally writes a CLAUDE.md + .claude/skills/ tree generated from the install's live context.

Every mode is a thin shim: calls become HTTPS POSTs against your admin install's /api/mcp/* endpoints, which dispatch into the same chat-runner machinery that powers the live-edit overlay. See the MCP page in the docs for the full Power-MCP working model (work sessions, the shared draft, approval gates).

Install

In your Caelo install:

  1. Visit /settings/mcp as an Owner.
  2. Click New token, give it a name (claude-code, laptop, ci, etc.), optionally set an AI-spend cap (microcents), and copy the bearer that's shown ONCE.
  3. The page shows ready-to-copy setup for Claude Code, Claude Desktop, Codex CLI, Cursor, VS Code and Gemini CLI — a terminal command or a JSON config entry, plus how the client picks it up.

Desktop apps (Claude Desktop, Cursor, VS Code) don't inherit your terminal's PATH: put the full path of bunx (which bunx) into their config instead of the bare name.

ChatGPT and claude.ai in the browser can't use this server: they only connect to MCP servers hosted on the internet (Streamable HTTP + OAuth), and this one runs on your machine over stdio. Tracked in #806.

Manual setup for any other MCP-aware client:

bash
# stdio server invoked by your MCP-aware clientbunx @caelo-cms/mcp-server@latest

It switches to the exact release your install runs at startup (see the MCP page in the docs), so the command never needs a version; @latest keeps bunx from reusing an older cached install.

with these env vars set:

VariableRequiredNotes
CAELO_ADMIN_URLyeshttps://admin.example.com — point at your install. Must be https:// (plain http:// only for localhost).
CAELO_MCP_TOKENyesBearer minted at /settings/mcp.
CAELO_IAP_SERVICE_ACCOUNTon GCP installsThe admin's MCP service account. /settings/mcp includes it in every client snippet when the admin is behind Google IAP.

Without CAELO_ADMIN_URL or CAELO_MCP_TOKEN the server still starts and lists its tools (MCP directories inspect servers that way), but every tool call fails and names the variable to set. Power-MCP then lists the catalogue shipped with this release (power-catalogue.json); once configured it always lists your admin's live catalogue, including plugin tools. export exits instead.

Installs behind Google IAP (GCP)

On gcp and gcp-firebase installs the admin sits behind Identity-Aware Proxy, which rejects every request before Caelo sees it unless it carries a Google credential. With CAELO_IAP_SERVICE_ACCOUNT set, the server signs a short-lived JWT as that service account (IAM Credentials signJwt, using your Application Default Credentials) and sends it in Authorization next to x-caelo-mcp-token: IAP checks the first, Caelo the second.

One-time setup on your machine:

bash
gcloud auth application-default login

The provisioner creates the service account (caelo-mcp@<project>), allowlists it on IAP and lets everyone on the IAP allowlist sign as it — on new installs via Pulumi, on existing ones during cms-provision upgrade. No service-account keys are involved.

The caelo_chat tool

FieldTypeNotes
messagestring, requiredWhat you want to say to the Caelo agent.
chatSessionIduuid, optionalContinue an existing chat session.
attachmentsarray, optionalUp to four image references returned by caelo_upload_images.
pageIduuid, optionalBind a NEW chat to one page so the agent's page-context block populates.

Output: assistant reply text + a JSON block with chatSessionId (for the next call), requestId (click through to /settings/audit/<requestId> for the full audit trail), the structured tool-call summaries the agent dispatched, the per-turn cost in microcents, and a pendingProposals count so the agent can surface "you have N things waiting for Owner approval".

Why route editing through chat?

Browse / publish / propose actions happen through the chat — "which pages exist?" → the Caelo agent calls pages.list internally → answers in text. Same auth surface, same RLS scoping, same audit trail, same propose-execute Owner gate as the browser. The remote agent talks to a human-equivalent agent, not to a programmatic API.

License

MPL-2.0.

Image uploads

Both modes expose caelo_upload_images. For example, call it with:

json
{"images":[{"filePath":"/home/me/Pictures/character.png","alt":"Main character reference"}]}

Paths are local to the MCP process. Alternatively use base64 plus an optional filename; supply exactly one of filePath and base64. Uploads support PNG/JPEG/WebP/GIF, up to 5 MiB each, with at most four files per call. The result contains per-file successes/errors and an attachments array. Pass that array to caelo_chat alongside message to send actual image content to Caelo's AI. In admin mode, the returned asset IDs can be used with regular media/page tools.

The token owner's current content.write permission is required for either scope. Images are stored in the shared CMS media library; admin previews require authentication. Uploading alone does not publish a page. A partial batch keeps successful uploads — retry only the failed entries. See the MCP page in the docs for HTTP examples and server limits.

Source: packages/mcp-server/README.md at commit 1149615

Tools

0
SourceWeft started this package once in an isolated sandbox, without credentials, to list its tools. That failed: the server did not start.

Version history

25
  1. v0.11.21LatestNov 6, 2026
  2. v0.11.20Nov 5, 2026
  3. v0.11.19Nov 5, 2026
  4. v0.11.17Nov 5, 2026
  5. v0.11.15Nov 4, 2026
  6. v0.11.12Nov 4, 2026
  7. v0.11.11Nov 3, 2026
  8. v0.11.10Nov 3, 2026
  9. v0.11.7Nov 1, 2026
  10. v0.11.6Oct 31, 2026
  11. v0.11.5Oct 30, 2026
  12. v0.11.4Oct 30, 2026
  13. v0.11.3Oct 29, 2026
  14. v0.11.0Oct 26, 2026
  15. v0.10.72Oct 25, 2026
  16. v0.10.71Oct 25, 2026
  17. v0.10.68Oct 24, 2026
  18. v0.10.67Oct 23, 2026
  19. v0.10.65Oct 23, 2026
  20. v0.10.64Oct 22, 2026
  21. v0.10.62Oct 21, 2026
  22. v0.10.61Oct 21, 2026
  23. v0.10.60Oct 21, 2026
  24. v0.10.59Oct 20, 2026
  25. v0.10.58Oct 20, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts