Provides secure, permission-controlled access to Firebase Firestore with full CRUD operations, advanced queries, subcollection support, batch operations, transactions, and atomic field value operations for managing documents and collections.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Firestore MCP Server get all users from the users collection"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides secure, permission-controlled access to Firebase Firestore. This server allows AI assistants and other MCP clients to interact with Firestore databases through a standardized interface.
🔐 Granular Permissions: Control access at the collection and operation level
📄 Full CRUD Operations: Create, read, update, and delete documents
🔍 Advanced Queries: Support for filtering, ordering, and limiting results
📁 Subcollection Support: Work with nested collections and documents
🔄 Batch Operations: Execute multiple operations atomically
💾 Transactions: Ensure data consistency with transactional operations
🎯 Field Value Operations: Atomic increments, array operations, and server timestamps
✅ Collection-level access control
🛡️ Operation-specific permissions (read, write, delete, query)
🔒 Default deny with explicit allow rules
📋 Conditional permissions (coming soon)
Related MCP server: MCP Firebase Server
npm install mcp-firestore
# or
yarn add mcp-firestore
# or
pnpm add mcp-firestoregit clone https://github.com/yourusername/mcp-firestore.git
cd mcp-firestore
pnpm install
pnpm buildCreate a .env file with your Firestore configuration:
# Required
FIRESTORE_PROJECT_ID=your-project-id
# Optional - for authentication
GOOGLE_APPLICATION_CREDENTIALS=path/to/service-account.jsonCreate a permissions.json file to control access:
{
"collections": [
{
"collectionId": "users",
"operations": ["read", "write", "query"]
},
{
"collectionId": "posts",
"operations": ["read", "query"]
}
],
"defaultAllow": false
}# With default permissions
mcp-firestore
# With custom permissions file
mcp-firestore --config permissions.json
# With full access (development only)
mcp-firestore --full-access
# With read-only access to specific collections
mcp-firestore --read-only --collections users,postsAdd to your Claude Desktop configuration:
{
"servers": {
"firestore": {
"command": "mcp-firestore",
"args": ["--config", "path/to/permissions.json"],
"env": {
"FIRESTORE_PROJECT_ID": "your-project-id"
}
}
}
}firestore-list-collections
List all accessible collections
{}firestore-get-collection
Get all documents from a collection
{
"collectionId": "users"
}firestore-get-document
Get a specific document
{
"collectionId": "users",
"documentId": "user123"
}firestore-create-document
Create a new document
{
"collectionId": "users",
"documentId": "user123",
"data": {
"name": "John Doe",
"email": "john@example.com"
}
}firestore-update-document
Update an existing document
{
"collectionId": "users",
"documentId": "user123",
"data": {
"name": "Jane Doe"
}
}firestore-delete-document
Delete a document
{
"collectionId": "users",
"documentId": "user123"
}firestore-query-collection
Query documents with filters
{
"collectionId": "users",
"filters": [
{
"field": "age",
"operator": ">",
"value": 18
}
],
"orderBy": {
"field": "createdAt",
"direction": "desc"
},
"limit": 10
}firestore-list-subcollections
List subcollections of a document
{
"documentPath": "users/user123"
}firestore-get-collection-by-path
Get documents from a subcollection
{
"collectionPath": "users/user123/orders"
}firestore-create-document-by-path
Create a document in a subcollection
{
"collectionPath": "users/user123/orders",
"data": {
"item": "Widget",
"quantity": 2
}
}firestore-batch-write
Execute multiple write operations atomically
{
"operations": [
{
"type": "create",
"collectionPath": "products",
"documentId": "product1",
"data": { "name": "Widget" }
},
{
"type": "update",
"documentPath": "inventory/product1",
"data": { "count": 100 }
}
]
}firestore-batch-read
Read multiple documents in one operation
{
"documentPaths": [
"users/user1",
"users/user2",
"products/product1"
]
}firestore-transaction
Execute a transaction with reads and conditional writes
{
"reads": ["products/product1"],
"operations": [
{
"type": "update",
"documentPath": "products/product1",
"data": { "stock": 99 }
}
],
"conditionScript": "return readResults['products/product1'].data.stock > 0;"
}firestore-increment-field
Atomically increment a numeric field
{
"documentPath": "stats/daily",
"field": "visitCount",
"incrementBy": 1
}firestore-array-union
Add elements to an array without duplicates
{
"documentPath": "users/user123",
"field": "tags",
"elements": ["premium", "verified"]
}firestore-server-timestamp
Set fields to server timestamp
{
"documentPath": "users/user123",
"fields": ["lastLogin", "modifiedAt"]
}The server also provides MCP resources for direct access to Firestore data:
firestore://collections - List all collections
firestore://collection/{collectionId} - Access collection data
firestore://collection/{collectionId}/document/{documentId} - Access document data
firestore://path/{path} - Access any path (collections or documents)
// Create a new user
await client.callTool("firestore-create-document", {
collectionId: "users",
documentId: "user123",
data: {
name: "John Doe",
email: "john@example.com",
createdAt: new Date().toISOString()
}
});
// Update user data
await client.callTool("firestore-update-document", {
collectionId: "users",
documentId: "user123",
data: {
lastLogin: new Date().toISOString()
}
});
// Query active users
await client.callTool("firestore-query-collection", {
collectionId: "users",
filters: [
{ field: "status", operator: "==", value: "active" }
],
orderBy: { field: "createdAt", direction: "desc" },
limit: 10
});// Create an order for a user
await client.callTool("firestore-create-document-by-path", {
collectionPath: "users/user123/orders",
data: {
items: ["widget1", "widget2"],
total: 99.99,
status: "pending"
}
});
// Get all orders for a user
await client.callTool("firestore-get-collection-by-path", {
collectionPath: "users/user123/orders"
});// Atomic updates across multiple documents
await client.callTool("firestore-batch-write", {
operations: [
{
type: "update",
documentPath: "products/widget1",
data: { stock: 95 }
},
{
type: "create",
collectionPath: "orders",
data: {
product: "widget1",
quantity: 5,
userId: "user123"
}
},
{
type: "update",
documentPath: "users/user123",
data: { orderCount: 1 }
}
]
});// Increment a counter
await client.callTool("firestore-increment-field", {
documentPath: "stats/global",
field: "totalOrders",
incrementBy: 1
});
// Add tags without duplicates
await client.callTool("firestore-array-union", {
documentPath: "products/widget1",
field: "tags",
elements: ["bestseller", "featured"]
});
// Set server timestamp
await client.callTool("firestore-server-timestamp", {
documentPath: "logs/access",
fields: ["timestamp", "lastModified"]
});Use Minimal Permissions: Only grant access to collections and operations that are necessary
Default Deny: Set defaultAllow: false in production environments
Service Account Security: Protect your service account credentials
Environment Variables: Never commit credentials to version control
Audit Access: Regularly review permission configurations
pnpm test
pnpm test:coveragepnpm build# Build image
docker build -t mcp-firestore .
# Run container
docker run -e FIRESTORE_PROJECT_ID=your-project mcp-firestoreAuthentication Errors
Ensure GOOGLE_APPLICATION_CREDENTIALS points to a valid service account
Check that the service account has necessary Firestore permissions
Permission Denied
Verify collection is listed in permissions configuration
Check that the operation is allowed for the collection
Connection Issues
Confirm project ID is correct
Check network connectivity to Firestore
Contributions are welcome! Please read our Contributing Guide for details.
MIT License - see LICENSE for details.
Built on the Model Context Protocol by Anthropic.
Remove elements from an array field
| Name | Required | Description | Default |
|---|---|---|---|
| documentPath | Yes | Full path to the document | |
| field | Yes | Array field name | |
| elements | Yes | Elements to remove from the array |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action (remove) but doesn't mention permissions needed, whether the operation is atomic, error handling (e.g., if elements aren't present), or side effects. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It's appropriately sized for the tool's complexity, though it could benefit from more detail given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters like 'documentPath' and 'elements'. The description adds no additional meaning beyond the schema, such as format examples or constraints, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove elements from an array field' clearly states the action (remove) and target (array field), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'firestore-array-union' (which adds elements) or other array-modifying tools, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'firestore-update-document' or 'firestore-array-union'. The description lacks context about prerequisites (e.g., the array must exist) or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add elements to an array field without duplicates
| Name | Required | Description | Default |
|---|---|---|---|
| documentPath | Yes | Full path to the document | |
| field | Yes | Array field name | |
| elements | Yes | Elements to add to the array |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the core behavior ('add elements without duplicates'). It doesn't disclose whether this is a mutation operation (implied but not explicit), what permissions are needed, whether it's idempotent, error conditions, or what happens if the field doesn't exist. For a write operation with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the essential purpose with zero wasted words. It's appropriately sized for a tool with clear parameters and no complex behavioral nuances to explain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (success/failure indicators, updated document), doesn't mention Firestore-specific behaviors (like field creation if missing), and provides no context about atomicity or transaction support that would be important for database operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds no additional parameter context beyond what's in the schema descriptions, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add elements') and target ('to an array field'), with the specific behavior 'without duplicates' that distinguishes it from generic array operations. However, it doesn't explicitly differentiate from its closest sibling 'firestore-array-remove', which would have made it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'firestore-update-document' for array modifications or 'firestore-array-remove' for the inverse operation. There's no mention of prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read multiple documents in a single operation
| Name | Required | Description | Default |
|---|---|---|---|
| documentPaths | Yes | Array of document paths to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation, implying non-destructive behavior, but lacks details on permissions, rate limits, error handling, or response format. This is inadequate for a tool that likely involves network calls and data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., document data, errors for missing paths), behavioral aspects like atomicity, or how it fits within the Firestore context. This leaves significant gaps for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'documentPaths' clearly documented as an array of document paths. The description adds no additional parameter semantics beyond what the schema provides, such as path format examples or constraints. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read multiple documents') and the operational context ('in a single operation'), which distinguishes it from single-document read tools like 'firestore-get-document'. However, it doesn't explicitly differentiate from other batch operations like 'firestore-batch-write', leaving some ambiguity about sibling distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like reading multiple documents efficiently, compare it to sequential single reads, or reference sibling tools like 'firestore-get-document' for single documents or 'firestore-batch-write' for writes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute multiple write operations in a single atomic batch
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | Array of write operations to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions atomic execution. It doesn't disclose critical behavioral traits like: whether this requires specific permissions, what happens on partial failure (all-or-nothing atomicity implied but not explicit), rate limits, or what the response contains. 'Write operations' implies mutation but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the core functionality with zero waste. Front-loaded with the main action and key characteristic (atomic batch). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes a successful execution, error handling, atomicity guarantees, or return values. Given the complexity of batch operations and lack of structured safety information, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the operations parameter well-documented in the schema. The description adds minimal value beyond the schema by implying the operations are write types, but doesn't explain the structure or constraints beyond what's already in the detailed input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'execute' and resource 'multiple write operations' with the key characteristic 'in a single atomic batch'. It distinguishes from individual write tools like firestore-create-document, but doesn't explicitly differentiate from firestore-transaction which also provides atomicity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing atomic batch writes, but doesn't provide explicit guidance on when to use this versus alternatives like individual write tools or firestore-transaction. No when-not-to-use guidance or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new document in Firestore
| Name | Required | Description | Default |
|---|---|---|---|
| collectionId | Yes | The ID of the collection | |
| documentId | No | Optional document ID (auto-generated if not provided) | |
| data | Yes | The document data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write operation, it doesn't mention important behavioral aspects like authentication requirements, error conditions, rate limits, whether the operation is idempotent, or what happens on conflicts. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loaded with the essential action, and contains no wasted words. Every word serves a clear purpose in communicating the tool's basic function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, or behavioral constraints. Given the complexity of document creation operations and the rich sibling tool ecosystem, more context about this tool's specific behavior and limitations would be necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new document in Firestore'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'firestore-create-document-by-path' or 'firestore-batch-write', which would require more specific language about this tool's particular approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for document creation (firestore-create-document-by-path, firestore-batch-write, firestore-transaction), there's no indication of when this specific create method is preferred or what distinguishes it from other creation options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a document in a collection using full path (supports subcollections)
| Name | Required | Description | Default |
|---|---|---|---|
| collectionPath | Yes | Full path to the collection (e.g., 'users/userId1/orders') | |
| data | Yes | Document data to create | |
| documentId | No | Optional document ID. If not provided, one will be generated |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a document but doesn't mention critical aspects like authentication requirements, error handling (e.g., what happens if the path is invalid), rate limits, or whether the operation is idempotent. This leaves significant gaps for a mutation tool with potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Create a document in a collection') and adds the key differentiating feature ('using full path (supports subcollections)'). There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a document creation tool with no annotations and no output schema, the description is inadequate. It lacks details on behavioral traits (e.g., permissions, errors), output format, or how it differs from sibling tools. For a mutation operation in a database context, this leaves too many unknowns for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond implying that 'collectionPath' supports subcollections (which is somewhat redundant with the schema's example). No additional semantics or usage nuances are provided beyond what the schema covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a document') and resource ('in a collection'), with the specific capability of using 'full path (supports subcollections)'. However, it doesn't explicitly differentiate from its sibling 'firestore-create-document' (which likely uses a different path format), leaving some ambiguity about when to choose one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'firestore-create-document' (which appears to be a sibling tool). It mentions the 'full path' capability but doesn't clarify if this is the preferred method or when subcollection support is needed, offering no explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a document from Firestore
| Name | Required | Description | Default |
|---|---|---|---|
| collectionId | Yes | The ID of the collection | |
| documentId | Yes | The ID of the document to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive operation, the description doesn't mention important behavioral aspects like whether deletion is permanent, what permissions are required, whether it cascades to subcollections, or what happens if the document doesn't exist. This is inadequate for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a straightforward operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion, whether the operation is reversible, what errors might occur, or how this differs from similar deletion tools. Given the complexity of document deletion in Firestore and the rich sibling tool ecosystem, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any parameter information beyond what the schema provides, but since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a document from Firestore'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'firestore-delete-document-by-path', which performs the same core function with a different parameter approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for document deletion and other Firestore operations, there's no indication of prerequisites, when this specific deletion method is preferred, or what distinguishes it from 'firestore-delete-document-by-path'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a document using full path (supports subcollections)
| Name | Required | Description | Default |
|---|---|---|---|
| documentPath | Yes | Full path to the document (e.g., 'users/userId1/orders/orderId1') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the deletion action without behavioral details. It doesn't disclose critical traits like permissions required, whether deletion is permanent or reversible, error handling, or rate limits, which are essential for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Delete a document') and adds necessary qualifiers ('using full path', 'supports subcollections') without any wasted words. Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is inadequate. It lacks information on what happens upon deletion (e.g., return values, confirmation), error cases, or safety considerations, leaving significant gaps for an agent to operate safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter 'documentPath' is fully documented in the schema. The description adds minimal value by mentioning 'full path' and 'supports subcollections', which aligns with but doesn't significantly expand beyond the schema's example. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('document'), and specifies the method ('using full path') which distinguishes it from the sibling 'firestore-delete-document' that likely uses different identification. However, it doesn't explicitly mention Firestore or contrast with all siblings, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'full path' and 'supports subcollections', suggesting it's for precise deletion in nested structures. But it lacks explicit guidance on when to choose this over 'firestore-delete-document' or other deletion-related tools, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific fields from a document
| Name | Required | Description | Default |
|---|---|---|---|
| documentPath | Yes | Full path to the document | |
| fields | Yes | Field names to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Delete') but lacks critical details: whether this is a destructive operation (implied but not explicit), what happens if fields don't exist (error or no-op), authentication requirements, rate limits, or return values. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it easy to parse. Every word earns its place, achieving optimal conciseness for such a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive mutation), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral traits, error conditions, or return values, which are crucial for safe and effective use. The high schema coverage helps with parameters, but overall context is insufficient for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (documentPath and fields) clearly documented in the schema. The description adds no additional meaning beyond implying field deletion, which aligns with the schema. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description doesn't compensate with extra context like path format examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target ('specific fields from a document'), which distinguishes it from sibling tools like firestore-delete-document (which deletes entire documents). However, it doesn't specify the resource type (Firestore) or differentiate from other field-modification tools like firestore-increment-field, making it slightly less specific than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose field deletion over document deletion (firestore-delete-document) or field updates (firestore-update-document), nor does it specify prerequisites like document existence or permissions. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute multiple field value operations in a batch
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | Array of field value operations to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states execution behavior without disclosing critical traits: it doesn't mention atomicity, transaction-like properties, error handling, performance implications, or that it's a write operation (implied by 'execute'). For a batch tool with complex operations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Execute multiple field value operations'), though it could be more structured by explicitly listing operation types. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex batch tool with no annotations and no output schema, the description is incomplete. It doesn't explain the atomic nature of field value operations, batch limits, error rollback behavior, or return values. Given the rich input schema and sibling tools, more context is needed to guide proper usage and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'operations' parameter well-documented in the schema (including operation types and required fields). The description adds no additional parameter semantics beyond 'multiple field value operations,' which is already implied by the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute multiple field value operations in a batch' states a general purpose (batch execution of field value operations) but is vague about what constitutes 'field value operations' and doesn't differentiate from siblings like firestore-batch-write or firestore-transaction. It mentions 'field value' which hints at atomic operations, but lacks specificity about the types of operations supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like firestore-batch-write, firestore-transaction, or individual atomic operation tools (e.g., firestore-increment-field). The description implies batch processing but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get documents from a Firestore collection
| Name | Required | Description | Default |
|---|---|---|---|
| collectionId | Yes | The ID of the collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get documents' implies a read operation, it doesn't specify important behavioral aspects like whether this retrieves all documents, supports pagination, returns metadata, requires authentication, or has rate limits. For a database operation with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the essential information with zero wasted words. Every word earns its place, making it easy to parse while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Firestore operations and the lack of both annotations and output schema, the description is insufficient. It doesn't explain what 'Get documents' actually returns (documents, metadata, pagination tokens), how it behaves with large collections, or how it differs from similar sibling tools. For a database query tool with no structured safety or output information, this leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter information beyond what's already in the schema, which has 100% coverage. The schema fully documents the single 'collectionId' parameter, so the baseline score of 3 is appropriate since the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get documents') and resource ('from a Firestore collection'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'firestore-get-collection-by-path' or 'firestore-query-collection', which appear to offer similar functionality with different approaches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that appear related (firestore-get-collection-by-path, firestore-query-collection, firestore-batch-read), there's no indication of when this specific tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get documents from a collection using full path (supports subcollections)
| Name | Required | Description | Default |
|---|---|---|---|
| collectionPath | Yes | Full path to the collection (e.g., 'users/userId1/orders') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'Get documents' but doesn't disclose behavioral traits like whether this is a read-only operation (implied but not explicit), what permissions are needed, how many documents are returned (all vs paginated), error handling for invalid paths, or response format. For a retrieval tool with zero annotation coverage, this lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get documents from a collection') and adds qualifying details ('using full path', 'supports subcollections') without waste. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving documents from potentially nested collections), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the return value looks like (e.g., array of documents, metadata), handling of large collections, authentication requirements, or error scenarios. For a read operation in a database context, this leaves significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'collectionPath' fully documented in the schema as 'Full path to the collection (e.g., 'users/userId1/orders')'. The description adds minimal value beyond this, mentioning 'full path' and 'supports subcollections' which aligns with but doesn't expand on the schema's example. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'documents from a collection', specifying it uses a 'full path' and 'supports subcollections'. This distinguishes it from simpler collection retrieval tools like 'firestore-get-collection' that might not handle subcollections. However, it doesn't explicitly differentiate from 'firestore-query-collection-by-path' which might offer more filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'firestore-get-collection' (which might use simpler paths) or 'firestore-query-collection-by-path' (which might offer query capabilities). It mentions 'supports subcollections' but doesn't clarify if this is unique or when subcollection paths are required versus other approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a document from Firestore
| Name | Required | Description | Default |
|---|---|---|---|
| collectionId | Yes | The ID of the collection | |
| documentId | Yes | The ID of the document |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't mention authentication requirements, rate limits, error conditions, or what happens if the document doesn't exist. For a database operation with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple retrieval operation and gets straight to the point. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a database operation with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the document returns in, what happens on errors, or any behavioral constraints. For a tool that interacts with a complex system like Firestore, more context about the operation's behavior and results would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a document from Firestore'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'firestore-get-document-by-path', which appears to serve a similar purpose with different parameterization. The description is specific but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for document retrieval (firestore-get-document-by-path, firestore-batch-read, firestore-query-collection), there's no indication of when this specific tool is appropriate versus those alternatives. No context, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a document using full path (supports subcollections)
| Name | Required | Description | Default |
|---|---|---|---|
| documentPath | Yes | Full path to the document (e.g., 'users/userId1/orders/orderId1') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the read operation ('Get') but doesn't mention whether this requires authentication, has rate limits, returns null for non-existent documents, or includes metadata. The phrase 'supports subcollections' hints at path flexibility but doesn't explain behavioral implications like error handling or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get a document using full path') and adds a clarifying note ('supports subcollections'). There is no wasted verbiage, repetition, or unnecessary elaboration, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter read operation), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and method but lacks details on authentication requirements, error conditions, return format, or performance characteristics. For a database read tool in a sibling-rich environment, more contextual guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'documentPath' fully documented in the schema. The description adds minimal value beyond the schema by reinforcing the 'full path' concept and mentioning subcollections, but doesn't provide additional syntax examples, constraints, or edge cases. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a document'), and specifies the method ('using full path') and capability ('supports subcollections'). It distinguishes from siblings like 'firestore-get-document' by emphasizing the path-based approach, but doesn't explicitly contrast with other read operations like 'firestore-batch-read' or 'firestore-query-collection-by-path'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'full path' and 'supports subcollections', suggesting this tool is for direct document retrieval when the exact path is known. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'firestore-get-document' (which might use different identifiers) or 'firestore-query-collection-by-path' (for filtered searches). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Atomically increment a numeric field value
| Name | Required | Description | Default |
|---|---|---|---|
| documentPath | Yes | Full path to the document | |
| field | Yes | Field name to increment | |
| incrementBy | Yes | Amount to increment by (can be negative) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions atomicity. It lacks details on permissions required, error conditions (e.g., non-numeric fields), rate limits, or what happens if the field doesn't exist. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and includes the key behavioral trait (atomic). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error handling, or important constraints like document existence requirements. The atomic hint is helpful but insufficient given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional semantic context beyond implying the field must be numeric. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('atomically increment') and target ('a numeric field value'), distinguishing it from siblings like firestore-update-document or firestore-delete-field. It uses precise technical language that conveys both the operation and its atomic nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like firestore-update-document for general field modifications or firestore-transaction for complex atomic operations. The description implies usage for numeric increments but doesn't specify scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Firestore collections
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('List') but doesn't disclose behavioral traits such as permissions needed, rate limits, pagination, or output format (e.g., list of strings). For a read operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('List Firestore collections') with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema) and lack of annotations, the description is incomplete. It doesn't explain what 'List' entails (e.g., returns collection IDs), behavioral aspects, or how it fits with siblings. For a tool in a complex server with many siblings, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param details, which is appropriate. Baseline is 4 for zero parameters, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Firestore collections' clearly states the verb ('List') and resource ('Firestore collections'), making the purpose immediately understandable. It distinguishes from siblings like 'firestore-get-collection' (retrieves documents) and 'firestore-list-subcollections' (lists nested collections). However, it doesn't specify scope (e.g., root-level only), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., after accessing a database), or comparisons to siblings like 'firestore-get-collection' (for documents) or 'firestore-list-subcollections' (for nested collections). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List subcollections of a document
| Name | Required | Description | Default |
|---|---|---|---|
| documentPath | Yes | Full path to the document (e.g., 'users/userId1') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List') but does not describe traits like read-only nature, potential errors (e.g., invalid document paths), return format, pagination, or performance implications. This leaves significant gaps for an agent to understand how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It is front-loaded with the core action and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not address behavioral traits, error handling, or return values, which are critical for a tool interacting with a database. While concise, it fails to provide sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'documentPath' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as examples of valid paths or constraints. The baseline score of 3 reflects adequate but minimal value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('subcollections of a document'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'firestore-list-collections' (which likely lists top-level collections), leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'firestore-list-collections' for top-level collections or 'firestore-get-collection' for retrieving collection contents. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query documents in a Firestore collection
| Name | Required | Description | Default |
|---|---|---|---|
| collectionId | Yes | The ID of the collection | |
| filters | Yes | Array of filter conditions | |
| limit | No | Maximum number of results to return | |
| orderBy | No | Order specification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Query' which implies a read operation, but doesn't disclose critical behavioral traits like whether it's safe (non-destructive), what permissions are needed, how results are returned (e.g., pagination, format), or any rate limits. For a query tool with complex parameters, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's appropriately sized and front-loaded, directly stating the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters with nested objects, no output schema, and no annotations), the description is insufficient. It doesn't explain what the query returns, how results are structured, error conditions, or performance considerations. For a database query tool with rich input schema but no output documentation, this creates significant ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaningful semantic context beyond what's in the schema (e.g., it doesn't explain how filters combine, what 'value' can be, or practical examples). With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Query') and resource ('documents in a Firestore collection'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'firestore-get-collection' or 'firestore-query-collection-by-path', which would require more detailed comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple query-related siblings (e.g., 'firestore-query-collection-by-path', 'firestore-get-collection'), there's no indication of when this specific query method is preferred or what distinguishes it from other retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query documents in a collection using full path (supports subcollections)
| Name | Required | Description | Default |
|---|---|---|---|
| collectionPath | Yes | Full path to the collection (e.g., 'users/userId1/orders') | |
| filters | Yes | Array of filter conditions | |
| limit | No | Maximum number of results to return | |
| orderBy | No | Order specification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool queries documents but doesn't describe critical behaviors: whether it's read-only or has side effects, authentication requirements, rate limits, error handling, or return format. The mention of 'supports subcollections' adds some context, but overall behavioral traits are inadequately covered for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Query documents in a collection') and adds a clarifying note ('using full path (supports subcollections)'). There is zero waste, and every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters with nested objects, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects like safety, performance, or output format, which are crucial for a query tool. While the schema covers parameters well, the description doesn't compensate for missing annotations or output schema, leaving gaps in overall understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (collectionPath, filters, limit, orderBy). The description adds minimal value beyond the schema, mentioning 'full path' and 'supports subcollections' which aligns with collectionPath but doesn't provide additional syntax or usage details. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Query') and resource ('documents in a collection'), specifying the action and target. It distinguishes from siblings like 'firestore-get-collection-by-path' by emphasizing querying with filters rather than simple retrieval. However, it doesn't explicitly contrast with 'firestore-query-collection' (without '-by-path'), leaving some sibling differentiation incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, mentioning 'supports subcollections' which hints at when to use this over simpler collection queries. However, it lacks explicit when-to-use scenarios, prerequisites, or alternatives compared to siblings like 'firestore-query-collection' or 'firestore-get-collection-by-path'. No exclusions or detailed context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a field to the server timestamp
| Name | Required | Description | Default |
|---|---|---|---|
| documentPath | Yes | Full path to the document | |
| fields | Yes | Field names to set to server timestamp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions setting a field to a server timestamp, implying a write operation, but doesn't clarify if this creates/updates documents, requires specific permissions, or has side effects like overwriting existing data. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for the tool's functionality, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return value, error conditions, or behavioral nuances like whether the timestamp is set immediately or on server commit. Given the complexity and lack of structured data, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (documentPath and fields). The description adds no additional meaning beyond what the schema provides, such as examples of field names or timestamp behavior. The baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a field') and the resource ('to the server timestamp'), making the purpose understandable. It distinguishes itself from siblings like firestore-update-document by focusing specifically on timestamp setting, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like firestore-update-document or firestore-field-value-batch. The description lacks context about prerequisites, such as document existence or permissions needed for timestamp operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a transaction with read and write operations
| Name | Required | Description | Default |
|---|---|---|---|
| reads | Yes | Document paths to read in the transaction | |
| operations | Yes | Write operations to execute based on read data | |
| conditionScript | No | JavaScript condition to evaluate before committing (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'transaction with read and write operations,' which implies atomicity and potential data mutation, but fails to disclose critical traits: whether it requires specific permissions, how errors are handled, if there are rate limits, transaction isolation levels, or what happens on failure (e.g., rollback). For a complex mutation tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Execute a transaction with read and write operations.' It is appropriately sized and front-loaded, directly stating the core functionality without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a transaction tool (involving multiple parameters, mutation operations, and no output schema), the description is incomplete. It lacks details on behavioral aspects like error handling, atomicity guarantees, and response format. With no annotations and no output schema, the description should provide more context to help the agent understand how to use it effectively and what to expect, but it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'reads,' 'operations,' and 'conditionScript.' The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain the relationship between reads and operations, the format of document paths, or the purpose of the conditionScript. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Execute') and resource ('a transaction with read and write operations'), making the purpose understandable. However, it doesn't explicitly distinguish this from sibling tools like firestore-batch-write or firestore-field-value-batch, which might also handle multiple operations. The description is specific about transaction semantics but could better differentiate from batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for individual operations (e.g., firestore-create-document, firestore-update-document) and batch operations (e.g., firestore-batch-write), the agent receives no explicit direction on when this transaction tool is preferred—such as for atomicity, consistency, or conditional execution based on read data. Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Firestore document
| Name | Required | Description | Default |
|---|---|---|---|
| collectionId | Yes | The ID of the collection | |
| documentId | Yes | The ID of the document to update | |
| data | Yes | The document data to update |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose critical behaviors: whether this is a partial or full update, if it requires specific permissions, error conditions (e.g., document doesn't exist), side effects, or how it handles concurrent modifications. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('update an existing Firestore document'), making it immediately understandable. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'update' entails (merge vs replace), return values, error handling, or how it differs from similar tools. Given the complexity of Firestore operations and rich sibling toolset, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning about parameters beyond what's in the schema (e.g., format of collectionId/documentId, structure of data object). Baseline score of 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'existing Firestore document', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'firestore-update-document-by-path' or 'firestore-batch-write', which could also update documents in different ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., document must exist), compare to siblings like 'update-document-by-path' (path-based vs ID-based), or specify use cases like partial updates versus full replacements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a document using full path (supports subcollections)
| Name | Required | Description | Default |
|---|---|---|---|
| documentPath | Yes | Full path to the document (e.g., 'users/userId1/orders/orderId1') | |
| data | Yes | Document data to update |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It states this is an update operation (implying mutation) but doesn't cover critical aspects like: whether this is a partial or complete update, what happens if the document doesn't exist, authentication requirements, error conditions, or rate limits. The mention of 'supports subcollections' adds some context but is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 9 words, front-loading the core purpose ('Update a document') and efficiently adding the key differentiator ('using full path') with a helpful parenthetical note ('supports subcollections'). Every word serves a purpose with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'update' means in this context (partial update? merge behavior?), doesn't mention error cases or prerequisites, and provides minimal guidance on usage versus siblings. The 100% schema coverage helps with parameters, but behavioral context is severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear documentation for both parameters. The description adds marginal value by emphasizing the 'full path' aspect for documentPath and implying the data parameter is for updates, but doesn't explain update semantics (merge vs replace) or provide examples beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update a document') and resource ('document'), and specifies the method ('using full path') with a clarifying note about subcollections. It distinguishes from the sibling 'firestore-update-document' by explicitly mentioning the path-based approach, though it doesn't fully explain how this differs from the non-path version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'firestore-update-document' (which likely uses a different referencing method) or other mutation tools like 'firestore-create-document-by-path'. It mentions 'supports subcollections' but doesn't clarify if this is unique to this tool or a general feature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is some overlap between 'firestore-get-collection' and 'firestore-query-collection' (both retrieve documents from a collection), and between 'firestore-create-document' and 'firestore-create-document-by-path' (both create documents, differing only in path specification). Descriptions clarify these differences, but an agent might occasionally misselect between the overlapping pairs.
All tool names follow a consistent 'firestore-verb-noun' pattern with hyphens, using clear verbs like 'create', 'get', 'update', 'delete', 'list', 'query', and 'increment'. The naming is highly predictable and readable throughout the set.
With 23 tools, the count is borderline high for a database server, potentially feeling heavy. However, it covers both basic CRUD operations and advanced Firestore-specific features like array updates, transactions, and batch operations, which justifies the number but may overwhelm agents.
The tool set provides comprehensive coverage for Firestore operations, including full CRUD lifecycle, batch and transaction support, field-specific updates (e.g., array operations, increments), and path-based variants for subcollections. No obvious gaps exist for typical agent workflows in this domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
One MCP URL for all your connectors — scoped writes, enforced constraints, and a full audit trail.
Build, deploy, and host full-stack web apps from any MCP client. DB, auth, storage, cron included.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/devlimelabs/firestore-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
