Skip to main content
Glama
s-h-u-h-a-r-i

firebase-mcp

firestore_read

Read data from Firebase Firestore: list collections and documents, fetch single or multiple documents, query with filters and ordering, perform aggregations and count, and inspect indexes and distinct values.

Instructions

Read from Firebase Firestore. Use the operation field to select what to do.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNoDocument IDs within the collection field (used with collection for get_many_documents)
pathNoDocument path (EVEN segments, e.g. 'users/123' or 'stores/ABC')
fieldNoSingle field name to count unique values for. Use fields[] for multi-field grouping.
limitNoMax number of documents to return
pathsNoFull document paths for batch fetch (e.g. ['users/123', 'orders/456'])
fieldsNoMultiple field names to fetch. Each result value is an object keyed by field name. Use groupByFields to group on a subset.
selectNoField paths to return. Omit for all fields.
filtersNoWhere-clause filters
orderByNoOrdering of results
operationYes- 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).
projectIdYesProject key as defined in firebase-mcp.json
collectionNoCollection path (ODD segments, e.g. 'users' or 'users/123/posts')
sampleSizeNoNumber of documents to sample (default 20)
startAfterNoPagination cursor: doc ID for collection queries, full doc path for collection group queries
aggregationsNoAggregation specs for aggregate_collection
collectionIdNoCollection name without slashes (e.g. 'orders') for collection group operations
groupByFieldsNoSubset 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.
includeCountsNoInclude document count per collection
minCollectionsNoWhen 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.
collectionGroupNoFilter results to a specific collection group name
includeNotReadyNoInclude indexes still being created or needing repair
includePhantomsNoFall back to listDocuments() when the collection returns no docs
groupByPathSegmentNoWhen 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")
Behavior5/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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