[danbarr]

Summary

Packages the official Firebase MCP server, which ships as the firebase mcp command of the firebase-tools npm package, as a pinned Dockyard image. Adds npx/firebase-tools/spec.yaml pinned to 15.34.1 with args: ["mcp"] so the entrypoint is npx firebase-tools mcp over stdio. No changes to cmd/dockhand/ or internal/skills/, so this does not trigger a full-catalog rebuild.

Closes #1192

Provenance and license

• License: MIT. npm view firebase-tools@15.34.1 license returns MIT, package.json:82 at tag v15.34.1 says "license": "MIT", and the repo LICENSE is the MIT License (Copyright (c) 2015 Firebase).
• Source: the tag v15.34.1 in firebase/firebase-tools resolves to commit e5d39c8a90d77dcbd5550dd6f5adb6194719a8b9, which equals the npm gitHead of the published 15.34.1 tarball.
• dockhand verify-provenance reports Status: SIGNATURES (npm registry signatures only). The package has no sigstore attestations, so the spec does not declare an attestations block.

Validation

• ./build/dockhand verify-provenance -c npx/firebase-tools/spec.yaml -v: pass, SIGNATURES (see above).
• task build -- npx/firebase-tools: pass, Dockerfile generated with ENTRYPOINT ["npx", "firebase-tools", "mcp"], non-root appuser.
• task scan -- npx/firebase-tools: pass, "No security issues found in firebase-tools (19 tools scanned)". Caveat: the scanner ran with the yara analyzer only (no LLM key locally), so LLM-analyzer findings are not covered by this local run. No allowed_issues entries were needed and none were added. The first two scan attempts timed out on a cold npx install of the large package (60s connect limit in the scanner) and left a partial npx cache; after clearing that one cache entry and warming it, the scan passed. CI could hit the same cold-start timeout.
• task test-build -- npx/firebase-tools: the Taskfile step failed locally because it calls podman and no Podman machine was running ("Cannot connect to Podman"). I built the same generated Dockerfile.test with docker build instead, which succeeded (arm64 host). amd64 was not built locally; multi-arch publishing is left to CI.
• Container smoke test (docker run -i): MCP initialize returned in about 2.6s with serverInfo firebase 0.3.0, and tools/list returned 19 tools with no project mounted.
• thv run test-firebase-tools:latest --transport stdio -v <proj>:/workspace:ro -- --dir /workspace (ToolHive v0.56.0, default network isolation on): server reached running and thv mcp list tools returned the tool list. The test workload was stopped and removed afterwards.

Project directory (--dir)

src/bin/mcp.ts:47 documents --dir <path> (project root, defaults to cwd), and src/bin/mcp.ts:117 resolves it into projectRoot. Mounting a directory containing firebase.json and .firebaserc and passing --dir /workspace changed the result: firebase_get_environment reported Project Directory: /workspace, Active Project ID: demo-test (alias: default), and tools/list grew from 19 to 66 tools (auto-detected Firestore, Data Connect, Auth, Functions, Remote Config, Realtime Database and more, per src/mcp/index.ts:209-226). The image does not set a working directory, so the catalog entry should either pass --dir or set the workdir to the mount. Use a read-write mount for firebase_init and firebase_deploy (they write or read project files); a read-only mount is fine for read-only use.

Browserless authentication

Verified against source at tag v15.34.1:

• src/requireAuth.ts:42 builds a GoogleAuth client and src/requireAuth.ts:54 calls getAccessToken() with the cloud-platform scope, so credentials resolve through standard Application Default Credentials (the google-auth-library lookup: GOOGLE_APPLICATION_CREDENTIALS, then the gcloud ADC file, then metadata server). This path is taken when no --token, no FIREBASE_TOKEN and no signed-in user exist (src/requireAuth.ts:119-142).
• FIREBASE_TOKEN and --token still work but log a deprecation warning pointing to GOOGLE_APPLICATION_CREDENTIALS (src/requireAuth.ts:119-131). The spec does not use them.
• The MCP server treats ADC as authenticated: getAuthenticatedUser returns "Application Default Credentials" when requireAuth succeeds with no email (src/mcp/index.ts:311).
• Empirical check in the built image: with no credentials, GoogleAuth.getCredentials() failed with "Could not load the default credentials", and firebase_list_projects returned the "not currently logged in ... configure Application Default Credentials" error. With a mounted (fake, self-generated) service account key at /creds/sa.json and GOOGLE_APPLICATION_CREDENTIALS=/creds/sa.json, getCredentials() returned the key's client_email and getProjectId() returned its project_id. This proves the container reads the mounted key and that the library behaves as the source says. It does NOT prove an authenticated call succeeds.
• Not verified: any call against a real Firebase project with a real service account or user ADC. That needs real credentials and should be reported separately by someone with a test project. Required IAM is per tool and not enumerated by upstream in one place; at minimum the service account needs roles for the APIs a tool calls (for example Firebase Viewer for read tools, Firebase Admin or the relevant product admin roles for create, deploy and write tools), and the Firebase Management and product APIs must be enabled on the project.
• firebase_login (interactive OAuth with a pasted auth code) is exposed but is not a browserless path; ADC is the supported container path.
• appuser has a writable $HOME (/home/appuser), where the server writes its debug log to ~/.cache/firebase/firebase-debug.log (src/bin/mcp.ts:102-104).

Tools that need an authenticated project

Taken from the _meta of tools/list in the built image (19 tools with no project dir; 66 with a Firestore/Hosting project dir).

• No auth required: firebase_login, firebase_logout, firebase_get_environment, firebase_update_environment, firebase_init, firebase_read_resources, dataconnect_build, dataconnect_list_services, dataconnect_execute_in_emulator, realtimedatabase_get_data, realtimedatabase_set_data (the last two declare no auth requirement in tool metadata but call the database API with the active credentials in practice, so treat them as needing a project).
• Auth required, active project required: firebase_get_project, firebase_list_apps, firebase_get_sdk_config, firebase_create_app, firebase_create_android_sha, firebase_get_security_rules, firebase_deploy, firebase_deploy_status, developerknowledge_answer_query, and the project-scoped product tools that appear when a project dir is mounted (Firestore, Auth, Functions, Remote Config, App Hosting, Messaging, Storage, Data Connect).
• Auth required, no active project required: firebase_list_projects, firebase_create_project, developerknowledge_search_documents, developerknowledge_get_documents.
• Full per-tool flags are visible in src/mcp/tools/** (requiresAuth and requiresProject in each tool's _meta).

Notes for the follow-up ToolHive catalog entry

• Transport: stdio, image ghcr.io/stacklok/dockyard/npx/firebase-tools:15.34.1. Entrypoint already includes mcp; extra args such as --dir /workspace, --only <features> or --tools <names> are appended.
• Env (all optional, all secret-ish): GOOGLE_APPLICATION_CREDENTIALS (path inside the container to the mounted service account JSON), optionally GOOGLE_CLOUD_PROJECT is not required because the project comes from .firebaserc or firebase_update_environment. Do not default FIREBASE_TOKEN (deprecated).
• Mounts: the project directory (for example to /workspace, read-write if firebase_init/firebase_deploy are expected), and the credential file read-only (for example /creds/sa.json:ro). User ADC alternative: mount ~/.config/gcloud/application_default_credentials.json and point GOOGLE_APPLICATION_CREDENTIALS at it.
• Network: outbound HTTPS to Google APIs. From the origins in src/api.ts and src/mcp/**, the core set is oauth2.googleapis.com/www.googleapis.com/accounts.google.com, firebase.googleapis.com, cloudresourcemanager.googleapis.com, serviceusage.googleapis.com, cloudbilling.googleapis.com, developerknowledge.googleapis.com, plus per-product hosts as used (firestore, firebaserules, firebasehosting, firebasestorage, cloudfunctions, firebaseremoteconfig, identitytoolkit, fcm, firebasedataconnect, firebaseapphosting under googleapis.com) and *.firebaseio.com for Realtime Database. A permission profile with *.googleapis.com, *.firebaseio.com and accounts.google.com covers it. Listing tools worked under ToolHive's default network isolation, but authenticated API calls were not exercised, so the final host list should be confirmed with a real project.
• The server may shell out to npx firebase-tools@latest as a fallback CLI command suggestion (src/mcp/index.ts:74); that is only text for the user, not something the container runs.

Open items

• Authenticated tool calls against a real Firebase project (service account and user ADC) are not verified here.
• Scanner run was yara-only locally; CI's scan (with LLM analyzer, if configured) is the authoritative check and may produce findings to triage.
• arm64 and amd64 publishing relies on CI; only an arm64 image was built locally.

🤖 Generated with Claude Code

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[toolhive-release-app]

🔒 MCP Security Scan Results

✅ firebase-tools

• Status: Passed
• Tools scanned: 19
• Result: No security issues detected

---

Summary: Scanned 1 MCP server(s), all passed security checks. ✅

[toolhive-release-app]

🛡️ Grype Vulnerability Scan Results

✅ No fixable High or Critical vulnerabilities found.

firebase-tools

✅ No blocking findings.