Firebase Emulator MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.3
Disambiguation5/5
Each tool targets a clear, distinct resource and action: Firestore operations are separate (list collections, query, get document), RTDB has a single get, Auth has list and get, and status/logs are emulator-wide. No two tools overlap in purpose.
Naming Consistency4/5
Most tools follow a consistent {service}_{action} pattern (firestore_list_collections, firestore_get, auth_list_users), but emulator_status and emulator_logs deviate to a noun-based pattern. Still predictable and easy to navigate.
Tool Count5/5
Eight tools is well-scoped for a Firebase emulator server, covering the core services (Firestore, RTDB, Auth) plus status and logs without unnecessary bloat.
Completeness2/5
The tool surface is heavily read-only: Firestore only supports list, query, and get, with no create, update, or delete operations. RTDB and Auth similarly lack write operations, making it impossible to fully manage data in the emulator.
Average 3.4/5 across 8 of 8 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Query documents,' which is essentially a reuse of the tool name. It does not disclose whether the operation is read-only, whether authentication is needed, what the return format is, or any rate limits or side effects. This is severely lacking behavioral transparency.
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?
The description is a single sentence with no wasted words, which is structurally concise. However, it is under-specified to the point of being minimally helpful. It is neither overly long nor confusing, but it also lacks the substance expected of a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description needs to explain how the query works, what input constraints exist, and what results look like. The single sentence covers only the high-level action, leaving out all necessary operational details. This is highly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It mentions none of the five parameters (collection, limit, whereField, whereValue, whereOperator). The description adds no meaning beyond the empty property names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Query' and the resource 'documents in a Firestore collection,' making the basic purpose understandable. However, it does not distinguish this from the sibling tool 'firestore_get' (which likely retrieves a single document) or clarify that querying involves filters. It is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'firestore_get' or 'firestore_list_collections.' There are no context clues, exclusions, or alternative mentions. The description gives the agent no help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only states the action without revealing details such as pagination through the limit parameter, default behavior, return format, or any required authentication. This is essentially a restatement of the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is front-loaded and efficient, delivering the core message without any fluff. While it is brief, conciseness itself is excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse to fully inform an agent. It does not explain the limit parameter's effect, whether the result is a complete list or truncated, or how it differs from auth_get_user. The description is minimally viable but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes a limit parameter with a default of 50, but the description does not mention it. With schema description coverage at 0%, the description fails to add any meaningful context about how the parameter works or when to override the default.
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?
The description uses a specific verb ('List') with a clear resource ('users from Auth emulator'). This distinguishes it from the sibling tool auth_get_user, which implies a single-user lookup. It unambiguously communicates the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like auth_get_user. It does not mention use cases, exclusions, or context for choosing list over get operations. The description offers no strategic selection help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It reveals the transport and endpoint, but does not explain whether the stream is continuous or one-shot, what the output format is, or any side effects. The word 'stream' may even conflict with the 'lines' parameter, which suggests a finite return, creating ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and includes the endpoint. Every word provides useful information with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the returned log entries look like or how the streaming behavior terminates. The ambiguity between 'stream' and the 'lines' parameter leaves a completeness gap for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter, 'lines', has a clear description in the schema. The tool description itself adds no additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.
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?
The description clearly states a specific action ('Stream recent log entries') and resource ('Firebase emulator hub WebSocket') with an explicit endpoint. This distinguishes it from sibling tools like emulator_status, which focuses on status rather than logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving emulator logs but does not explicitly state when to use this tool vs alternatives or any exclusions. It names the resource and action, giving context, but lacks clear 'when to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'check reachability' but does not explain what the tool returns, whether it performs network I/O, or how failures are reported. This is too minimal for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that gets to the point immediately. Every word is necessary and there is no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description fails to explain what the caller receives (e.g., a list, a boolean, per-emulator statuses). It also lacks information about edge cases, such as whether all emulators must be running. The description is too sparse for a standalone tool.
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?
The tool has zero parameters, so the baseline is 4. There is no parameter information to add, and the description correctly makes no mention of parameters.
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?
The description uses a specific verb 'check' and names the resource 'Firebase emulators' with scope 'all', clearly distinguishing this tool from the sibling data-access and log tools. It exactly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions. While the purpose implies a pre-flight check, no explicit context or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. 'Get' implies a read-only operation, but the description does not disclose error behavior (e.g., what happens if the identifier is not found), authentication requirements, or return format. It adds no context beyond the minimal implication of a read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence that directly states the purpose and key input detail. Every word contributes value, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple structure (1 param, no output schema), and the description adequately conveys the basic operation. However, the absence of any return-value description, error semantics, and usage context means the agent gets only a minimal understanding. It is sufficient for a simple getter but leaves clear gaps.
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?
The input schema only defines 'identifier' as a string with zero description, so the description must compensate. It does so by explicitly stating that the identifier can be an 'email or localId', adding meaningful domain semantics that help the agent construct the parameter correctly. This goes beyond the bare schema but could be improved with format examples.
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?
The description clearly states a specific verb ('Get') and resource ('a single Auth user') with a differentiating scope ('by email or localId'). It distinguishes this tool from siblings like auth_list_users (list vs single) and firestore_get/rtdb_get (Auth vs other data stores).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like auth_list_users or firestore_get. It does not mention any exclusions, prerequisites, or typical use cases, leaving the agent to infer from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. 'List' implies a read-only operation, and 'from Firestore emulator' provides context about the environment. However, it does not disclose return format (e.g., array of strings), potential absence of collections, or any edge cases. This is adequate for a simple read tool but not maximally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, with zero wasted words. It is perfectly sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, no output schema), the description provides the essential context: it lists root-level collection IDs specifically in the emulator environment. It is complete enough for an agent to understand the tool's purpose, though it could mention the return type explicitly.
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?
The tool has 0 parameters, so the schema coverage is trivially 100%. Per the rubric, 0 params earns a baseline of 4. The description adds no parameter info, but none is needed.
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?
The description clearly states the verb 'List' and the specific resource 'root-level collection IDs from Firestore emulator', distinguishing it from sibling tools like firestore_query (which queries documents) and firestore_get (which retrieves a specific document). The 'root-level' scope adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in the context of the Firestore emulator (when you want to see available collections), but it does not explicitly mention when NOT to use it or provide alternatives. It provides clear context but lacks exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone establishes that this is a read-only operation targeting the Realtime Database emulator, which are key behavioral traits. However, it omits details on return format, error behavior, or whether the entire subtree is returned, leaving some room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded with the verb and resource. Every word earns its place, with no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema and no annotations, the description is largely complete. It names the resource (RTDB emulator), the operation (read), and the input (path). The default path is captured in the schema, and the simplicity of the tool reduces the need for extensive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'path' parameter, including examples and a default value. The description merely repeats 'at a given path' without adding semantic meaning beyond the schema, so the baseline of 3 applies.
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?
The description states a specific verb ('Read'), a clear resource ('Realtime Database emulator'), and a scope ('at a given path'), which distinguishes it from sibling tools like firestore_get and auth_get_user. The purpose is unmistakable and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for reading RTDB emulator data) but does not explicitly contrast it with alternatives such as firestore_get or auth_get_user. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a read operation ('Get') but does not specify behavior when the document is not found, whether any authentication is needed, or what the return value looks like. The path example adds some context, but significant behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the core purpose and includes an example. Every word earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly adequate. However, it lacks any mention of return values or error behavior when the document doesn't exist. Since no output schema exists, the description should have provided a bit more context about what happens on success or failure.
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?
The schema has one parameter 'path' with no description, and description coverage is 0%. The description compensates by explaining that path is the document path and provides a concrete example ('Member/abc123'), adding meaning beyond the bare schema.
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?
The description clearly states the tool gets a single Firestore document by path, using a specific verb ('Get') and resource ('Firestore document'). It also gives a path example, which distinguishes it from sibling tools like firestore_list_collections (list) and firestore_query (query multiple), and rtdb_get (different database).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need a single document and know its path. The example 'Member/abc123' clarifies the expected path format. However, it does not explicitly mention alternatives or when not to use it, but the context is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![firebase-emulator-mcp MCP server](https://glama.ai/mcp/servers/LaishGlenberg/firebase-emulator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LaishGlenberg/firebase-emulator-mcp)

Score Badge

Copy to your README.md:

[![firebase-emulator-mcp MCP server](https://glama.ai/mcp/servers/LaishGlenberg/firebase-emulator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LaishGlenberg/firebase-emulator-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/LaishGlenberg/firebase-emulator-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server