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 need

1. get_project_setup_status → check one project in detail (optional)
2. enable_project_apis → only if apisEnabled is false
3. enable_firestore → only if firestoreEnabled is false (location is permanent)
4. connect_project_to_firecms → service account, admin user, and the security rules
5. 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 connected

1. connect_project_to_firecms → provision it
2. setup_all_collections → infer collections from the data already there

Create a collection from scratch

1. firecms_login          → authenticate

1. list_projects → pick your project
2. save_collection_schema → define the schema
3. import_documents → seed with initial data

Shape a schema before committing to it

1. preview_inferred_schema  → draft a schema from real documents, nothing saved

1. save_property → adjust individual fields
2. save_collection_schema → persist the result

AI-assisted schema creation

1. generate_collection    → describe what you want in natural language

1. 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 w