mcp
Server Details
Interact with your Google Cloud Firestore resources using natural language commands.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.3/5 across 15 of 15 tools scored.
Every tool has a clearly distinct purpose targeting specific Firestore resources (databases, documents, indexes, collections) with unambiguous action verbs. There is no overlap or confusion between tools like 'add_document' vs 'update_document' or 'list_databases' vs 'get_database'.
All tools follow a perfect verb_noun pattern with consistent snake_case throughout. The naming convention is completely predictable with verbs like create/get/list/update/delete paired consistently with their corresponding nouns.
15 tools is ideal for a comprehensive Firestore management server. The count provides complete coverage of database, document, and index operations without being overwhelming or redundant. Each tool clearly earns its place in the set.
The toolset provides complete CRUD/lifecycle coverage for Firestore databases, documents, and indexes. It includes all essential operations from creation to deletion, with appropriate listing capabilities and no obvious gaps for the stated Firestore domain.
Available Tools
15 toolsadd_documentCInspect
Create a document from a Firestore database.
| Name | Required | Description | Default |
|---|---|---|---|
| mask | No | The fields to return. If not set, returns all fields. If the document has a field that is not present in this mask, that field will not be returned in the response. | |
| parent | Yes | Required. The parent resource. For example: `projects/{project_id}/databases/{database_id}/documents` or `projects/{project_id}/databases/{database_id}/documents/chatrooms/{chatroom_id}` | |
| document | Yes | Required. The document to create. `name` must not be set. | |
| documentId | No | The client-assigned document ID to use for this document. Optional. If not specified, an ID will be assigned by the service. | |
| collectionId | Yes | Required. The collection ID, relative to `parent`, to list. For example: `chatrooms`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The resource name of the document, for example `projects/{project_id}/databases/{database_id}/documents/{document_path}`. |
| fields | No | The document's fields. The map keys represent field names. Field names matching the regular expression `__.*__` are reserved. Reserved field names are forbidden except in certain documented contexts. The field names, represented as UTF-8, must not exceed 1,500 bytes and cannot be empty. Field paths may be used in other contexts to refer to structured fields defined here. For `map_value`, the field path is represented by a dot-delimited (`.`) string of segments. Each segment is either a simple field name (defined below) or a quoted field name. For example, the structured field `"foo" : { map_value: { "x&y" : { string_value: "hello" }}}` would be represented by the field path `` foo.`x&y` ``. A simple field name contains only characters `a` to `z`, `A` to `Z`, `0` to `9`, or `_`, and must not start with `0` to `9`. For example, `foo_bar_17`. A quoted field name starts and ends with `` ` `` and may contain any character. Some characters, including `` ` ``, must be escaped using a `\`. For example, `` `x&y` `` represents `x&y` and `` `bak\`tik` `` represents `` bak`tik ``. |
| createTime | No | Output only. The time at which the document was created. This value increases monotonically when a document is deleted then recreated. It can also be compared to values from other documents and the `read_time` of a query. |
| updateTime | No | Output only. The time at which the document was last changed. This value is initially set to the `create_time` then increases monotonically with each change to the document. It can also be compared to values from other documents and the `read_time` of a query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only, not open-world, and not destructive, which the description doesn't contradict. However, the description adds minimal behavioral context beyond annotations—it doesn't explain that this is a write operation requiring specific permissions, potential constraints (e.g., document size limits), or how it interacts with Firestore's consistency model. With annotations covering basic safety, the description adds little extra value.
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 but could be more structured by including key usage notes. While concise, it lacks depth that would justify a perfect score.
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 presence of annotations and an output schema, the description is minimally adequate. It doesn't explain the tool's role in the context of sibling tools (e.g., vs. 'update_document'), nor does it address common pitfalls like document ID conflicts. With structured data covering parameters and output, the description meets a basic threshold but leaves gaps in practical guidance.
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 detailed parameter documentation in the schema. The description provides no additional parameter information beyond the schema's definitions (e.g., it doesn't clarify the relationship between 'parent', 'collectionId', and 'document'). 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 'Create a document from a Firestore database' states the action (create) and resource (document) but is vague about what 'from a Firestore database' means. It doesn't specify whether this creates a new document in a collection or imports/transforms existing data. Compared to siblings like 'create_database' or 'update_document', the distinction is unclear.
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 'update_document' or 'delete_document'. The description lacks context about prerequisites (e.g., needing a parent collection) or typical use cases (e.g., adding new data entries). It doesn't mention any exclusions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_databaseBInspect
Create a Firestore database.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. A parent name of the form `projects/{project_id}` | |
| database | Yes | Required. The Database to create. | |
| databaseId | Yes | Required. The ID to use for the database, which will become the final component of the database's resource name. This value should be 4-63 characters. Valid characters are /a-z-/ with first character a letter and the last a letter or a number. Must not be UUID-like /[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}/. "(default)" database ID is also valid if the database is Standard edition. |
Output Schema
| Name | Required | Description |
|---|---|---|
| done | No | If the value is `false`, it means the operation is still in progress. If `true`, the operation is completed, and either `error` or `response` is available. |
| name | No | The server-assigned name, which is only unique within the same service that originally returns it. If you use the default HTTP mapping, the `name` should be a resource name ending with `operations/{unique_id}`. |
| error | No | The error result of the operation in case of failure or cancellation. |
| metadata | No | Service-specific metadata associated with the operation. It typically contains progress information and common metadata such as create time. Some services might not provide such metadata. Any method that returns a long-running operation should document the metadata type, if any. |
| response | No | The normal, successful response of the operation. If the original method returns no data on success, such as `Delete`, the response is `google.protobuf.Empty`. If the original method is standard `Get`/`Create`/`Update`, the response should be the resource. For other methods, the response should have the type `XxxResponse`, where `Xxx` is the original method name. For example, if the original method name is `TakeSnapshot()`, the inferred response type is `TakeSnapshotResponse`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive, non-openWorld operation (i.e., a standard creation). The description adds no behavioral context beyond this—it doesn't mention permissions required, rate limits, costs, or that creation might be irreversible. With annotations covering basic safety, a 3 is appropriate as the description adds minimal value but doesn't contradict annotations.
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 resource, making it easy for an agent to parse quickly. No structural issues or redundancy are present.
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 (creation tool with 3 required parameters, rich schema, and output schema), the description is minimal. It doesn't address context like project prerequisites, database configuration options, or implications of creation. With annotations covering basic behavior and an output schema handling return values, it's adequate but leaves gaps in guidance and operational context.
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 detailed descriptions for all parameters (parent, database, databaseId). The description adds no parameter semantics beyond the schema, not even hinting at required fields or their purposes. Baseline 3 is correct when the schema fully documents parameters, though the description could have highlighted key inputs like database type or location.
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 'Create a Firestore database' clearly states the action (create) and resource (Firestore database). It distinguishes from siblings like 'update_database' or 'delete_database' by specifying creation. However, it doesn't explicitly differentiate from 'add_document' which creates a document rather than a database, though the resource type makes this distinction implicit.
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., needing a project), when not to use it (e.g., if a database already exists), or direct alternatives like 'update_database' for modifications. The agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_indexBInspect
Create a composite index.
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Required. The composite index to create. | |
| parent | Yes | Required. A parent name of the form `projects/{project_id}/databases/{database_id}/collectionGroups/{collection_id}` |
Output Schema
| Name | Required | Description |
|---|---|---|
| done | No | If the value is `false`, it means the operation is still in progress. If `true`, the operation is completed, and either `error` or `response` is available. |
| name | No | The server-assigned name, which is only unique within the same service that originally returns it. If you use the default HTTP mapping, the `name` should be a resource name ending with `operations/{unique_id}`. |
| error | No | The error result of the operation in case of failure or cancellation. |
| metadata | No | Service-specific metadata associated with the operation. It typically contains progress information and common metadata such as create time. Some services might not provide such metadata. Any method that returns a long-running operation should document the metadata type, if any. |
| response | No | The normal, successful response of the operation. If the original method returns no data on success, such as `Delete`, the response is `google.protobuf.Empty`. If the original method is standard `Get`/`Create`/`Update`, the response should be the resource. For other methods, the response should have the type `XxxResponse`, where `Xxx` is the original method name. For example, if the original method name is `TakeSnapshot()`, the inferred response type is `TakeSnapshotResponse`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive, non-openWorld operation (implying a write that's safe and scoped). The description doesn't add behavioral context beyond 'Create'—no mention of permissions, rate limits, asynchronous creation, or that indexes affect query performance. It doesn't contradict annotations but adds minimal value given their 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 no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. 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?
Given the complexity (Firestore index creation with nested schema), annotations cover safety, and an output schema exists, the description is minimally adequate. However, it lacks context on use cases, prerequisites, or impact, leaving gaps for an agent to understand when and why to invoke this 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%, so parameters 'parent' and 'index' are well-documented in the schema. The description adds no semantic details beyond 'composite index', which is implied by the schema. Baseline score of 3 is appropriate as the schema carries the full burden.
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 'Create a composite index' states the action and resource but lacks specificity. It doesn't clarify what a 'composite index' is in this context (Firestore database index) or differentiate it from sibling tools like 'delete_index' or 'get_index' beyond the basic verb. The purpose is understandable but vague about the domain and 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a parent collection), exclusions, or related tools like 'list_indexes' for checking existing indexes. The agent must infer usage from the schema and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_databaseADestructiveInspect
Delete a Firestore database.
| Name | Required | Description | Default |
|---|---|---|---|
| etag | No | The current etag of the Database. If an etag is provided and does not match the current etag of the database, deletion will be blocked and a FAILED_PRECONDITION error will be returned. | |
| name | Yes | Required. A name of the form `projects/{project_id}/databases/{database_id}` |
Output Schema
| Name | Required | Description |
|---|---|---|
| done | No | If the value is `false`, it means the operation is still in progress. If `true`, the operation is completed, and either `error` or `response` is available. |
| name | No | The server-assigned name, which is only unique within the same service that originally returns it. If you use the default HTTP mapping, the `name` should be a resource name ending with `operations/{unique_id}`. |
| error | No | The error result of the operation in case of failure or cancellation. |
| metadata | No | Service-specific metadata associated with the operation. It typically contains progress information and common metadata such as create time. Some services might not provide such metadata. Any method that returns a long-running operation should document the metadata type, if any. |
| response | No | The normal, successful response of the operation. If the original method returns no data on success, such as `Delete`, the response is `google.protobuf.Empty`. If the original method is standard `Get`/`Create`/`Update`, the response should be the resource. For other methods, the response should have the type `XxxResponse`, where `Xxx` is the original method name. For example, if the original method name is `TakeSnapshot()`, the inferred response type is `TakeSnapshotResponse`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, indicating a destructive, non-read-only operation. The description adds context by specifying it's for Firestore databases, but doesn't disclose additional behavioral traits like irreversible deletion, permissions required, or error handling. No contradiction with annotations, and it provides some useful context beyond them.
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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse for an AI agent.
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 high complexity (destructive database deletion), annotations cover safety (destructiveHint), and an output schema exists, the description is minimal but functional. However, it lacks critical context like irreversible consequences, prerequisites, or error scenarios, which are important for such a high-stakes operation.
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 detailed descriptions for both parameters (name and etag). The description adds no parameter-specific information beyond what the schema provides, such as examples or usage notes. Baseline 3 is appropriate since the schema fully documents parameters.
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 'Delete a Firestore database' clearly states the specific action (delete) and target resource (Firestore database). It distinguishes from siblings like delete_document or delete_index by specifying the database level, and from create_database or update_database by the destructive action.
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., database must exist), exclusions (e.g., cannot delete if in use), or sibling tools like delete_document for different operations. Usage is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_documentBDestructiveInspect
Delete a document from a Firestore database.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The resource name of the Document to delete. In the format: `projects/{project_id}/databases/{database_id}/documents/{document_path}`. | |
| currentDocument | No | An optional precondition on the document. The request will fail if this is set and not met by the target document. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, and openWorldHint=false, covering key safety traits. The description adds minimal behavioral context beyond this, stating it deletes a document but not elaborating on effects (e.g., permanent removal, impact on related data) or constraints like permissions. It doesn't contradict annotations, but provides little extra value.
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, direct sentence with zero wasted words. It's front-loaded with the core action ('Delete a document') and efficiently specifies the context ('from a Firestore database'). No unnecessary elaboration or redundancy is present.
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 destructive nature (annotations cover this), 100% schema coverage, and presence of an output schema, the description is minimally adequate. However, for a deletion tool, it lacks details on consequences (e.g., irreversibility, effects on subcollections) and error handling, which would enhance completeness despite structured fields.
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 detailed parameter documentation in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'name' format or 'currentDocument' usage). Baseline score of 3 applies since the schema carries the full burden of parameter semantics.
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 ('Delete') and resource ('document from a Firestore database'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete_database' or 'delete_index', which would require mentioning it specifically targets documents rather than databases or indexes.
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. It doesn't mention prerequisites (e.g., document must exist), compare to related tools like 'update_document' for modifications, or specify error conditions. The description is a standalone statement without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_indexADestructiveInspect
Delete a Firestore index.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. A name of the form `projects/{project_id}/databases/{database_id}/collectionGroups/{collection_id}/indexes/{index_id}` |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true (irreversible deletion) and readOnlyHint=false (mutation), but the description adds value by specifying the resource type ('Firestore index'), which clarifies scope beyond generic deletion. It doesn't mention authentication needs, rate limits, or side effects, but with annotations covering key safety aspects, this is adequate.
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 resource, making it immediately understandable 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 destructive nature, annotations cover safety (destructiveHint), and an output schema exists, the description is minimally complete. However, for a deletion tool, it lacks context on consequences (e.g., performance impact, recovery options) or usage prerequisites, leaving gaps despite structured data.
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 parameter 'name' fully documented in the schema. The description adds no additional meaning about parameters beyond implying deletion targets an index, which is already clear from the tool name and schema context.
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 Firestore index'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like delete_database or delete_document, which target different resources in the same system.
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., index must exist), exclusions (e.g., cannot delete while in use), or relationships with siblings like get_index or list_indexes for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_databaseBRead-onlyInspect
Get a Firestore database.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. A name of the form `projects/{project_id}/databases/{database_id}` |
Output Schema
| Name | Required | Description |
|---|---|---|
| uid | No | Output only. The system-generated UUID4 for this Database. |
| etag | No | This checksum is computed by the server based on the value of other fields, and may be sent on update and delete requests to ensure the client has an up-to-date value before proceeding. |
| name | No | The resource name of the Database. Format: `projects/{project}/databases/{database}` |
| tags | No | Optional. Input only. Immutable. Tag keys/values directly bound to this resource. For example: "123/environment": "production", "123/costCenter": "marketing" |
| type | No | Required. The type of the database. See https://cloud.google.com/datastore/docs/firestore-or-datastore for information about how to choose. |
| freeTier | No | Output only. Background: Free tier is the ability of a Firestore database to use a small amount of resources every day without being charged. Once usage exceeds the free tier limit further usage is charged. Whether this database can make use of the free tier. Only one database per project can be eligible for the free tier. The first (or next) database that is created in a project without a free tier database will be marked as eligible for the free tier. Databases that are created while there is a free tier database will not be eligible for the free tier. |
| keyPrefix | No | Output only. The key_prefix for this database. This key_prefix is used, in combination with the project ID ("~") to construct the application ID that is returned from the Cloud Datastore APIs in Google App Engine first generation runtimes. This value may be empty in which case the appid to use for URL-encoded keys is the project_id (eg: foo instead of v~foo). |
| cmekConfig | No | Optional. Presence indicates CMEK is enabled for this database. |
| createTime | No | Output only. The timestamp at which this database was created. Databases created before 2016 do not populate create_time. |
| deleteTime | No | Output only. The timestamp at which this database was deleted. Only set if the database has been deleted. |
| locationId | No | Required. The location of the database. Available locations are listed at https://cloud.google.com/firestore/docs/locations. |
| previousId | No | Output only. The database resource's prior database ID. This field is only populated for deleted databases. |
| sourceInfo | No | Output only. Information about the provenance of this database. |
| updateTime | No | Output only. The timestamp at which this database was most recently updated. Note this only includes updates to the database resource and not data contained by the database. |
| concurrencyMode | No | The default concurrency control mode to use for this database. If unspecified in a CreateDatabase request, this will default based on the database edition: Optimistic for Enterprise and Pessimistic for all other databases. While transactions can explicitly specify their own concurrency mode, this setting defines the default behavior when left unspecified. Important: This database-level setting is not respected for Firestore with MongoDB compatibility. All transactions through the MongoDB compatibility layer will use optimistic concurrency control, regardless of this setting. |
| databaseEdition | No | Immutable. The edition of the database. |
| earliestVersionTime | No | Output only. The earliest timestamp at which older versions of the data can be read from the database. See [version_retention_period] above; this field is populated with `now - version_retention_period`. This value is continuously updated, and becomes stale the moment it is queried. If you are using this value to recover data, make sure to account for the time from the moment when the value is queried to the moment when you initiate the recovery. |
| realtimeUpdatesMode | No | Immutable. The default Realtime Updates mode to use for this database. |
| deleteProtectionState | No | State of delete protection for the database. |
| versionRetentionPeriod | No | Output only. The period during which past versions of data are retained in the database. Any read or query can specify a `read_time` within this window, and will read the state of the database at that time. If the PITR feature is enabled, the retention period is 7 days. Otherwise, the retention period is 1 hour. |
| firestoreDataAccessMode | No | Optional. The Firestore API data access mode to use for this database. If not set on write: - the default value is DATA_ACCESS_MODE_DISABLED for Enterprise Edition. - the default value is DATA_ACCESS_MODE_ENABLED for Standard Edition. |
| appEngineIntegrationMode | No | The App Engine integration mode to use for this database. |
| pointInTimeRecoveryEnablement | No | Whether to enable the PITR feature on this database. |
| mongodbCompatibleDataAccessMode | No | Optional. The MongoDB compatible API data access mode to use for this database. If not set on write, the default value is DATA_ACCESS_MODE_ENABLED for Enterprise Edition. The value is always DATA_ACCESS_MODE_DISABLED for Standard Edition. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's read-only, non-destructive, and closed-world, so the description doesn't need to repeat these. It adds value by specifying the resource type ('Firestore database'), but doesn't elaborate on behavioral aspects like error handling, permissions, or response format beyond what annotations cover.
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 no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration, earning a top score for brevity and structure.
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 (one parameter, read-only operation) and the presence of annotations and an output schema, the description is reasonably complete. It could be improved by mentioning when to use it versus siblings, but it adequately covers the basic context for a straightforward retrieval 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?
With 100% schema description coverage, the input schema fully documents the single required parameter 'name'. The description doesn't add any parameter-specific details beyond implying the tool operates on a database resource, so it meets the baseline for adequate but not enhanced parameter semantics.
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') and resource ('a Firestore database'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_document' or 'get_index' beyond the resource type, which keeps 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 provides no guidance on when to use this tool versus alternatives like 'list_databases' for browsing or 'get_document' for specific data retrieval. It lacks context about prerequisites or typical use cases, 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.
get_documentBRead-onlyInspect
Get a document from a Firestore database.
| Name | Required | Description | Default |
|---|---|---|---|
| mask | No | The fields to return. If not set, returns all fields. If the document has a field that is not present in this mask, that field will not be returned in the response. | |
| name | Yes | Required. The resource name of the Document to get. In the format: `projects/{project_id}/databases/{database_id}/documents/{document_path}`. | |
| readTime | No | Reads the version of the document at the given time. This must be a microsecond precision timestamp within the past one hour, or if Point-in-Time Recovery is enabled, can additionally be a whole minute timestamp within the past 7 days. | |
| transaction | No | Reads the document in a transaction. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The resource name of the document, for example `projects/{project_id}/databases/{database_id}/documents/{document_path}`. |
| fields | No | The document's fields. The map keys represent field names. Field names matching the regular expression `__.*__` are reserved. Reserved field names are forbidden except in certain documented contexts. The field names, represented as UTF-8, must not exceed 1,500 bytes and cannot be empty. Field paths may be used in other contexts to refer to structured fields defined here. For `map_value`, the field path is represented by a dot-delimited (`.`) string of segments. Each segment is either a simple field name (defined below) or a quoted field name. For example, the structured field `"foo" : { map_value: { "x&y" : { string_value: "hello" }}}` would be represented by the field path `` foo.`x&y` ``. A simple field name contains only characters `a` to `z`, `A` to `Z`, `0` to `9`, or `_`, and must not start with `0` to `9`. For example, `foo_bar_17`. A quoted field name starts and ends with `` ` `` and may contain any character. Some characters, including `` ` ``, must be escaped using a `\`. For example, `` `x&y` `` represents `x&y` and `` `bak\`tik` `` represents `` bak`tik ``. |
| createTime | No | Output only. The time at which the document was created. This value increases monotonically when a document is deleted then recreated. It can also be compared to values from other documents and the `read_time` of a query. |
| updateTime | No | Output only. The time at which the document was last changed. This value is initially set to the `create_time` then increases monotonically with each change to the document. It can also be compared to values from other documents and the `read_time` of a query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds minimal behavioral context beyond this - it doesn't mention authentication requirements, rate limits, error conditions, or what happens when a document doesn't exist. With annotations doing the heavy lifting, this earns a baseline score.
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 any wasted words. It's appropriately sized for a simple retrieval operation and gets straight to the point.
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 annotations cover safety aspects, the input schema has 100% description coverage, and an output schema exists, the description is reasonably complete for its context. However, it could better address when to use this versus sibling tools and provide more behavioral context about error handling or performance characteristics.
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, all four parameters are well-documented in the input schema itself. The description adds no additional parameter information beyond what's already in the structured schema fields, so it meets but doesn't exceed the baseline expectation.
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') and resource ('document from a Firestore database'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'list_documents' or explain that this retrieves a single document by name rather than listing multiple documents, which would be needed for 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 provides no guidance on when to use this tool versus alternatives like 'list_documents' or 'update_document'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_indexBRead-onlyInspect
Get a Firestore index.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. A name of the form `projects/{project_id}/databases/{database_id}/collectionGroups/{collection_id}/indexes/{index_id}` |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | Output only. A server defined name for this index. The form of this name for composite indexes will be: `projects/{project_id}/databases/{database_id}/collectionGroups/{collection_id}/indexes/{composite_index_id}` For single field indexes, this field will be empty. |
| state | No | Output only. The serving state of the index. |
| fields | No | The fields supported by this index. For composite indexes, this requires a minimum of 2 and a maximum of 100 fields. The last field entry is always for the field path `__name__`. If, on creation, `__name__` was not specified as the last field, it will be added automatically with the same direction as that of the last field defined. If the final field in a composite index is not directional, the `__name__` will be ordered ASCENDING (unless explicitly specified). For single field indexes, this will always be exactly one entry with a field path equal to the field path of the associated field. |
| unique | No | Optional. Whether it is an unique index. Unique index ensures all values for the indexed field(s) are unique across documents. |
| density | No | Immutable. The density configuration of the index. |
| apiScope | No | The API scope supported by this index. |
| multikey | No | Optional. Whether the index is multikey. By default, the index is not multikey. For non-multikey indexes, none of the paths in the index definition reach or traverse an array, except via an explicit array index. For multikey indexes, at most one of the paths in the index definition reach or traverse an array, except via an explicit array index. Violations will result in errors. Note this field only applies to index with MONGODB_COMPATIBLE_API ApiScope. |
| queryScope | No | Indexes with a collection query scope specified allow queries against a collection that is the child of a specific document, specified at query time, and that has the same collection ID. Indexes with a collection group query scope specified allow queries against all collections descended from a specific document, specified at query time, and that have the same collection ID as this index. |
| shardCount | No | Optional. The number of shards for the index. |
| searchIndexOptions | No | Optional. Options for search indexes that are at the index definition level. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-destructive, closed-world operation. The description adds no behavioral context beyond what annotations provide, such as rate limits, authentication needs, or error handling, but it doesn't contradict annotations either.
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 front-loaded with the core purpose and appropriately sized for a simple tool, 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 tool's simplicity (1 parameter, 100% schema coverage, annotations present, and an output schema exists), the description is reasonably complete. It states what the tool does, though it lacks usage guidance, which is a minor gap in this context.
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 the single required parameter 'name'. The description adds no additional meaning or context about the parameter beyond what's in the schema, 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 clearly states the verb 'Get' and the resource 'a Firestore index', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_database' or 'get_document' beyond specifying the resource type, which is why it doesn't reach the highest 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when to choose this over similar tools like 'list_indexes', or any context-specific usage scenarios, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_collectionsBRead-onlyInspect
List all the collection IDs underneath a document.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The parent document. In the format: `projects/{project_id}/databases/{database_id}/documents/{document_path}`. For example: `projects/my-project/databases/my-database/documents/chatrooms/my-chatroom` Use `projects/{project_id}/databases/{database_id}/documents` to list top-level collections. | |
| pageSize | No | The maximum number of results to return. | |
| readTime | No | Reads documents as they were at the given time. This must be a microsecond precision timestamp within the past one hour, or if Point-in-Time Recovery is enabled, can additionally be a whole minute timestamp within the past 7 days. | |
| pageToken | No | A page token. Must be a value from ListCollectionIdsResponse. |
Output Schema
| Name | Required | Description |
|---|---|---|
| collectionIds | No | The collection ids. |
| nextPageToken | No | A page token that may be used to continue the list. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, indicating a safe, read-only operation with closed-world semantics. The description adds minimal behavioral context beyond this, such as the hierarchical relationship ('underneath a document'), but lacks details on pagination behavior, rate limits, or auth needs. No contradiction with annotations exists.
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, front-loaded sentence that directly states the tool's purpose without unnecessary words. It efficiently conveys the core action and scope, making it easy for an agent to parse and 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 tool's moderate complexity (4 parameters, 1 required), rich annotations (read-only, non-destructive, closed-world), and the presence of an output schema, the description is reasonably complete. It covers the basic purpose but could benefit from more usage guidance or behavioral details to fully compensate for the lack of explicit output explanation, though the output schema mitigates this gap.
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 detailed documentation for all 4 parameters (e.g., parent format, pageSize, readTime constraints, pageToken usage). The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline score of 3 without compensating for gaps.
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 ('collection IDs'), specifying they are 'underneath a document'. It distinguishes from siblings like list_documents or list_databases by focusing on collections within a document. However, it doesn't explicitly differentiate from list_documents in terms of hierarchy, which could be slightly more specific.
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 list_documents or list_databases. It mentions 'underneath a document' but doesn't clarify use cases, prerequisites, or exclusions, leaving the agent to infer based on context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_databasesBRead-onlyInspect
List Firestore databases.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. A parent name of the form `projects/{project_id}` | |
| showDeleted | No | If true, also returns deleted resources. |
Output Schema
| Name | Required | Description |
|---|---|---|
| databases | No | The databases in the project. |
| unreachable | No | In the event that data about individual databases cannot be listed they will be recorded here. An example entry might be: projects/some_project/locations/some_location This can happen if the Cloud Region that the Database resides in is currently unavailable. In this case we can't fetch all the details about the database. You may be able to get a more detailed error message (or possibly fetch the resource) by sending a 'Get' request for the resource or a 'List' request for the specific location. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and scope. The description adds no behavioral context beyond the basic action, such as pagination, rate limits, or authentication needs, but doesn't contradict annotations.
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, direct sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core action 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 low complexity (list operation), rich annotations, full schema coverage, and presence of an output schema, the description is reasonably complete. However, it could benefit from more usage context to guide the agent 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%, with clear documentation for both parameters (parent and showDeleted). The description adds no additional parameter semantics beyond what the schema provides, so it 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 verb 'List' and the resource 'Firestore databases', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_collections' or 'list_indexes', which would require mentioning it's specifically for databases at the project level.
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 'get_database' for a single database or 'list_collections' for collections within a database. It lacks context about prerequisites 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.
list_documentsBRead-onlyInspect
List documents from a Firestore database.
| Name | Required | Description | Default |
|---|---|---|---|
| mask | No | Optional. The fields to return. If not set, returns all fields. If a document has a field that is not present in this mask, that field will not be returned in the response. | |
| parent | Yes | Required. The parent resource name. In the format: `projects/{project_id}/databases/{database_id}/documents` or `projects/{project_id}/databases/{database_id}/documents/{document_path}`. For example: `projects/my-project/databases/my-database/documents` or `projects/my-project/databases/my-database/documents/chatrooms/my-chatroom` | |
| orderBy | No | Optional. The optional ordering of the documents to return. For example: `priority desc, __name__ desc`. This mirrors the `ORDER BY` used in Firestore queries but in a string representation. When absent, documents are ordered based on `__name__ ASC`. | |
| pageSize | No | Optional. The maximum number of documents to return in a single response. Firestore may return fewer than this value. | |
| readTime | No | Perform the read at the provided time. This must be a microsecond precision timestamp within the past one hour, or if Point-in-Time Recovery is enabled, can additionally be a whole minute timestamp within the past 7 days. | |
| pageToken | No | Optional. A page token, received from a previous `ListDocuments` response. Provide this to retrieve the subsequent page. When paginating, all other parameters (with the exception of `page_size`) must match the values set in the request that generated the page token. | |
| showMissing | No | If the list should show missing documents. A document is missing if it does not exist, but there are sub-documents nested underneath it. When true, such missing documents will be returned with a key but will not have fields, `create_time`, or `update_time` set. Requests with `show_missing` may not specify `where` or `order_by`. | |
| transaction | No | Perform the read as part of an already active transaction. | |
| collectionId | No | Optional. The collection ID, relative to `parent`, to list. For example: `chatrooms` or `messages`. This is optional, and when not provided, Firestore will list documents from all collections under the provided `parent`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| documents | No | The Documents found. |
| nextPageToken | No | A token to retrieve the next page of documents. If this field is omitted, there are no subsequent pages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and scope. The description adds no behavioral context beyond the basic action—no mention of pagination behavior, rate limits, authentication needs, or what 'list' entails operationally. It doesn't contradict annotations but adds minimal value beyond them.
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 resource, making it easy to parse. No structural issues or redundancy are present.
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 rich annotations (covering safety) and a 100% schema coverage with an output schema, the description is minimally adequate. However, for a tool with 9 parameters and sibling tools, it lacks context on usage scenarios, limitations, or how it fits into broader operations, leaving gaps in completeness.
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 semantic context about parameters—it doesn't explain what 'parent' means in practice, how 'mask' affects results, or the implications of 'showMissing'. Baseline 3 is appropriate as the schema carries the burden.
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 documents from a Firestore database' clearly states the verb ('List') and resource ('documents'), but it's vague about scope and doesn't distinguish from siblings like 'list_collections' or 'get_document'. It lacks specificity about what kind of listing operation this performs.
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 'get_document' (for single documents) or 'list_collections' (for collections). The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_indexesBRead-onlyInspect
List Firestore indexes.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | The filter to apply to list results. | |
| parent | Yes | Required. A parent name of the form `projects/{project_id}/databases/{database_id}/collectionGroups/{collection_id}` | |
| pageSize | No | The number of results to return. | |
| pageToken | No | A page token, returned from a previous call to FirestoreAdmin.ListIndexes, that may be used to get the next page of results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| indexes | No | The requested indexes. |
| nextPageToken | No | A page token that may be used to request another page of results. If blank, this is the last page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as read-only, non-destructive, and closed-world, so the agent knows it's a safe query operation. The description adds no behavioral context beyond what annotations provide - no mention of pagination behavior (implied by parameters), rate limits, authentication requirements, or what the output contains. With good annotation coverage, the bar is lower, but the description adds minimal value.
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 maximally concise - a single clear sentence with zero wasted words. It's perfectly front-loaded with the essential information about what the tool does. 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?
Given that this is a read-only list operation with comprehensive annotations (readOnlyHint, destructiveHint, openWorldHint) and a complete output schema exists, the description is reasonably complete. The main gap is lack of sibling differentiation and usage context, but for a straightforward list operation with good structured metadata, it's mostly adequate.
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 all parameters well-documented in the schema. The description adds no parameter information beyond what's already in the structured schema. The baseline of 3 is appropriate when the schema does all the heavy lifting for parameter documentation.
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 ('Firestore indexes'), making the tool's purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'list_databases', 'list_collections', or 'list_documents', which all follow the same 'list_[resource]' pattern for different Firestore resources.
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 about when to use this tool versus alternatives. It doesn't mention prerequisites (like needing admin permissions), when you'd list indexes versus creating/deleting them, or how this differs from other list operations for databases, collections, or documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_databaseBInspect
Update a Firestore database.
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Required. The database to update. | |
| updateMask | No | The list of fields to be updated. |
Output Schema
| Name | Required | Description |
|---|---|---|
| done | No | If the value is `false`, it means the operation is still in progress. If `true`, the operation is completed, and either `error` or `response` is available. |
| name | No | The server-assigned name, which is only unique within the same service that originally returns it. If you use the default HTTP mapping, the `name` should be a resource name ending with `operations/{unique_id}`. |
| error | No | The error result of the operation in case of failure or cancellation. |
| metadata | No | Service-specific metadata associated with the operation. It typically contains progress information and common metadata such as create time. Some services might not provide such metadata. Any method that returns a long-running operation should document the metadata type, if any. |
| response | No | The normal, successful response of the operation. If the original method returns no data on success, such as `Delete`, the response is `google.protobuf.Empty`. If the original method is standard `Get`/`Create`/`Update`, the response should be the resource. For other methods, the response should have the type `XxxResponse`, where `Xxx` is the original method name. For example, if the original method name is `TakeSnapshot()`, the inferred response type is `TakeSnapshotResponse`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutable, non-destructive, closed-world operation. The description adds no behavioral context beyond this, such as permissions needed, rate limits, or side effects. It doesn't contradict annotations, but fails to supplement them with useful operational details.
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, direct sentence with zero wasted words. It's front-loaded and efficiently communicates the core action, though it lacks depth.
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 (mutation with 2 parameters, rich schema, and output schema), the description is minimal. It doesn't address critical context like what 'updating' entails, common scenarios, or error conditions, relying heavily on structured fields to fill gaps.
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 well-documented in the schema. The description adds no semantic context beyond the schema, such as explaining the 'updateMask' field's purpose or typical use cases for updating database properties.
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 'Update a Firestore database' states the verb ('Update') and resource ('Firestore database'), which is clear but vague. It doesn't specify what aspects of the database can be updated or distinguish it from sibling tools like 'update_document', leaving 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing database), exclusions, or compare with siblings like 'create_database' or 'update_document', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_documentBInspect
Update a document from a Firestore database.
| Name | Required | Description | Default |
|---|---|---|---|
| mask | No | The fields to return. If not set, returns all fields. If the document has a field that is not present in this mask, that field will not be returned in the response. | |
| document | Yes | Required. The updated document. Creates the document if it does not already exist. | |
| updateMask | No | The fields to update. None of the field paths in the mask may contain a reserved name. If the document exists on the server and has fields not referenced in the mask, they are left unchanged. Fields referenced in the mask, but not present in the input document, are deleted from the document on the server. | |
| currentDocument | No | An optional precondition on the document. The request will fail if this is set and not met by the target document. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The resource name of the document, for example `projects/{project_id}/databases/{database_id}/documents/{document_path}`. |
| fields | No | The document's fields. The map keys represent field names. Field names matching the regular expression `__.*__` are reserved. Reserved field names are forbidden except in certain documented contexts. The field names, represented as UTF-8, must not exceed 1,500 bytes and cannot be empty. Field paths may be used in other contexts to refer to structured fields defined here. For `map_value`, the field path is represented by a dot-delimited (`.`) string of segments. Each segment is either a simple field name (defined below) or a quoted field name. For example, the structured field `"foo" : { map_value: { "x&y" : { string_value: "hello" }}}` would be represented by the field path `` foo.`x&y` ``. A simple field name contains only characters `a` to `z`, `A` to `Z`, `0` to `9`, or `_`, and must not start with `0` to `9`. For example, `foo_bar_17`. A quoted field name starts and ends with `` ` `` and may contain any character. Some characters, including `` ` ``, must be escaped using a `\`. For example, `` `x&y` `` represents `x&y` and `` `bak\`tik` `` represents `` bak`tik ``. |
| createTime | No | Output only. The time at which the document was created. This value increases monotonically when a document is deleted then recreated. It can also be compared to values from other documents and the `read_time` of a query. |
| updateTime | No | Output only. The time at which the document was last changed. This value is initially set to the `create_time` then increases monotonically with each change to the document. It can also be compared to values from other documents and the `read_time` of a query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-destructive, closed-world operation. The description adds minimal behavioral context beyond this, as 'Update' implies mutation but doesn't detail side effects like overwriting fields or handling missing documents. It doesn't contradict annotations, but provides little additional insight into behavior like error conditions or performance.
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 highly concise and front-loaded. It directly states the tool's action without unnecessary elaboration, earning a top score for brevity and clarity.
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, mutation operation) and the presence of annotations and an output schema, the description is minimally adequate. It states the basic action but lacks details on behavior, error handling, or integration with siblings, leaving gaps that could hinder effective use despite structured data coverage.
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 the four parameters (document, mask, updateMask, currentDocument). The description adds no parameter-specific information beyond what's in the schema, such as examples or usage tips, resulting in a baseline score of 3.
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 resource ('a document from a Firestore database'), making the purpose understandable. However, it doesn't differentiate this from sibling tools like 'add_document' or 'delete_document' beyond the basic verb difference, missing explicit comparison to 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 'add_document' or 'delete_document'. The description lacks context about prerequisites, such as needing an existing document or specific permissions, and doesn't mention any exclusions 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!