firebase-tools: the CLI that grew an MCP server inside it

A CLI that grew an MCP server

The Firebase Command Line Interface Tools test, manage and deploy Firebase projects from the command line, four headline capabilities, deploy code and assets to Firebase projects, run a local web server for Firebase Hosting, interact with data in the Firebase database, and import or export users into and from Firebase Auth. The notable recent addition is stated in the repository's own title, this is also the home of the official Firebase MCP Server, living under src/mcp with its own documentation and registered in package.json under the mcpName io.github.firebase/firebase-mcp. The README even carries a one-click Cursor MCP install badge. For humans, the entry points are firebase --help for the command list and firebase with a command and --help for details, with the full reference at firebase.google.com/docs/cli.

A global npm package or a dependency-free binary

Two installation paths cover both kinds of machine. The Node route is one command, npm install -g firebase-tools, which requires Node.js and npm installed and provides the globally accessible firebase command. The standalone route skips the runtime entirely, downloading a firebase executable without any dependencies via

curl -sL firebase.tools | bash

The choice matters mostly on build machines and locked down laptops where a Node toolchain is unwanted or absent. The published version moves fast, v15.30.2 on 2026-09-17, v15.31.0 on 2026-09-23 and v15.32.0 on 2026-09-28, essentially a weekly release cadence, with the repository pushed 2026-09-26, so the CLI tracks the platform closely rather than shipping in bursts.

login:ci and --no-localhost for headless machines

The authentication command family anticipates the awkward environments. login authenticates to the Firebase account but requires access to a web browser, and appending --no-localhost switches the flow to copy and paste a code instead of starting a local server, with the README naming the exact use case, SSH into an instance somewhere and authenticate on that machine. login:ci generates an authentication token for non-interactive environments, the CI pipeline answer. Multi-account workflows get login:add to authorize an additional account, login:list to enumerate them, and login:use to set the default for the current project, with logout closing sessions. This is a tool designed by people who have actually had to deploy from a server with no GUI.

firebase.json as the contract

Project-level state hangs off two mechanisms. init sets up a new Firebase project in the current directory and creates a firebase.json configuration file there, the artifact everything else reads. deploy ships the project relying on that firebase.json and the local project folder, and serve starts a local server from the Firebase Hosting configuration plus HTTPS-triggered Cloud Functions, reading the same file. Project selection follows the rule that project-specific commands require either a project directory with an active project alias or the Firebase project id passed with -P, and the use command manages those aliases, switching the active project and maintaining the mapping. The open command rounds out the workflow by opening a browser directly to relevant project resources, a small convenience that saves hunting through the console.

Emulators with a scripted lifecycle

The local emulation commands come in two shapes for two workflows. emulators:start starts the local Firebase emulators and keeps them running for interactive development. emulators:exec starts the emulators, runs a test script, and then shuts them down, the shape a CI pipeline needs, since cleanup is guaranteed by construction rather than by a cleanup step someone forgets. The emulators themselves are downloadable through setup:emulators:database and setup:emulators:firestore, each fetching its component separately, which keeps the initial install lean and the emulator versions manageable. Combined with serve for hosting and functions, the loop of emulate locally, test against emulators, then deploy is executable entirely from this one CLI.

App distribution from the same binary

Mobile release work also routes through the CLI. appdistribution:distribute uploads a release binary and optionally distributes it to testers and runs automated tests, putting the build-plus-testers step of a release pipeline into the same tool that deployed the backend. appdistribution:testers:list enumerates the testers in a project for scripting distribution lists. Alongside the project management family, apps:create, apps:list and apps:sdkconfig for registered apps, and projects:create, projects:list and projects:addfirebase for the projects themselves, the last of which adds Firebase resources to an existing Google Cloud Platform project, the bridge between the two Google consoles. The breadth is the point, one CLI spans console, emulator and app store adjacency.

A VS Code extension, a schema, and agent-shaped roots

The repository's extra directories show where the tool is heading. firebase-vscode holds a Visual Studio Code extension, extending the surface beyond the terminal. The schema directory receives a generated JSON schema for firebase.json, produced by the generate:json-schema script from the FirebaseConfig TypeScript source with strict null checks and required properties, so editors can validate project configuration. The agent era is visible in the root files, GEMINI.md, a .claude-plugin directory and an .agent directory, and the build pipeline compiles MCP apps with Vite for update_environment, init and deploy flows. Mocha runs the tests, templates seed new projects, and standalone holds the binary distribution machinery, one repository feeding three delivery channels.

Editorial conclusion

Use firebase-tools as the primary interface whenever Firebase work happens from a terminal or script, deployment, local emulation before deployment, database interaction and auth user management all live in the one binary, and the MCP server extends the same surface to agent driven workflows. The standalone binary suits machines without a Node toolchain, the npm global suits everyone else. Before scripting it in CI, generate a login:ci token for non-interactive environments and decide between project aliases and the -P flag for project selection, and read the src/mcp documentation before pointing an agent at the MCP server so its capabilities and safety model are clear.

Frequently asked questions

Official sources

1. firebase/firebase-tools on GitHub
2. Issues
3. License: MIT
4. README
5. Releases