firebase-tools: the Firebase CLI and its MCP server

What firebase-tools actually solves, and for whom

Firebase projects have a console, but console work does not fit into a build pipeline. firebase-tools is the command line surface for the same resources: deploying code and assets, running a local web server for a Hosting site, reading and writing data in a Firebase database, and importing or exporting users through Firebase Auth. The README lists those four capabilities explicitly, and the command tables expand them into configuration, project management, deployment and emulation, and App Distribution groups.

The audience is narrower than "anyone deploying a website". Project-specific commands require either an active project alias in the current directory or an explicit -P <project_id> flag, so the tool assumes you are working against a Firebase project, not an arbitrary host. Teams already on Firebase get a single binary that covers setup, local emulation and release. Teams evaluating it as a neutral deployer will find the project model baked into almost every command.

How the CLI is put together, from firebase.json to the emulator suite

The repository is TypeScript, with src/ holding the implementation and lib/ holding the compiled output that the firebase binary points at: package.json maps the bin entry to ./lib/bin/firebase.js. The build script runs a Vite build for the MCP apps first, then tsc, then a copy step that moves src/dynamicImport.js and the firebase_studio directory into lib/. That ordering matters if you build from source: the MCP apps are compiled separately from the main TypeScript pass.

Configuration is file-driven. firebase init writes a firebase.json into the current directory, and the deploy and serve commands rely on that file. The schema directory contains a generated firebase-config.json, produced by typescript-json-schema from the FirebaseConfig type in src/firebaseConfig.ts, so the shape of the config file is machine-checked in the repository rather than only described in prose.

The emulator side is a separate lifecycle. emulators:start brings up local emulators, emulators:exec starts them, runs a test script, then shuts them down, and setup:emulators:database and setup:emulators:firestore download the individual emulators. That split is deliberate: the emulator binaries are fetched on demand instead of shipping inside the npm package.

The repository also hosts the official Firebase MCP Server, with its own documentation under src/mcp. The README presents it alongside the CLI rather than as a separate product, and package.json carries an mcpName field of io.github.firebase/firebase-mcp.

Installing firebase-tools and running a first deploy

There are two documented install paths. The npm route requires Node.js and npm, and installing Node.js brings npm with it. The global install exposes a firebase command on your PATH.

npm install -g firebase-tools

After that, firebase --help lists the available commands, and firebase <command> --help gives details for one command. The standalone binary route downloads a firebase executable with no dependencies:

curl -sL firebase.tools | bash

Authentication needs a browser for the normal path. firebase login opens one. On a machine you reach over SSH, the README documents firebase login --no-localhost, which copies and pastes a code instead of starting a local server. For non-interactive environments, Firebase recommends Application Default Credentials; login:ci is a legacy method that Firebase no longer recommends.

From there the first real use is initialising a project directory. firebase init sets up the current project directory, associates it with a selected Firebase project and creates firebase.json there. Once that file exists and a project alias is active, firebase deploy reads the configuration and your local project folder and pushes the result. If you would rather not touch a live project first, emulators:start brings up the local emulators so the same configuration can be exercised offline.

Where firebase-tools is the wrong tool

The most concrete limitation is the project model. The README states that a project-specific command needs either a project directory with an active alias or the -P <project_id> flag. There is no mode where the CLI deploys to an arbitrary target that is not a Firebase project. If your hosting lives on S3, Cloudflare Pages or a plain VPS, this tool has nothing to offer you, and the deploy command will not become useful by adding flags.

The emulator setup is a second constraint. The database and Firestore emulators are downloaded by separate setup commands rather than bundled, so a first run in a network-restricted CI container can fail before any test executes. That is a design choice with a real cost.

Authentication is the third friction point. Interactive login requires a browser, with --no-localhost available for remote environments. For CI, configure Application Default Credentials; the older login:ci token method is no longer recommended.

firebase-tools compared with the Google Cloud CLI

The obvious alternative is gcloud, the Google Cloud command line. The difference is the unit of work. gcloud operates on Google Cloud resources: projects, service accounts, compute, storage buckets. firebase-tools operates on Firebase resources and on the firebase.json file that describes them, with commands like apps:create, apps:sdkconfig, projects:addfirebase and appdistribution:distribute that have no direct gcloud equivalent in this repository's command list.

The two overlap at the project level. projects:addfirebase adds Firebase resources to an existing Google Cloud Platform project, which is the documented bridge between the two tools. So the split is not either/or: gcloud provisions the underlying cloud project, and firebase-tools turns on Firebase features and deploys the app layer.

Where they diverge is local development. firebase-tools ships an emulator suite with emulators:start and emulators:exec, and a serve command that runs a local server using your Hosting configuration and HTTPS-triggered Cloud Functions. If your work is mostly provisioning infrastructure, gcloud is the right entry point. If it is deploying and testing a Firebase app, firebase-tools is.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-11-02. Releases are frequent: v15.34.2 on 2026-10-28, v15.34.1 on 2026-10-22, and v15.34.0 on 2026-10-15, all within the same month. For a CLI that talks to hosted services, that cadence is the relevant signal, because API changes on the Firebase side tend to surface as new CLI versions rather than as configuration you can patch yourself.

The upgrade cost is mostly on the Node side. The npm install path requires Node.js and npm, and the package declares a Node version badge in the README, so a pinned runtime in CI needs to track that. The standalone binary avoids the Node dependency entirely, which is the reason to prefer it on build machines where you do not want a Node toolchain.

firebase-tools is MIT licensed, and the LICENSE file sits at the repository root. That is a permissive licence, but it covers this CLI, not the Firebase services it talks to. The terms that govern your project's data, quotas and billing come from the Firebase and Google Cloud side, and nothing in this repository changes those. Treat the licence question and the service-terms question as separate reviews.

Editorial conclusion

Adopt firebase-tools if your backend already lives in Firebase or Google Cloud and you want deploys, emulators and project management in one binary, including the MCP server for editor agents. Do not adopt it as a generic static-site deployer or as a cloud-agnostic tool: every project-specific command expects a Firebase project id or an active alias. Before committing, verify three things in your own environment: that Node.js and npm meet the version the package declares, that interactive login works or Application Default Credentials are configured for CI, and that your deploy target matches what firebase init writes into firebase.json, since deploy relies on that file.

Frequently asked questions

Official sources

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