FireCMS Cloud

@firecms/mcp-server

MCP server for FireCMS Cloud. Lets AI assistants connect a Firebase project to FireCMS, infer collections from the data already in Firestore, and then manage the CMS — browse and edit data, shape collection schemas and properties, configure the project, and manage users.

Admin-only: All write operations require the authenticated user to have the admin role on the target project. Read operations are available to any authenticated project member. Onboarding tools run before a project exists, so they are gated by Google Cloud access instead.

The same server runs in two places:

• Hosted, at https://api.firecms.co/mcp, for everyone. Clients sign in with OAuth in the browser; nothing to install. It holds no Google Cloud credentials, so connecting a new Firebase project is handed off to the web app. The FireCMS backend mounts it through the @firecms/mcp-server/hosted entry point.
• Local, over stdio (npx @firecms/mcp-server). It signs in with your Google account (firecms_login), so it can also enable APIs, create Firestore databases and connect projects end to end.

Hosted server

In Claude (claude.ai or Claude Desktop): Settings → Connectors → Add custom connector, and paste https://api.firecms.co/mcp.

In Claude Code:

claude mcp add --transport http firecms https://api.firecms.co/mcp

Any other client that takes remote servers by URL:

{  "mcpServers": {    "firecms": { "url": "https://api.firecms.co/mcp" }  }}

Local server

Setup

cd packages/mcp_server && npm install && npm run build

Claude Desktop

Add to claude_desktop_config.json:

{  "mcpServers": {    "firecms": {      "command": "node",      "args": ["/path/to/packages/mcp_server/dist/cli.js"]    }  }}

Or use npx (no build required):

{  "mcpServers": {    "firecms": {      "command": "npx",      "args": ["@firecms/mcp-server"]    }  }}

Use firecms_login to sign in when prompted. Tokens are shared with the FireCMS CLI (~/.firecms/tokens.json).

Connecting an existing Firebase project

The typical first session. Everything here is driven by the Google account you logged in with.

1. list_firebase_projects        → see which projects you can connect, and what they still need2. get_project_setup_status      → check one project in detail (optional)3. enable_project_apis           → only if apisEnabled is false4. enable_firestore              → only if firestoreEnabled is false (location is permanent)5. connect_project_to_firecms    → service account, admin user, and the security rules6. setup_all_collections         → infer every root collection from the existing data

Firebase Authentication must be enabled on the project before step 5 — it is the one prerequisite with no API, so turn it on in the Firebase console. Step 5 then adds FireCMS's access rule to the project's Firestore and Storage rules; without it the CMS reports "Missing Firestore Security Rules" and opens nothing, and no tool here would notice, because they all read through the backend's service account, which bypasses security rules.

Step 6 is where an existing project becomes a working CMS: FireCMS samples the documents at each root collection, infers the property types, and uses an LLM to pick display names, a singular name, an icon and a navigation group.

Building collections from existing data

preview_inferred_schema is the non-destructive option: it samples up to 200 documents, infers types, enums and validation locally, and hands back a draft you can edit and then persist with save_collection_schema. It also works for subcollections and any path the bulk tools skip.

infer_collections_from_data and setup_all_collections go through the backend, which adds the LLM pass and writes the result straight into the project. Both skip paths that already map to a collection, so they are safe to re-run as the database grows.

Tools

Auth

Onboarding

Projects & Root Collections

Project Configuration 🔒

Users 🔒

Collection Schemas 🔒

AI Schema Generation

Documents (Firestore CRUD)

Data Import & Export

🔒 = Admin-only operation · 💻 = local server only

Every tool declares a title and a readOnlyHint, plus a destructiveHint when it writes: false for tools that only add (create a document, invite a user), true for anything that can overwrite or delete.

Resources

Example Workflows

Bring an existing Firebase project into FireCMS

1. list_firebase_projects        → pick a project that is not yet connected2. connect_project_to_firecms    → provision it3. setup_all_collections         → infer collections from the data already there

Create a collection from scratch

1. firecms_login          → authenticate2. list_projects          → pick your project3. save_collection_schema → define the schema4. import_documents       → seed with initial data

Shape a schema before committing to it

1. preview_inferred_schema  → draft a schema from real documents, nothing saved2. save_property            → adjust individual fields3. save_collection_schema   → persist the result

AI-assisted schema creation

1. generate_collection    → describe what you want in natural language2. save_collection_schema → persist the generated schema

Architecture

Sessions: local and hosted

Nothing reads credentials from process-wide state. Every API call goes through a FireCMSSession (session.ts) — the user's email, a Firebase ID token on firecms-backend, and a Google access token when there is one — passed to createFireCMSMcpServer():

• Local (cli.ts): localSession reads the CLI's tokens file and exchanges the Google ID token for a backend token (below). The login/logout tools are registered by the CLI only.
• Hosted (hosted.ts): the backend resolves each request's OAuth bearer token to a user and passes a session that mints that user's backend ID token. There is no Google token, so the Google Cloud tools are replaced by a connect_project_to_firecms that links to the web app. Every request gets its own server and transport (stateless Streamable HTTP), so nothing of one person's session outlives their request. hosted.ts never imports the CLI's login flow; a test walks its import graph to keep it that way.

Authentication

The FireCMS Cloud API expects two different tokens, and the server sends both — the same pair the web app sends:

firecms login only produces the Google credentials. The Google ID token is not a Firebase ID token — it is issued by accounts.google.com for the Google OAuth client, so verifyIdToken() rejects it. backend-auth.ts therefore exchanges it for a real firecms-backend token through Identity Toolkit signInWithIdp, which is the headless equivalent of the web app's signInWithPopup(auth, GoogleAuthProvider). The exchanged token is cached in memory until shortly before it expires.

Where collection configurations live

FireCMS Cloud reads collection configurations from the backend Firestore, at projects/{projectId}/collections/{collectionId} — see useFirestoreCollectionsConfigController in FireCMSCloudApp.tsx. That is not the client project's __FIRECMS/config/collections, which is the self-hosted layout and is never read by Cloud.

The backend exposes no REST endpoints for that store — the web app writes to it directly with the Firebase SDK — so backend-firestore.ts talks to the Firestore REST API with the exchanged Firebase token. The backend's security rules apply unchanged.

Document CRUD is different: it is proxied by the backend into the client's Firestore using the project's delegated service account.

Cache-aware collection discovery

The backend's firestore_root_collections endpoint caches its answer for 5 minutes per project, so it misses collections created since the last lookup — including every collection of a project connected moments ago. Discovery therefore goes through the uncached admin/collections/list endpoint, and setup_all_collections resolves the paths itself rather than delegating to initial_setup, which resolves them through that same cache.

infer_collections_from_data also refuses paths with no documents. The backend runs its LLM pass regardless, and with nothing to sample the model invents a schema from the path name alone — an empty articles path yields plausible title/slug/status/author fields that exist nowhere in the data.

stdout is reserved

On a stdio transport, stdout carries the JSON-RPC stream, so cli.ts routes every console channel to stderr before starting. Dependencies do log — @firecms/schema_inference logs while inferring properties — and a single stray console.log would corrupt the protocol stream.

Security

• Hosted authentication: OAuth 2.1 with PKCE against the FireCMS backend; the person approves each client in the web app. The backend stores tokens only as hashes, rotates refresh tokens, and never holds Google Cloud credentials
• Local authentication: Google OAuth via browser, same as firecms login CLI
• Authorization: Write operations enforce admin role check per project
• Token storage: ~/.firecms/tokens.json (shared with CLI); the exchanged backend token is held in memory only and dropped on logout
• Admin cache: Role checks are cached for 5 minutes per project
• Credential hygiene: list_projects strips each project's service account from its output, so credentials are never serialised into the model's context