Exposes Firebase Firestore and Authentication to AI agents, enabling read operations on Firestore (listing collections/documents, queries, aggregations, schema inference, etc.) and Auth user lookup (by UID or email, with pagination).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@firebase-mcp list collections in Firestore"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that exposes Firebase Firestore and Authentication to AI agents. Built with the Firebase Admin SDK, it runs over stdio and is designed to be wired directly into any MCP-compatible host (Cursor, Claude Desktop, etc.).
13 Firestore read operations — list/browse collections and documents, query (including collection groups), aggregates, counts, schema sampling, composite indexes, distinct value counts, and list_paths for configured path templates
2 Firebase Auth operations — look up users by UID or email, list users with pagination
Multi-project support — configure multiple Firebase projects in one config file; each tool call targets a specific project via projectId
Glob-based access control — allow/deny rules evaluated per Firestore path before any read is performed
Pagination on query_collection, read_collection, and list_users via cursor-based tokens
Batch fetching with configurable maxBatchFetchSize
Schema inference via get_collection_schema — samples documents and infers field types without reading the full collection
Distinct value counts via distinct_values — count occurrences of unique field values across a collection or collection group
Normalized output — Firestore Timestamps, GeoPoints, and DocumentReferences are converted to JSON-serializable values on all tools
Zero runtime state — each tool call hits Firebase directly through the Admin SDK
Related MCP server: MCP Firebase Server
Tool | Description |
| Returns a full config template (every supported field) and setup instructions. Use this when no |
| Returns the current in-memory config, listing all available projects. Call this first to discover valid |
| Re-reads |
firestore_read)All operations are dispatched through the single firestore_read tool via the operation field. Every call requires a projectId matching a key in firebase-mcp.json.
Operation | Description |
| Lists named |
| List root collections or subcollections of a document. Optionally include document counts. |
| List all document IDs in a collection, including phantom documents. Optionally include subcollection names. |
| Read documents from a collection with optional phantom-doc surfacing. |
| Fetch a single document by path. |
| Batch-fetch documents by a list of paths or a collection + ID list. |
| Query with filters, ordering, limit, and pagination. |
| Query across all collections sharing the same name, regardless of parent path. |
| Server-side document count with optional filters. |
| Native |
| Sample a collection from both ends and infer field types. |
| List Firestore composite indexes for the project. |
| Count occurrences of each unique value (or value combination) of one or more fields across a collection or collection group. |
auth_read)All operations are dispatched through the single auth_read tool via the operation field. Every call requires a projectId.
Operation | Description |
| Fetch a Firebase Auth user by UID or email. |
| List Firebase Auth users with optional pagination via |
Node.js 18+
A Firebase project with Firestore enabled
A service account JSON key with Firestore and Auth read permissions
1. Create your per-user firebase-mcp.json
Create the file at:
Linux/macOS: ~/.config/firebase-mcp/firebase-mcp.json
Windows: %USERPROFILE%\AppData\Roaming\firebase-mcp\firebase-mcp.json
The config supports multiple projects under a projects key. Each key becomes the projectId value you pass to tool calls.
{
"projects": {
"my-app": {
"firebase": {
"projectId": "your-firebase-project-id",
"serviceAccountPath": "secrets/serviceAccount.json"
},
"firestore": {
"rules": {
"allow": ["**"],
"deny": []
},
"maxCollectionReadSize": 100,
"maxBatchFetchSize": 200,
"paths": {
"example_orders": {
"template": "customers/{customerId}/orders",
"description": "Optional hint for agents; omit or replace with your own entries"
}
}
},
"timeouts": {
"callMs": 15000
}
}
}
}To configure multiple projects, add additional keys under projects:
{
"projects": {
"prod": { "firebase": { ... }, "firestore": { ... } },
"staging": { "firebase": { ... }, "firestore": { ... } }
}
}2. Add your service account key
Place your Firebase service account JSON at any path you prefer — you'll reference it in firebase-mcp.json above. Paths are resolved relative to the working directory when the server starts, or you can use an absolute path.
3. Wire it into your MCP host
See the Connecting to Cursor section below — no installation step required when using npx.
Field | Type | Default | Description |
|
| — | Map of project keys to project configs |
|
| — | Firebase project ID |
|
| — | Path to service account JSON (relative to CWD or absolute) |
|
| — | Glob patterns for allowed Firestore paths |
|
| — | Glob patterns for denied Firestore paths (evaluated first) |
|
|
| Default document limit for collection reads |
|
|
| Maximum documents per batch fetch |
|
|
| Named path templates ( |
|
|
| Max duration of a single tool call in ms (integer, min |
The server reads config from a deterministic per-user path:
Linux/macOS: ~/.config/firebase-mcp/firebase-mcp.json
Windows: %USERPROFILE%\AppData\Roaming\firebase-mcp\firebase-mcp.json
Firestore path access is governed by glob patterns evaluated with micromatch. Deny rules take precedence over allow rules. Every tool call checks the target path before hitting Firestore.
{
"rules": {
"allow": ["users/**", "products/**"],
"deny": ["users/*/private/**"]
}
}Add to your MCP config (e.g. .cursor/mcp.json):
{
"mcpServers": {
"firebase": {
"command": "npx",
"args": ["-y", "firebase-mcp"]
}
}
}npx -y will download and cache the package automatically on first run. No manual installation needed.
firestore_read and auth_read are safe to add to Cursor's tool allowlist for unattended use. get_config, reload_config, and create_config are also read-only and safe to allowlist.
MIT
Read from Firebase Authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | No | Firebase Auth UID | |
| No | User email address | ||
| operation | Yes | - get_user: Fetch a user by uid, email, or phoneNumber. Args: uid? OR email? OR phoneNumber? - list_users: List users with pagination. Args: maxResults?(1-1000, default 100), pageToken? | |
| pageToken | No | Page token from a previous list_users response | |
| projectId | Yes | Project key as defined in firebase-mcp.json | |
| maxResults | No | Maximum number of users to return, 1–1000 (default 100) | |
| phoneNumber | No | E.164 phone number, e.g. +15555550100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Read' which is implicit from the name, and does not elaborate on safety, side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but at the cost of completeness. It is not verbose, but it is underspecified given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is inadequate. It should explain that results are read-only, pagination behavior, and that it does not modify data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for each parameter, including enums and usage notes. The tool description adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read from Firebase Authentication' clearly states the verb (read) and resource (Firebase Authentication). It differentiates from siblings like firestore_read which reads from Firestore, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor on when to choose 'get_user' vs 'list_users'. The description provides no usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a template showing the required structure of the firebase-mcp.json config file. Use this when no config file has been found. After creating the file, call reload_config to load it without restarting the server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the name 'create_config', the description accurately states it returns a template, indicating it is a read-only operation. No annotations exist, but the description adds behavioral context about its non-destructive nature and the recommended workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every word contributes meaning. No redundancy or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete: it explains what the tool returns, when to use it, and what to do next. It adequately equips an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100%. The description adds meaning by explaining the tool returns a template for the config file structure, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns a template showing the required structure of the firebase-mcp.json config file'. It distinguishes from siblings by explicitly mentioning reload_config for loading after creation, and implies get_config for reading the current config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use: 'Use this when no config file has been found'. It also provides the next step to call reload_config. While it doesn't explicitly exclude other use cases, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read from Firebase Firestore. Use the operation field to select what to do.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Document IDs within the collection field (used with collection for get_many_documents) | |
| path | No | Document path (EVEN segments, e.g. 'users/123' or 'stores/ABC') | |
| field | No | Single field name to count unique values for. Use fields[] for multi-field grouping. | |
| limit | No | Max number of documents to return | |
| paths | No | Full document paths for batch fetch (e.g. ['users/123', 'orders/456']) | |
| fields | No | Multiple field names to fetch. Each result value is an object keyed by field name. Use groupByFields to group on a subset. | |
| select | No | Field paths to return. Omit for all fields. | |
| filters | No | Where-clause filters | |
| orderBy | No | Ordering of results | |
| operation | Yes | - list_paths: Returns all named path templates registered in config for this project. Each entry has a template (using {param} placeholders), the extracted parameter names, whether it resolves to a document (even segments) or collection (odd segments), and an optional description. Call this early to avoid exploring the schema from scratch. - list_collections: List root collections, or subcollections of a document. Args: path?(EVEN segments — document path, e.g. "stores/ABC"), includeCounts?(bool). Returns collection paths (ODD segments) → use with list_documents or read_collection. - list_documents: List all doc IDs including phantoms. Always includes subcollections per doc. Args: collection(ODD segments). Returns document paths (EVEN segments) with collections[] → use with get_document or list_collections. - read_collection: Read documents from a collection. Args: collection(ODD segments), limit?, select?[], startAfter?(doc ID), includePhantoms?(bool) - get_document: Fetch a single document by path. Args: path(EVEN segments, e.g. "users/123"), select?[] - get_many_documents: Batch-fetch documents. Args: paths?[](each EVEN segments) OR (collection(ODD segments) + ids[]); select?[] - query_collection: Query with filters/ordering/pagination. Args: collection(ODD segments), filters?[], orderBy?[], limit?, select?[], startAfter?(doc ID) - query_collection_group: Query across all subcollections with the same name. Args: collectionId(single name, no slashes), filters?[], orderBy?[], limit?, select?[], startAfter?(full doc path) - count_documents: Server-side count without fetching docs. Args: collection(ODD segments), filters?[] - aggregate_collection: Server-side sum/avg/count aggregations. Args: collection(ODD segments), aggregations[]{alias,type,field?}, filters?[] - get_collection_schema: Infer field types by sampling docs. Args: collection(ODD segments), sampleSize?(default 20) - list_indexes: List composite indexes. Args: collectionGroup?(filter by name), includeNotReady?(bool) - distinct_values: Count occurrences of each unique value (or value combination) of one or more fields. Source: collection(ODD segments) OR collectionId(single name — queries across ALL subcollections with that name, like query_collection_group). Fields: field(single field name) OR fields([array of field names] — each result value becomes an object keyed by field name). groupByFields?([subset of fields] — use only these as the identity/grouping key; remaining fields become label arrays of unique values seen per group, e.g. groupByFields:["cashier"] with fields:["cashier","cashierNm"] groups by cashier ID while collecting all cashierNm variants as a label — useful when a display name varies across collections but the ID is stable). filters?[]. groupByPathSegment?(integer — when using collectionId, extracts this segment from the parent collection path as the byCollection key, e.g. 2 turns "shared/stores_data/ABC123/data/purchase_orders" into "ABC123"). minCollections?(integer or "all" — only return values present in at least this many distinct collection buckets; "all" means present in every bucket found without knowing the count upfront; operates on the groupByFields key so label variation across buckets does not cause missed matches; all values are annotated with collectionCount and collections[] regardless). Fetches all matching docs internally (up to maxBatchFetchSize). Returns values[] sorted by count desc. When using collectionId, also returns byCollection{} broken down by parent collection (or extracted segment). | |
| projectId | Yes | Project key as defined in firebase-mcp.json | |
| collection | No | Collection path (ODD segments, e.g. 'users' or 'users/123/posts') | |
| sampleSize | No | Number of documents to sample (default 20) | |
| startAfter | No | Pagination cursor: doc ID for collection queries, full doc path for collection group queries | |
| aggregations | No | Aggregation specs for aggregate_collection | |
| collectionId | No | Collection name without slashes (e.g. 'orders') for collection group operations | |
| groupByFields | No | Subset of fields[] to use as the grouping/identity key. Remaining fields are collected as label arrays (unique values seen per group). Allows minCollections to operate on a stable ID field even when a display name varies across collections. | |
| includeCounts | No | Include document count per collection | |
| minCollections | No | When using collectionId: only return values that appear in at least this many distinct collection buckets. Pass a number (e.g. 2) or "all" to mean "present in every collection bucket found". All returned values are annotated with collectionCount and collections[] regardless. | |
| collectionGroup | No | Filter results to a specific collection group name | |
| includeNotReady | No | Include indexes still being created or needing repair | |
| includePhantoms | No | Fall back to listDocuments() when the collection returns no docs | |
| groupByPathSegment | No | When using collectionId: 0-based index of the path segment to use as the byCollection key instead of the full path (e.g. 2 extracts "ABC123" from "shared/stores_data/ABC123/data/purchase_orders") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses detailed behavior for all operations, including internal fetching limits ('up to maxBatchFetchSize') for distinct_values, pagination mechanics (startAfter), and path segment conventions. No destructive actions implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long and embeds detailed operation-by-operation documentation in a single paragraph. While comprehensive, it lacks bullet points or separation that would improve scannability. The two introductory sentences are efficient, but the bulk is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 23 parameters, no output schema, and no annotations, the description thoroughly covers all operations, parameter constraints (e.g., path segment parity), and edge cases (e.g., minCollections, groupByPathSegment). It provides enough detail for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant value for the 'operation' parameter with detailed enum descriptions. For other parameters, it largely reiterates schema info (e.g., path segments) but still provides helpful context like 'ODD segments' that clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Read from Firebase Firestore' with a verb and specific resource. It distinguishes from sibling tools (auth_read, create_config, etc.) which deal with authentication and configuration. The operation field is introduced as the mechanism to choose a read action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive guidance on when to use each operation, e.g., 'Call this early to avoid exploring the schema from scratch' for list_paths. Explicitly defines arguments and constraints per operation (e.g., EVEN vs ODD path segments). No need to exclude siblings as they are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all in-memory project configs (excluding sensitive fields, e.g. serviceAccountPath). Use to find available projectId values. If hasPaths is true, use firestore_read list_paths for path templates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool excludes sensitive fields (e.g., serviceAccountPath), which is a key behavioral trait. It also implies the configs are in-memory, though it could further clarify read-only behavior or potential performance impacts. The disclosure is sufficient to avoid misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence delivers the primary purpose and a key exclusion, and the second sentence provides an alternative use case. No wasted words, and the structure is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description adequately explains the return value: 'all in-memory project configs (excluding sensitive fields)'. It also gives a specific use case (finding projectId values) and provides alternatives. For a parameterless read-only tool, this is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters and schema coverage is 100% (vacuous). The description adds meaning beyond the schema by explaining what the tool returns (all configs, excluding sensitive fields) and its purpose (finding projectId values). This enriches the semantic understanding, earning a baseline-adjusted score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('in-memory project configs'), and specifies that it excludes sensitive fields like serviceAccountPath. It also provides a distinct use case: finding available projectId values. This differentiates it from siblings such as create_config and reload_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use an alternative: 'If hasPaths is true, use firestore_read list_paths for path templates.' This directly tells the agent when not to use this tool and provides a sibling alternative, which is excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-reads the config file from disk and evicts all cached project runtimes. Use this after the user says they have changed their firebase-mcp.json config.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral traits: re-reading config and evicting caches. This alerts the agent to potential side effects (cache invalidation). It could mention impact on other tools or need to reauthenticate, but for a zero-parameter tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action and then the usage trigger. Every sentence adds value with zero waste. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and the straightforward action, the description is complete. It covers what the tool does and when to use it. No information is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params, 100% schema coverage by default). The description adds no parameter information because none is needed. Baseline for 0 params is 4, and the description meets that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('re-reads the config file from disk and evicts all cached project runtimes') and explicitly distinguishes its use case from siblings by referencing when to use it ('after the user says they have changed their firebase-mcp.json config').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by stating when to use this tool (after config changes). While it doesn't list when not to use it or alternatives, the context of sibling tools implies usage boundaries. It effectively communicates the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource or operation: authentication, Firestore, config template, config reading, and config reloading. There is no overlap in purpose.
Two tools use noun_verb pattern (auth_read, firestore_read) while three use verb_noun (create_config, get_config, reload_config). This inconsistency can confuse agents about the naming convention.
5 tools is reasonable for a server focused on reading from Auth and Firestore plus configuration management. It is not excessive but could be expanded for full coverage.
The server lacks write operations for both Auth and Firestore (e.g., create user, update document), and does not cover other Firebase services like Realtime Database or Storage. This leaves significant gaps for typical Firebase management tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/s-h-u-h-a-r-i/firebase-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server