Server Details
Provides tools to manage Memorystore for Valkey instances and backups.
- 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.4/5 across 14 of 14 tools scored.
Each tool has a clearly distinct purpose targeting specific resources (instances, backups, backup collections, certificate authority, maintenance) and actions (create, get, list, update, delete, backup, export, reschedule). There is no overlap or ambiguity between tools; for example, backup_instance and export_backup serve different functions, and get_backup vs. get_backup_collection are clearly differentiated.
All tool names follow a consistent verb_noun pattern using snake_case, such as create_instance, list_backups, and update_instance. The naming is uniform across all 14 tools, with verbs like create, delete, get, list, update, backup, export, and reschedule consistently applied to specific nouns, making the set highly predictable and readable.
With 14 tools, the count is well-scoped for managing Memorystore for Valkey instances, covering core operations like CRUD for instances and backups, maintenance scheduling, and certificate retrieval. Each tool earns its place by addressing a specific need in the domain, avoiding bloat while providing comprehensive coverage for typical workflows.
The tool set offers complete CRUD and lifecycle coverage for the Memorystore for Valkey domain, including instance management (create, get, list, update, delete, backup, reschedule maintenance), backup handling (get, list, delete, export), backup collections (get, list), and certificate authority retrieval. There are no obvious gaps, and agents can perform end-to-end operations without dead ends.
Available Tools
14 toolsbackup_instanceBInspect
Back up a Memorystore for Valkey instance.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | Optional. TTL for the backup to expire. Value range is 1 day to 100 years. If not specified, the default value is 100 years. | |
| name | Yes | Required. Instance resource name using the form: `projects/{project_id}/locations/{location_id}/instances/{instance_id}` where `location_id` refers to a Google Cloud region. | |
| backupId | No | Optional. The id of the backup to be created. If not specified, the default value ([YYYYMMDDHHMMSS]_[Shortened Instance UID] is used. |
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-read-only, non-open-world, non-idempotent, and non-destructive operation, but the description doesn't add significant behavioral context beyond this. It implies a creation action ('Back up') without detailing effects like backup storage, performance impact, or rate limits, offering minimal value over 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 that efficiently conveys the core action without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.
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 (3 parameters, 1 required), full schema coverage, annotations, and an output schema, the description is reasonably complete. It states the basic purpose, though it could benefit from more context on usage and behavioral details, but the structured data compensates well.
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 all parameters (name, ttl, backupId). The description adds no additional meaning or context about these parameters, such as usage examples or constraints beyond what's in the schema, so it meets the baseline score.
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 ('Back up') and resource ('a Memorystore for Valkey instance'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'export_backup' or 'create_instance', which could handle similar backup-related operations, so 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 like 'export_backup' or 'create_instance' for backup-related tasks. It lacks context about prerequisites, such as instance status or permissions, 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.
create_instanceBInspect
Create a Memorystore for Valkey instance.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The parent resource where this instance will be created. Format: projects/{project}/locations/{location} | |
| instance | Yes | Required. The instance to create. | |
| requestId | No | Optional. An optional request ID to identify requests. Specify a unique request ID so that if you must retry your request, the server will know to ignore the request if it has already been completed. The server will guarantee that for at least 60 minutes since the first request. For example, consider a situation where you make an initial request and the request times out. If you make the request again with the same request ID, the server can check if original operation with the same request ID was received, and if so, will ignore the second request. This prevents clients from accidentally creating duplicate commitments. The request ID must be a valid UUID with the exception that zero UUID is not supported (00000000-0000-0000-0000-000000000000). | |
| instanceId | Yes | Required. The ID to use for the instance, which will become the final component of the instance's resource name. This value is subject to the following restrictions: * Must be 4-63 characters in length * Must begin with a letter or digit * Must contain only lowercase letters, digits, and hyphens * Must not end with a hyphen * Must be unique within a location |
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 operation, but the description adds no behavioral context beyond the basic 'Create' action. It doesn't mention creation time, resource provisioning behavior, potential costs, authentication needs, rate limits, or what happens on failure—critical details for a cloud resource creation tool that annotations don't 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, efficient sentence with zero wasted words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point 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?
For a complex creation tool with 4 parameters, rich schema documentation, and an output schema, the description is minimally adequate. It states what the tool does but lacks important context about behavioral expectations, error conditions, and operational considerations that would help an agent use it effectively despite the structured documentation.
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 thoroughly documents all 4 parameters. The description adds no parameter-specific information beyond implying an 'instance' is created, which is already obvious from the tool name and schema. 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 ('Create') and resource ('Memorystore for Valkey instance'), making the purpose unambiguous. It distinguishes this from deletion or update operations, though it doesn't explicitly differentiate from sibling tools like 'backup_instance' or 'update_instance' beyond the obvious verb difference.
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 'update_instance' or 'get_instance', nor does it mention prerequisites, dependencies, or typical usage contexts. It's a bare statement of function without operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_backupADestructiveInspect
Delete a Memorystore for Valkey backup.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. Instance backup resource name using the form: `projects/{project_id}/locations/{location_id}/backupCollections/{backup_collection_id}/backups/{backup_id}` | |
| requestId | No | Optional. Idempotent request UUID. |
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 indicate this is a destructive, non-idempotent, non-read-only operation. The description adds value by specifying the resource type ('Memorystore for Valkey backup'), which clarifies scope beyond the generic 'destructive' hint. It doesn't contradict annotations and provides useful context about what gets destroyed.
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 front-loads the core action and resource, making it immediately understandable. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with 2 parameters), annotations cover safety and idempotency, and an output schema exists (so return values are documented elsewhere), the description is reasonably complete. It specifies the resource type clearly, though it could benefit from more usage context or error handling hints.
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 (name and requestId). The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or usage tips. Baseline 3 is appropriate since the schema fully covers 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 specific action ('Delete') and resource ('a Memorystore for Valkey backup'), distinguishing it from siblings like delete_instance (which deletes instances) or get_backup (which retrieves backup info). It precisely identifies what the tool does without ambiguity.
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., backup must exist), exclusions (e.g., cannot delete if in use), or compare to siblings like export_backup or list_backups. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_instanceADestructiveInspect
Delete a Memorystore for Valkey instance.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The name of the instance to delete. Format: projects/{project}/locations/{location}/instances/{instance} | |
| requestId | No | Optional. An optional request ID to identify requests. Specify a unique request ID so that if you must retry your request, the server will know to ignore the request if it has already been completed. The server will guarantee that for at least 60 minutes after the first request. For example, consider a situation where you make an initial request and the request times out. If you make the request again with the same request ID, the server can check if original operation with the same request ID was received, and if so, will ignore the second request. This prevents clients from accidentally creating duplicate commitments. The request ID must be a valid UUID with the exception that zero UUID is not supported (00000000-0000-0000-0000-000000000000). |
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?
The annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=false, and idempotentHint=false. The description doesn't contradict these annotations and adds the specific resource type ('Memorystore for Valkey instance'), which provides useful context beyond the generic destructive nature indicated by 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 that states exactly what the tool does without any unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 indicate destructiveHint=true), the presence of an output schema, and 100% schema coverage, the description is minimally adequate. However, for a destructive operation, more context about consequences or confirmation requirements would be helpful, especially with sibling backup/restore tools available.
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, both parameters are well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions, so it meets the baseline expectation but doesn't provide additional semantic 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 the resource ('a Memorystore for Valkey instance'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like 'delete_backup' or explain what distinguishes deleting an instance versus other deletion operations in the 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. With sibling tools like 'delete_backup' and 'backup_instance' available, there's no indication of prerequisites, when deletion is appropriate, or what alternatives might exist for data preservation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_backupBInspect
Export a Memorystore for Valkey backup.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. Instance backup resource name using the form: `projects/{project_id}/locations/{location_id}/backupCollections/{backup_collection_id}/backups/{backup_id}` | |
| gcsBucket | No | Google Cloud Storage bucket, like "my-bucket". |
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 provide basic behavioral hints (readOnlyHint=false, destructiveHint=false, etc.), so the description doesn't need to repeat those. However, it adds minimal context about what 'Export' entails - it implies creating an external copy but doesn't specify format, destination details beyond the GCS bucket parameter, or any side effects. The description doesn't contradict annotations, but adds limited behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that gets straight to the point with no wasted words. It's front-loaded with the core action and resource. This is an example of efficient communication where 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 annotations cover basic behavioral traits, the input schema has 100% description coverage, and there's an output schema (which means return values are documented elsewhere), the description is reasonably complete for its purpose. The main gap is lack of differentiation from sibling tools, but for a straightforward export operation with good structured documentation, 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?
With 100% schema description coverage, the input schema already fully documents both parameters. The description doesn't add any parameter semantics beyond what's in the schema - it mentions 'backup' generally but doesn't explain the relationship between the 'name' parameter and the 'gcsBucket' parameter, or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Export') and resource ('a Memorystore for Valkey backup'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'backup_instance' or 'get_backup', which could cause confusion about when to use this specific export function versus other backup-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'backup_instance' or 'get_backup'. There's no mention of prerequisites, timing considerations, or typical use cases for exporting versus other backup operations in the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_backupBRead-onlyIdempotentInspect
Get detailed information about a Memorystore for Valkey backup.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. Instance backup resource name using the form: `projects/{project_id}/locations/{location_id}/backupCollections/{backup_collection_id}/backups/{backup_id}` |
Output Schema
| Name | Required | Description |
|---|---|---|
| uid | No | Output only. System assigned unique identifier of the backup. |
| name | No | Identifier. Full resource path of the backup. the last part of the name is the backup id with the following format: [YYYYMMDDHHMMSS]_[Shorted Instance UID] OR customer specified while backup instance. Example: 20240515123000_1234 |
| state | No | Output only. State of the backup. |
| instance | No | Output only. Instance resource path of this backup. |
| nodeType | No | Output only. Node type of the instance. |
| backupType | No | Output only. Type of the backup. |
| createTime | No | Output only. The time when the backup was created. |
| expireTime | No | Output only. The time when the backup will expire. |
| shardCount | No | Output only. Number of shards for the instance. |
| backupFiles | No | Output only. List of backup files of the backup. |
| instanceUid | No | Output only. Instance uid of this backup. |
| replicaCount | No | Output only. Number of replicas for the instance. |
| engineVersion | No | Output only. valkey-7.5/valkey-8.0, etc. |
| encryptionInfo | No | Output only. Encryption information of the backup. |
| totalSizeBytes | No | Output only. Total size of the backup in bytes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, non-destructive, and idempotent, which covers the core safety profile. The description adds minimal behavioral context beyond this - it specifies that information retrieved is 'detailed' but doesn't elaborate on what that includes, rate limits, or authentication requirements. 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, efficient sentence that immediately states the tool's purpose without unnecessary words. It's perfectly front-loaded and every word serves a clear function - no wasted verbiage or structural issues.
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 simple nature (single parameter, read-only operation), the presence of comprehensive annotations, and an output schema (which handles return value documentation), the description is reasonably complete. However, it could better address when to use this versus sibling tools and provide more context about what 'detailed information' includes.
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 'name' parameter including its format. The description doesn't add any parameter semantics beyond what's already in the schema, such as explaining what constitutes a valid backup name or how to obtain one. The baseline of 3 is appropriate when the schema carries the full parameter documentation 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 clearly states the action ('Get detailed information') and resource ('about a Memorystore for Valkey backup'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_backup_collection' or 'get_instance', which also retrieve information about related 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 on when to use this tool versus alternatives like 'list_backups' (for browsing) or 'get_backup_collection' (for collection-level details). It doesn't mention prerequisites such as needing a specific backup name format or when this operation is appropriate versus other retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_backup_collectionARead-onlyIdempotentInspect
Get detailed information about a Memorystore for Valkey backup collection.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. Instance backupCollection resource name using the form: `projects/{project_id}/locations/{location_id}/backupCollections/{backup_collection_id}` where `location_id` refers to a Google Cloud region. |
Output Schema
| Name | Required | Description |
|---|---|---|
| uid | No | Output only. System assigned unique identifier of the backup collection. |
| name | No | Identifier. Full resource path of the backup collection. |
| kmsKey | No | Output only. The KMS key used to encrypt the backups under this backup collection. |
| instance | No | Output only. The full resource path of the instance the backup collection belongs to. Example: projects/{project}/locations/{location}/instances/{instance} |
| createTime | No | Output only. The time when the backup collection was created. |
| instanceUid | No | Output only. The instance uid of the backup collection. |
| lastBackupTime | No | Output only. The last time a backup was created in the backup collection. |
| totalBackupCount | No | Output only. Total number of backups in the backup collection. |
| totalBackupSizeBytes | No | Output only. Total size of all backups in the backup collection. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide strong behavioral hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false), covering safety and idempotency. The description adds value by specifying the resource type ('Memorystore for Valkey backup collection'), which clarifies scope beyond what annotations indicate. No contradictions with annotations are present.
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 front-loaded with the core functionality and avoids redundancy. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 100% schema coverage, annotations covering key behaviors, and an output schema present), the description is reasonably complete. It specifies the resource type clearly, though it could benefit from mentioning sibling differentiation or usage context. The output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'name' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., it doesn't explain format constraints or examples). Baseline score of 3 is appropriate since 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 clearly states the tool's purpose: 'Get detailed information about a Memorystore for Valkey backup collection.' It specifies the verb ('Get') and resource ('backup collection'), but doesn't differentiate it from sibling tools like 'get_backup' or 'get_instance' that also retrieve information about different resources. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_backup_collections' (for listing collections) or 'get_backup' (for individual backups), nor does it specify prerequisites or contextual constraints. The agent must 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_certificate_authorityBRead-onlyIdempotentInspect
Get the certificate authority for a Memorystore for Valkey instance.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The name of the certificate authority. Format: projects/{project}/locations/{location}/instances/{instance}/certificateAuthority |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | Identifier. Unique name of the certificate authority. Format: projects/{project}/locations/{location}/instances/{instance} |
| managedServerCa | No | A managed server certificate authority. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover key behavioral traits (read-only, non-destructive, idempotent, closed-world), so the description adds minimal value beyond stating the operation. It doesn't disclose additional context like rate limits, authentication needs, or what 'certificate authority' entails (e.g., security certificates), but 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, direct sentence that efficiently conveys the core function without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse quickly, which is ideal for tool selection in an agent context.
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 (single parameter), rich annotations, and presence of an output schema, the description is reasonably complete. It specifies the resource type ('certificate authority for a Memorystore for Valkey instance'), which helps contextualize the tool within the sibling set, though it could better integrate with the broader instance management 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?
With 100% schema description coverage, the input schema fully documents the single required parameter 'name', including its format and purpose. The description adds no extra parameter details beyond implying it retrieves data for a specific instance, aligning with the baseline score when schema handles documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('certificate authority for a Memorystore for Valkey instance'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_instance' or 'get_backup', which follow similar 'get' patterns for different resources, leaving room for slight ambiguity in tool selection.
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 an existing instance), exclusions, or compare it to sibling tools like 'get_instance' for general instance details, leaving the agent to infer usage solely from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_instanceBRead-onlyIdempotentInspect
Get detailed information about a Memorystore for Valkey instance.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The name of the instance to retrieve. Format: projects/{project}/locations/{location}/instances/{instance} |
Output Schema
| Name | Required | Description |
|---|---|---|
| uid | No | Output only. System assigned, unique identifier for the instance. |
| mode | No | Optional. Immutable. The mode config for the instance. |
| name | No | Identifier. Unique name of the instance. Format: projects/{project}/locations/{location}/instances/{instance} |
| state | No | Output only. Current state of the instance. |
| kmsKey | No | Optional. The KMS key used to encrypt the at-rest data of the cluster. |
| labels | No | Optional. Labels to represent user-provided metadata. |
| nodeType | No | Optional. Machine type for individual nodes of the instance. |
| aclPolicy | No | Optional. The ACL policy for the instance. Format: projects/{project}/locations/{location}/aclPolicies/{acl_policy} |
| endpoints | No | Optional. Endpoints for the instance. |
| gcsSource | No | Optional. Immutable. Backups that stored in Cloud Storage buckets. The Cloud Storage buckets need to be the same region as the instances. Read permission is required to import from the provided Cloud Storage Objects. |
| stateInfo | No | Output only. Additional information about the state of the instance. |
| createTime | No | Output only. Creation timestamp of the instance. |
| nodeConfig | No | Output only. Configuration of individual nodes of the instance. |
| shardCount | No | Optional. Number of shards for the instance. |
| updateTime | No | Output only. Latest update timestamp of the instance. |
| replicaCount | No | Optional. Number of replica nodes per shard. If omitted the default is 0 replicas. |
| satisfiesPzi | No | Optional. Output only. Reserved for future use. |
| satisfiesPzs | No | Optional. Output only. Reserved for future use. |
| serverCaMode | No | Optional. Immutable. The Server CA mode for the instance. |
| serverCaPool | No | Optional. Immutable. The customer-managed CA pool for the instance. Only applicable if the Server CA mode is CUSTOMER_MANAGED_CAS_CA. Format: "projects/{project}/locations/{region}/caPools/{ca_pool}". |
| engineConfigs | No | Optional. User-provided engine configurations for the instance. |
| engineVersion | No | Optional. Engine version of the instance. |
| encryptionInfo | No | Output only. Encryption information of the data at rest of the cluster. |
| aclPolicyInSync | No | Output only. Whether the ACL rules applied to the instance are in sync with the latest ACL policy rules. This field is only applicable if the ACL policy is set for the instance. |
| migrationConfig | No | Output only. Migration config for the instance. |
| backupCollection | No | Output only. The backup collection full resource name. Example: projects/{project}/locations/{location}/backupCollections/{collection} |
| authorizationMode | No | Optional. Immutable. Authorization mode of the instance. |
| maintenancePolicy | No | Optional. The maintenance policy for the instance. If not provided, the maintenance event will be performed based on Memorystore internal rollout schedule. |
| persistenceConfig | No | Optional. Persistence configuration of the instance. |
| discoveryEndpoints | No | Output only. Deprecated: The discovery_endpoints parameter is deprecated. As a result, it will not be populated if the connections are created using endpoints parameter. Instead of this parameter, for discovery, use endpoints.connections.pscConnection and endpoints.connections.pscAutoConnection with connectionType CONNECTION_TYPE_DISCOVERY. |
| maintenanceVersion | No | Optional. This field can be used to trigger self service update to indicate the desired maintenance version. The input to this field can be determined by the available_maintenance_versions field. |
| pscAutoConnections | No | Optional. Immutable. Deprecated: Use the endpoints.connections.psc_auto_connection value instead. |
| maintenanceSchedule | No | Output only. Published maintenance schedule. |
| managedBackupSource | No | Optional. Immutable. Backups that generated and managed by memorystore service. |
| ondemandMaintenance | No | Optional. Input only. Ondemand maintenance for the instance. |
| pscAttachmentDetails | No | Output only. Service attachment details to configure PSC connections. |
| automatedBackupConfig | No | Optional. The automated backup config for the instance. |
| transitEncryptionMode | No | Optional. Immutable. In-transit encryption mode of the instance. |
| zoneDistributionConfig | No | Optional. Immutable. Zone distribution configuration of the instance for node allocation. |
| rotateServerCertificate | No | Optional. Input only. Rotate the server certificates. |
| simulateMaintenanceEvent | No | Optional. Input only. Simulate a maintenance event. |
| allowFewerZonesDeployment | No | Optional. Immutable. Deprecated, do not use. |
| deletionProtectionEnabled | No | Optional. If set to true deletion of the instance will fail. |
| effectiveMaintenanceVersion | No | Output only. This field represents the actual maintenance version of the instance. |
| availableMaintenanceVersions | No | Output only. This field is used to determine the available maintenance versions for the self service update. |
| crossInstanceReplicationConfig | No | Optional. The config for cross instance replication. |
| asyncInstanceEndpointsDeletionEnabled | No | Optional. If true, instance endpoints that are created and registered by customers can be deleted asynchronously. That is, such an instance endpoint can be de-registered before the forwarding rules in the instance endpoint are deleted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key traits (read-only, non-destructive, idempotent, closed-world), so the description adds little behavioral context. It doesn't disclose additional aspects like rate limits, authentication needs, or response format details, though 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input, rich annotations, and presence of an output schema, the description is reasonably complete for a read-only retrieval tool. It could be more helpful by mentioning sibling tools or usage context, but the structured data compensates well for the 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?
With 100% schema description coverage, the input schema fully documents the single 'name' parameter. The description adds no extra meaning about parameters, such as format nuances or examples, so it meets the baseline but doesn't enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a Memorystore for Valkey instance', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_backup' or 'get_certificate_authority' beyond the resource name, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_instances' for overviews or 'get_backup' for backup details. It lacks any context about prerequisites, typical use cases, or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_backup_collectionsBRead-onlyIdempotentInspect
List all Memorystore for Valkey backup collections.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The resource name of the backupCollection location using the form: `projects/{project_id}/locations/{location_id}` where `location_id` refers to a Google Cloud region. | |
| pageSize | No | Optional. The maximum number of items to return. If not specified, a default value of 1000 will be used by the service. Regardless of the page_size value, the response may include a partial list and a caller should only rely on response's `next_page_token` to determine if there are more clusters left to be queried. | |
| pageToken | No | Optional. The `next_page_token` value returned from a previous `ListBackupCollections` request, if any. |
Output Schema
| Name | Required | Description |
|---|---|---|
| unreachable | No | Locations that could not be reached. |
| nextPageToken | No | Token to retrieve the next page of results, or empty if there are no more results in the list. |
| backupCollections | No | A list of backupCollections in the project. If the `location_id` in the parent field of the request is "-", all regions available to the project are queried, and the results aggregated. If in such an aggregated query a location is unavailable, a placeholder backupCollection entry is included in the response with the `name` field set to a value of the form `projects/{project_id}/locations/{location_id}/backupCollections/`- and the `status` field set to ERROR and `status_message` field set to "location not available for ListBackupCollections". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds no behavioral context beyond what annotations declare, such as pagination behavior, rate limits, or authentication requirements. However, it doesn't contradict annotations, so it meets the lower bar with annotations present.
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 front-loaded and wastes no space, 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 the tool's simplicity (list operation), rich annotations, 100% schema coverage, and presence of an output schema, the description is reasonably complete. It states what the tool does, though it lacks differentiation from siblings and usage context, which are minor gaps given the structured data support.
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 semantics beyond what the schema provides, such as explaining the 'parent' format or pagination behavior. With high schema coverage, the baseline score of 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 clearly states the action ('List') and resource ('Memorystore for Valkey backup collections'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'list_backups' or 'list_instances', which would require mentioning it specifically lists backup collections rather than individual backups or instances.
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_backups' or 'get_backup_collection'. There's no mention of prerequisites, context for usage, or comparison with sibling tools, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_backupsBRead-onlyIdempotentInspect
List all Memorystore for Valkey backups.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The resource name of the backupCollection using the form: `projects/{project_id}/locations/{location_id}/backupCollections/{backup_collection_id}` | |
| pageSize | No | Optional. The maximum number of items to return. If not specified, a default value of 1000 will be used by the service. Regardless of the page_size value, the response may include a partial list and a caller should only rely on response's `next_page_token` to determine if there are more clusters left to be queried. | |
| pageToken | No | Optional. The `next_page_token` value returned from a previous `ListBackupCollections` request, if any. |
Output Schema
| Name | Required | Description |
|---|---|---|
| backups | No | A list of backups in the project. |
| unreachable | No | Backups that could not be reached. |
| nextPageToken | No | Token to retrieve the next page of results, or empty if there are no more results in the list. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (read-only, non-destructive, idempotent, closed-world), so the description doesn't need to repeat these. It adds minimal context by specifying 'all' backups, but doesn't mention pagination behavior, rate limits, or authentication requirements, which would be helpful given the schema's pagination parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It earns its place by clearly stating what the tool does, 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 the annotations cover safety and idempotency, the schema fully describes parameters, and an output schema exists (so return values are documented elsewhere), the description is reasonably complete. However, it could better address sibling differentiation and usage context to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents all three parameters. The description adds no additional parameter semantics beyond implying 'all' backups, which aligns with the schema but doesn't provide extra value. 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 ('List') and resource ('Memorystore for Valkey backups'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_backup_collections' or 'get_backup', which also deal with backups, leaving some ambiguity about when to choose this specific tool.
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_backup_collections' or 'get_backup'. It lacks context about prerequisites (e.g., needing a backup collection first) 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.
list_instancesBRead-onlyIdempotentInspect
List all Memorystore for Valkey instances.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional. Expression for filtering results. | |
| parent | Yes | Required. The parent to list instances from. Format: projects/{project}/locations/{location} | |
| orderBy | No | Optional. Sort results by a defined order. Supported values: "name", "create_time". | |
| pageSize | No | Optional. Requested page size. Server may return fewer items than requested. If unspecified, server will pick an appropriate default. | |
| pageToken | No | Optional. A token identifying a page of results the server should return. |
Output Schema
| Name | Required | Description |
|---|---|---|
| instances | No | If the {location} requested was "-" the response contains a list of instances from all locations. Instances in unreachable locations will be omitted. |
| unreachable | No | Locations that could not be reached. |
| nextPageToken | No | A token, which can be sent as `page_token` to retrieve the next page. 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?
The annotations already provide strong behavioral information (read-only, non-destructive, idempotent, closed-world). The description adds no additional behavioral context about pagination behavior, rate limits, authentication requirements, or what 'all' means in practice. However, it doesn't contradict the annotations, so it gets a baseline score for not adding value beyond what's already structured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any unnecessary words. It's appropriately sized for a simple listing operation and is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a read-only listing operation with comprehensive annotations (readOnlyHint, idempotentHint) and both input and output schemas, the minimal description is reasonably complete. The output schema will handle return value documentation, and the annotations cover safety concerns. However, the lack of sibling differentiation and usage context prevents a perfect score.
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 already thoroughly documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even without parameter details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all Memorystore for Valkey instances'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'list_backups' or 'list_backup_collections', which are also listing operations for related 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 on when to use this tool versus alternatives like 'get_instance' (for a single instance) or 'list_backups' (for a different resource type). It also doesn't mention prerequisites such as the required 'parent' parameter or when this listing operation is appropriate versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reschedule_maintenanceBInspect
Reschedule maintenance for a Memorystore for Valkey instance.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. Name of the instance to reschedule maintenance for: `projects/{project}/locations/{location_id}/instances/{instance}` | |
| scheduleTime | No | Optional. Timestamp when the maintenance shall be rescheduled to if reschedule_type=SPECIFIC_TIME, in RFC 3339 format. Example: `2012-11-15T16:19:00.094Z`. | |
| rescheduleType | Yes | Required. If reschedule type is SPECIFIC_TIME, schedule_time must be set. |
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?
The annotations already indicate this is a non-readOnly, non-destructive operation, which the description doesn't contradict. The description adds minimal behavioral context beyond annotations - it implies this changes maintenance timing but doesn't specify whether this causes downtime, requires specific permissions, or has rate limits. With annotations covering the basic safety profile, 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 states the core purpose without unnecessary words. It's appropriately sized for a tool with good schema documentation and gets straight to the point with zero wasted text.
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 mutation tool (non-readOnly) with complete input schema coverage and an output schema exists, the description is minimally adequate. However, it doesn't address important context like what maintenance entails, whether rescheduling affects instance availability, or how this differs from other instance management tools. The existence of an output schema reduces the burden, but more operational context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already thoroughly documents all parameters including their types, formats, enums, and constraints. The description adds no additional parameter semantics beyond what's in the schema, so it earns the baseline score 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 ('Reschedule maintenance') and the target resource ('Memorystore for Valkey instance'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its siblings like 'update_instance' or 'backup_instance' which might also involve maintenance-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like whether the instance must be in a specific state), doesn't differentiate from sibling tools like 'update_instance' that might handle maintenance settings, and offers no context about appropriate timing or constraints for rescheduling maintenance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_instanceBInspect
Update a Memorystore for Valkey instance.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | Yes | Required. The instance to update. | |
| requestId | No | Optional. An optional request ID to identify requests. Specify a unique request ID so that if you must retry your request, the server will know to ignore the request if it has already been completed. The server will guarantee that for at least 60 minutes since the first request. For example, consider a situation where you make an initial request and the request times out. If you make the request again with the same request ID, the server can check if original operation with the same request ID was received, and if so, will ignore the second request. This prevents clients from accidentally creating duplicate commitments. The request ID must be a valid UUID with the exception that zero UUID is not supported (00000000-0000-0000-0000-000000000000). | |
| updateMask | No | Optional. The list of fields to be updated on the instance. At least one field must be specified. |
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-idempotent, non-open-world operation. The description doesn't contradict these annotations, but adds minimal behavioral context beyond them. It doesn't mention potential side effects (e.g., instance downtime during update), authentication requirements, rate limits, or what happens when updateMask is omitted. With annotations covering basic safety profile, the description adds some value but lacks 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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately 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 tool's complexity (updating a cloud database instance with many configurable fields), the description is minimal. While annotations provide basic safety information and an output schema exists (not shown but indicated in context signals), the description doesn't address important contextual aspects like update constraints, state dependencies, or typical use cases. It meets minimum viability but leaves significant gaps for a mutation tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (instance, requestId, updateMask). The description adds no additional parameter semantics beyond what's in the schema. The baseline score 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 action ('Update') and resource ('a Memorystore for Valkey instance'), which is specific and unambiguous. However, it doesn't differentiate this tool from other update-related operations that might exist in the sibling tool list, such as 'reschedule_maintenance' which could also be considered an update operation.
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., instance must exist), exclusions (e.g., cannot update certain fields while instance is in certain states), or refer to sibling tools like 'create_instance' for initial creation or 'get_instance' to check current state before updating.
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!