firebase-mcp-server

Why it exists

An agent working in a Firebase app is working half-blind. It can call the Admin SDK, but it has no idea what a document is supposed to look like — which fields are current, which are half-migrated, which were renamed two releases ago and never cleaned up. So it reads a collection, infers a shape from whatever happens to be there, and writes something plausible that quietly doesn’t match.

Most Firebase tooling for agents leans into that: hand over raw SDK access and hope. It holds up until the data has history in it. This one starts from the schema you already keep — Firebase’s own path convention, users/{userId}/orders/{orderId} — and checks every read and write against it, aware that a field can be official, experimental, or legacy, not merely present or absent.

The other half is the context window. A naive “read this collection” answer pulls thousands of documents through the model just to count them. The query tools return the count, the sum, the projection, the overview — the answer, not the raw material for it — which is the difference between a question an agent can afford to ask and one it can’t.

The tool list is itself a context cost, charged before anything is asked: thirty-three tool definitions run to roughly twelve thousand tokens in every session. So the surface divides. --tools firestore loads the twelve Firestore tools and leaves Auth, Storage, and logging out of the conversation entirely.

And it works without a schema at all: pointed at an unfamiliar database it discovers collections rather than refusing. Schemas make it careful; their absence doesn’t make it useless.