Provides access to Google Cloud Datastore (Firestore in Datastore mode), enabling operations such as creating, updating, and deleting entities, running complex queries and aggregations, and managing transactions.
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., "@MCP Datastore Server Find all User entities where age is greater than 25"
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 access to Google Firestore in Datastore mode.
This MCP server exposes the following tools for interacting with Google Cloud Datastore:
datastore_get: Get an entity by kind and key
datastore_insert: Insert a new entity
datastore_update: Update an existing entity
datastore_upsert: Insert or update an entity
datastore_delete: Delete an entity by kind and key
datastore_query: Query entities with filters and ordering
datastore_runAggregationQuery: Run aggregation queries (count, sum, avg)
datastore_listKinds: List all entity kinds (types) in the Datastore
datastore_allocateIds: Allocate IDs for incomplete keys
datastore_createKey: Create a complete or incomplete key
datastore_runInTransaction: Execute multiple operations in a transaction
Related MCP server: Cloud Datastore API MCP Server
A Google Cloud project with Datastore API enabled
Service account credentials with appropriate Datastore permissions
npm install
npm run buildSet the following environment variables:
# Path to your service account JSON key file
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json
# Your Google Cloud project ID
export GOOGLE_CLOUD_PROJECT=your-project-idOr you can provide them when running the server:
GOOGLE_APPLICATION_CREDENTIALS=/path/to/key.json GOOGLE_CLOUD_PROJECT=your-project-id npm startnpm startAdd this to your Claude Desktop configuration file:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"datastore": {
"command": "node",
"args": [
"d:\\projects\\mcp-datastore\\build\\index.js"
],
"env": {
"GOOGLE_APPLICATION_CREDENTIALS": "C:\\path\\to\\service-account-key.json",
"GOOGLE_CLOUD_PROJECT": "your-project-id"
}
}
}
}{
"kind": "User",
"keyId": "12345"
}{
"kind": "User",
"data": {
"name": "John Doe",
"email": "john@example.com",
"age": 30
}
}{
"kind": "User",
"filters": [
{
"property": "age",
"operator": ">",
"value": 25
}
],
"orderBy": [
{
"property": "name",
"descending": false
}
],
"limit": 10
}{
"kind": "Order",
"aggregations": [
{
"type": "count",
"alias": "total_orders"
},
{
"type": "sum",
"property": "amount",
"alias": "total_amount"
}
]
}{
"namespace": "optional-namespace" // Optional: specify namespace to list kinds from
}This returns all entity kinds (types) in your Datastore, including both user-defined kinds and system metadata kinds (prefixed with __Stat_).
MIT
Allocate IDs for incomplete keys
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | The kind (type) for the keys | |
| count | Yes | Number of IDs to allocate | |
| namespace | No | Optional namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions 'allocate IDs' which implies a write operation, but doesn't disclose if this is idempotent, has side effects, requires permissions, or how the IDs are returned (e.g., format, uniqueness). 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, front-loaded sentence with zero waste. It directly states the tool's function without unnecessary words, 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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'allocate IDs' entails (e.g., returns IDs, reserves them), how it fits into workflows, or what happens after allocation, leaving the agent with insufficient context 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 the schema already documents parameters (kind, count, namespace). The description adds no additional meaning beyond implying that these parameters relate to 'incomplete keys', but doesn't clarify how they interact or provide examples, meeting 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 'Allocate IDs for incomplete keys' states a purpose but is vague about what 'incomplete keys' means and doesn't specify the resource (e.g., Datastore entities). It distinguishes from siblings like datastore_createKey by focusing on ID allocation rather than key creation, but lacks specificity about the verb's exact 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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't explain if this is for pre-allocating IDs before insertion or how it relates to siblings like datastore_insert or datastore_createKey, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a complete or incomplete key
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | The kind (type) for the key | |
| keyId | No | Optional key ID (omit for incomplete key) | |
| namespace | No | Optional namespace | |
| path | No | Optional array for creating hierarchical keys [kind, id/name, kind, id/name, ...] |
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 creating keys but doesn't specify if this is a read-only operation, has side effects (e.g., persists data), requires authentication, or involves rate limits. The term 'create' suggests a mutation, but without annotations, critical behavioral traits like safety or idempotency are missing, making it inadequate for informed tool selection.
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. It avoids redundancy and wastes no words, though it could be more informative. However, its brevity borders on under-specification, as it lacks explanatory depth, slightly reducing its effectiveness despite good 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 complexity of a key creation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return value (e.g., the created key object), error conditions, or how it integrates with sibling tools like datastore_insert. For a mutation tool in a datastore context, more context is needed to ensure proper usage, making this insufficient.
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 (kind, keyId, namespace, path). The description adds minimal value by hinting at 'complete' vs. 'incomplete' keys, which loosely maps to optional keyId, but doesn't explain the semantics beyond what the schema provides (e.g., what makes a key 'complete'). This meets the baseline for high schema coverage without significant enhancement.
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 states the action ('Create') and resource ('key'), but it's vague about what a 'key' is in this context (e.g., a database key, identifier, or cryptographic key). It distinguishes between 'complete' and 'incomplete' keys, but without explaining the difference or purpose, leaving the agent to infer from parameters. This is better than a tautology but lacks specificity compared to siblings like datastore_insert or datastore_get.
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. For example, it doesn't explain if this is for generating keys before insertion (datastore_insert) or for other purposes, nor does it mention prerequisites like existing data. The description implies usage through the 'complete/incomplete' distinction but doesn't clarify when each is appropriate, leaving the agent to guess based on parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an entity from Datastore
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | The kind (type) of the entity | |
| keyId | Yes | The ID of the key | |
| namespace | No | Optional namespace for the entity |
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 action is a deletion, implying a destructive operation, but doesn't cover critical aspects like whether deletions are permanent, if they require specific permissions, or what happens on failure. 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, direct sentence with zero waste. It's front-loaded and efficiently conveys the core action without unnecessary elaboration, 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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral risks, return values, or error handling, which are crucial for safe usage. The context demands more detail than provided.
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 (kind, keyId, namespace) with descriptions. The description adds no additional meaning beyond the schema, such as examples or constraints, but the baseline is 3 when schema coverage is high.
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 ('an entity from Datastore'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like datastore_update or datastore_upsert, which also modify Datastore entities, so it misses full sibling distinction.
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. For example, it doesn't mention when to choose delete over update or upsert, or any prerequisites like needing to fetch an entity first. The description lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an entity by kind and key from Datastore
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | The kind (type) of the entity | |
| keyId | Yes | The ID of the key (can be string name or numeric ID) | |
| namespace | No | Optional namespace for the entity | |
| ancestors | No | Optional array of ancestor keys [kind, id/name, kind, id/name, ...] |
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 it 'gets' an entity without disclosing behavioral traits. It doesn't cover error handling (e.g., if the entity doesn't exist), permissions required, rate limits, or what the return format looks like (since there's no output schema). This is inadequate for a tool with mutation siblings like delete/update.
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 action and resource, 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 complexity of Datastore operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'Get' entails operationally (e.g., is it a direct lookup?), how results are returned, or error cases, leaving gaps for the agent to infer behavior in a context with mutation tools.
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 additional meaning beyond implying the tool uses 'kind and key' (matching the required parameters). This meets the baseline for high schema coverage but doesn't enhance understanding.
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 ('an entity by kind and key from Datastore'), making the purpose understandable. However, it doesn't explicitly differentiate this read operation from sibling tools like datastore_query or datastore_listKinds, which also retrieve data but 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. It doesn't mention scenarios like retrieving a single known entity (vs. datastore_query for filtered searches) or prerequisites such as needing the exact key. This leaves the agent without 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.
Insert a new entity into Datastore
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | The kind (type) of the entity | |
| data | Yes | The entity data to insert | |
| keyId | No | Optional key ID (if not provided, Datastore will auto-generate) | |
| namespace | No | Optional namespace for the entity | |
| excludeFromIndexes | No | Optional array of property names to exclude from indexes |
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 this is an insert operation, implying a write/mutation, but doesn't cover critical aspects like permissions required, whether it's idempotent, error handling, or what happens on conflicts. 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 waste—it directly states the tool's purpose without fluff. It's appropriately sized and front-loaded, making it easy for an agent 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 this is a mutation tool with no annotations, no output schema, and complex parameters (including nested objects), the description is incomplete. It doesn't address behavioral traits, return values, or usage context, leaving the agent with insufficient information to invoke it correctly in a real-world scenario.
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 5 parameters. The description adds no parameter-specific information beyond the generic 'entity' reference, not explaining what 'kind' or 'data' represent semantically. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't enhance understanding.
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 ('Insert') and resource ('a new entity into Datastore'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like datastore_upsert or datastore_update, which also modify entities, so it lacks specific sibling distinction.
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-not-to-use scenarios, or comparisons to siblings like datastore_upsert (for insert-or-update) or datastore_update (for existing entities), leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all entity kinds (types) in the Datastore by querying the kind metadata
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Optional namespace to list kinds from |
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 querying metadata but lacks details on permissions needed, rate limits, pagination, or return format. For a read operation with zero annotation coverage, this leaves significant behavioral 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, efficient sentence that front-loads the purpose ('List all entity kinds') and includes essential technical context. There is zero waste, making it appropriately sized for this simple 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 no annotations, no output schema, and a read operation that likely returns a list, the description is incomplete. It lacks details on response format, error handling, or behavioral constraints, which are crucial for an agent to use this 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 already documents the optional 'namespace' parameter. The description does not add any meaning beyond what the schema provides, such as explaining namespace implications or default behavior. 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 action ('List all entity kinds') and resource ('in the Datastore'), with specific technical detail about querying '__kind__ metadata'. It distinguishes from siblings like datastore_query or datastore_get by focusing on metadata rather than data entities, though not explicitly naming 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?
The description implies usage for retrieving metadata about entity types, but provides no explicit guidance on when to use this versus other tools (e.g., datastore_query for actual data). No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query entities from Datastore with optional filters, ordering, and pagination
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | The kind (type) of entities to query | |
| filters | No | Optional array of filter conditions | |
| orderBy | No | Optional array of properties to order by | |
| limit | No | Maximum number of results to return | |
| offset | No | Number of results to skip | |
| namespace | No | Optional namespace to query from | |
| select | No | Optional array of property names to return (projection query) |
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 querying with optional features but fails to describe critical behaviors: whether this is a read-only operation (likely, but not stated), potential performance impacts (e.g., large queries), error conditions (e.g., invalid filters), or the return format (e.g., list of entities). This leaves significant gaps for an agent to understand how the tool behaves in practice.
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 ('query entities from Datastore') and succinctly lists key capabilities ('optional filters, ordering, and pagination'). There is no wasted verbiage, and every word contributes to understanding the tool's scope.
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 (7 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what the tool returns (e.g., entity data structure), error handling, or usage constraints. For a query tool with rich filtering options, more context is needed to help an agent use it effectively without trial and error.
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 7 parameters with their types, descriptions, and constraints. The description adds minimal value beyond the schema by listing optional features (filters, ordering, pagination) but doesn't provide additional context like filter syntax examples or pagination limits. 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 verb ('query') and resource ('entities from Datastore'), making the purpose unambiguous. It distinguishes itself from siblings like datastore_get (single entity retrieval) and datastore_listKinds (metadata listing) by emphasizing querying with filters, ordering, and pagination. However, it doesn't explicitly contrast with datastore_runAggregationQuery, which is a more specialized sibling.
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 datastore_query over datastore_get (for single entities) or datastore_runAggregationQuery (for aggregated data), nor does it specify prerequisites like required permissions or data availability. Usage is implied by the tool name 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.
Run an aggregation query (count, sum, avg) on Datastore entities
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | The kind (type) of entities to query | |
| aggregations | Yes | Array of aggregations to perform | |
| filters | No | Optional array of filter conditions | |
| namespace | No | Optional namespace to query from |
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 only states what the tool does operationally, without mentioning whether it's read-only or mutating (though 'run' suggests read-only), performance characteristics, error conditions, authentication needs, or output format. For a query tool with 4 parameters and no output schema, this leaves significant behavioral 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a tool with clear parameters documented elsewhere, and the information is front-loaded with no wasted verbiage.
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 (aggregation operations with filters and namespaces), lack of annotations, and absence of an output schema, the description is insufficient. It doesn't explain what the tool returns (aggregation results), how errors are handled, or performance implications. For a data query tool with multiple parameters and no structured output documentation, more contextual information 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 description mentions 'aggregation query (count, sum, avg)' which aligns with the 'aggregations' parameter's enum values, adding minimal context beyond the 100% schema coverage. It doesn't explain the relationship between parameters (e.g., how filters apply before aggregation) or provide examples. With complete schema documentation, the baseline is 3, and the description adds only slight value.
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 tool's purpose: 'Run an aggregation query (count, sum, avg) on Datastore entities'. It specifies the verb ('run'), resource ('Datastore entities'), and operation type ('aggregation query'), distinguishing it from siblings like datastore_query (likely general queries) and datastore_get (single entity retrieval). However, it doesn't explicitly differentiate from datastore_query beyond mentioning aggregation types.
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 aggregation queries over regular queries (datastore_query) or other siblings like datastore_listKinds. There's no context about use cases, prerequisites, or exclusions, leaving the agent with no usage direction beyond the basic purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute multiple operations within a transaction
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | Array of operations to execute in the transaction |
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 mentions transactional execution, which implies atomicity and potential rollback on failure, but doesn't disclose critical behavioral traits such as whether the transaction is read-write, isolation levels, timeout handling, error behavior, or authentication needs. For a complex transactional tool with no annotation coverage, this is a significant gap.
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 any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance. Every part of the sentence earns its place by conveying the core transactional aspect.
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 transactional tool with multiple operation types, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like atomicity guarantees, error handling, or return values, which are crucial for safe usage. The schema handles parameters well, but the overall context lacks necessary details for effective tool invocation.
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, so the schema already documents the 'operations' parameter and its nested properties thoroughly. The description adds no additional meaning beyond what the schema provides, such as explaining transaction boundaries or operation ordering. With high schema coverage, the baseline is 3, and the description doesn't compensate further.
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 operations within a transaction'), making the purpose understandable. It distinguishes from siblings by focusing on transactional execution rather than individual operations like datastore_get or datastore_insert. However, it doesn't explicitly mention that this is for Google Cloud Datastore or similar database operations, which could make it slightly less 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 implies usage when multiple operations need to be executed atomically, which is a typical transaction use case. However, it doesn't explicitly state when to use this tool versus alternatives like individual datastore_insert or datastore_update calls, nor does it mention prerequisites like transaction requirements or when not to use it (e.g., for single operations). The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing entity in Datastore
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | The kind (type) of the entity | |
| keyId | Yes | The ID of the key | |
| data | Yes | The updated entity data | |
| namespace | No | Optional namespace for the entity | |
| excludeFromIndexes | No | Optional array of property names to exclude from indexes |
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 'Update' implying a mutation, but fails to describe critical aspects like required permissions, whether the update is partial or full, error handling (e.g., if the entity doesn't exist), or any rate limits. 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 that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy for an agent 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 insufficient. It lacks details on behavioral traits (e.g., idempotency, side effects), error conditions, and what the tool returns, leaving the agent with incomplete context 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, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond what's in the schema, such as explaining the relationship between 'kind' and 'keyId' or how 'data' merges with existing properties. 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 ('Update') and resource ('an existing entity in Datastore'), which is specific and unambiguous. However, it doesn't explicitly differentiate this tool from its sibling 'datastore_upsert', which likely serves a similar but distinct purpose, preventing 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 'datastore_upsert' or 'datastore_insert', nor does it mention prerequisites such as requiring an existing entity. It only states the basic function without context, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert or update an entity in Datastore (upsert operation)
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | The kind (type) of the entity | |
| keyId | Yes | The ID of the key | |
| data | Yes | The entity data | |
| namespace | No | Optional namespace for the entity | |
| excludeFromIndexes | No | Optional array of property names to exclude from indexes |
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 identifies the operation as an upsert but fails to describe critical behaviors such as permission requirements, whether it overwrites existing data, transaction implications, error handling, or response format. 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 that conveys the core purpose without unnecessary words. It is front-loaded and wastes no space, 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 lacks details on behavioral traits, error cases, return values, and how it differs from siblings. Given the complexity of an upsert operation and the rich sibling set, 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 the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what the schema provides, such as examples or constraints. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 ('insert or update') and resource ('an entity in Datastore'), with the parenthetical 'upsert operation' providing additional specificity. It distinguishes itself from siblings like datastore_insert and datastore_update by combining both operations, though it doesn't explicitly name those 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?
The description provides no guidance on when to use this tool versus alternatives like datastore_insert or datastore_update, nor does it mention prerequisites, error conditions, or contextual constraints. It merely states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity. Each targets a specific Datastore operation (e.g., get vs. query vs. runAggregationQuery), and even similar-sounding tools like insert, update, and upsert are clearly differentiated in their descriptions.
All tools follow a consistent 'datastore_verbNoun' pattern with snake_case throughout. The naming is predictable and readable, making it easy to understand each tool's function at a glance.
With 11 tools, this server is well-scoped for Datastore operations. Each tool earns its place by covering essential CRUD, querying, transaction, and metadata functions without being overwhelming or sparse.
The toolset provides complete coverage for Datastore operations, including key management (allocateIds, createKey), CRUD (insert, get, update, delete, upsert), querying (query, runAggregationQuery), transactions (runInTransaction), and metadata (listKinds). There are no obvious gaps that would hinder agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Google Compute Engine MCP server is a fully-managed Model Context Protocol server that provides tools to manage Google Compute Engine resources through AI agents. It enables capabilities including instance management (creating, starting, stopping, resetting, listing), disk management, handling instance templates and group managers, viewing machine and accelerator types, managing images, and accessing reservation and commitment information. The server operates as a zero-deployment, enterprise-grade endpoint at https://compute.googleapis.com/mcp with built-in IAM-based security.
MCP server for interacting with the Supabase platform
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/petekmet/mcp-gcp-datastore'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
