Loading ToolBench
MCP server for Firebase Firestore operations
Server demonstrates solid fundamentals with complete JSON schemas, clear descriptions, and well-organized tool structure. However, several patterns are underutilized: no tool annotations (readOnlyHint/destructiveHint), limited error recovery guidance, and missing documentation of response schemas. Output descriptions are present but vary in depth. All 9 tools are properly registered with input schemas and descriptions, placing this in the 'Fair to Good' range (C+/B- territory). The dual-endpoint (emulator/production) design is thoughtful, but the confirmation pattern for write operations could be more prominent. This is a competent community server that would benefit from stronger error handling and response documentation.
Fetch multiple documents by ID in a single request. Uses Firestore's getAll() for efficiency. Supports subcollection paths.
Count documents in a collection with optional where conditions. Uses Firestore's native count() aggregation (no document fetching). Supports subcollection paths.
Create a new document in a collection. Supports subcollection paths (e.g. 'users/uid/posts').
Delete a document. Supports subcollection paths (e.g. 'users/uid/posts').
Get a specific document by ID. Supports subcollection paths (e.g. 'users/uid/posts').
List collections. Lists top-level collections by default, or subcollections of a specific document when documentPath is provided.
Missing tool annotations: no readOnlyHint, destructiveHint, or idempotentHint metadata. This prevents clients from understanding operation safety (read-only vs destructive) and makes it harder for agents to reason about idempotency and retry safety.
No documented output/response schemas. While tools return structured data, the response format is not formally documented in tool definitions. LLMs cannot plan downstream calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Query documents in a collection with pagination support. Supports subcollection paths.
Query documents with where conditions and optional pagination. Supports subcollection paths.
Update an existing document. Supports subcollection paths (e.g. 'users/uid/posts').
Error handling lacks recovery guidance. The error response builder (buildErrorResponse) does not provide actionable context to help agents self-recover (e.g., 'Connection failed; ensure Firestore emulator is running on $FIRESTORE_EMULATOR_HOST').
Confirmation pattern for production writes is weak. The 'confirm' parameter defaults to false but does not provide interactive confirmation flow. For destructive operations (delete_document), a two-step approval process or explicit agent guidance is missing.
Pagination support is minimal. query_collection and query_with_where accept 'startAfter' but the response does not document a 'lastDocId' or 'hasMore' field for agents to continue pagination correctly.
Parameter validation rules are underdocumented. The 'where' parameter in query_with_where accepts array-of-arrays but does not specify valid operators (==, <, >, <=, >=, !=, array-contains, in, etc.) or value coercion behavior clearly enough for LLM self-correction.