Server Details
Interact with your Google Bigtable resources using natural language commands.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 13 of 13 tools scored. Lowest: 3.2/5.
Each tool targets a distinct resource (instance, table, logical view) and action (create, get, list, delete, update), with no overlap in purpose. Tools for different resources are clearly separated.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., create_instance, delete_table, list_logical_views. The naming is predictable and systematic.
13 tools cover the core operations for three resource types (instances, tables, logical views). Each tool serves a clear purpose without unnecessary duplication, making the set well-scoped.
The set covers create, get, list, delete for all resources, and update for logical views. Missing update functionality for instances and tables represents minor gaps, but the essential workflows are supported.
Available Tools
13 toolscreate_instanceAIdempotentInspect
Create a new instance in the specified project. The request requires project_id, instance_id, display_name, and at least one cluster. The instance_id must be RFC 1035 compliant. Each cluster must specify its zone (e.g. us-central1-a). Example: { "project_id": "my-project", "instance_id": "my-instance", "display_name": "This is my instance", "clusters": [ { "zone": "us-central1-a", "serve_nodes": 3, "default_storage_type": "SSD" } ] }
| Name | Required | Description | Default |
|---|---|---|---|
| clusters | Yes | Required. Clusters to be created within the instance. At least one cluster must be specified. | |
| projectId | Yes | Required. The project ID (e.g., "my-project"). If not known from the context, the Agent should attempt to get the current project ID from the gcloud config by running `gcloud config get-value project`. If the attempt fails, prompt the user for the project ID. | |
| instanceId | Yes | Required. The ID to be used when referring to the new instance within its project, e.g., just `myinstance` rather than `projects/myproject/instances/myinstance`. | |
| displayName | Yes | Required. The descriptive name for this instance as it appears in UIs. |
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 description adds valuable context beyond annotations: it specifies that 'at least one cluster' is required and provides a concrete example with zone format. While annotations already indicate this is a non-destructive, idempotent creation operation (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description enhances understanding with practical implementation details that aren't captured in the structured 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 perfectly structured and concise: two clear sentences stating the purpose and requirements, followed by a comprehensive example that demonstrates proper usage. Every element serves a purpose with zero wasted words, and the information is front-loaded with the most critical details first.
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 comprehensive input schema (100% coverage), rich annotations (covering safety, idempotency, and world state), and existence of an output schema, the description provides exactly what's needed: clear purpose, key requirements, and a practical example. It doesn't need to explain return values or repeat schema details, making it complete for this well-structured tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already thoroughly documents all 4 parameters and their nested cluster properties. The description adds minimal value beyond the schema by mentioning 'project_id, instance_id, display_name, and at least one cluster' and providing an example, but doesn't significantly enhance parameter understanding beyond what's already in the well-documented 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 specific action ('Create a new instance'), identifies the resource ('in the specified project'), and distinguishes from siblings like 'delete_instance' or 'get_instance' by specifying creation rather than deletion or retrieval. It provides a complete example that reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the example and required parameters, but doesn't explicitly state when to use this tool versus alternatives like 'list_instances' or 'get_instance'. It mentions the need for 'at least one cluster', which provides some guidance, but lacks explicit when/when-not or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_logical_viewAIdempotentInspect
Create a new Bigtable logical view within a specified instance. The request requires project_id, instance_id, logical_view_id, and logical_view. The logical_view_id can be any name up to 128 characters. Example: { "project_id": "my-project", "instance_id": "my-instance", "logical_view_id": "my-logical-view", logical_view: { "query": "SELECT CF FROM my-table" } }
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | Required. The project ID (e.g., "my-project"). If not known from the context, the Agent should attempt to get the current project ID from the gcloud config by running `gcloud config get-value project`. If the attempt fails, prompt the user for the project ID. | |
| instanceId | Yes | Required. The instance ID within the project where the logical view will be created (e.g., "my-instance"). | |
| logicalView | Yes | Required. The logical view to create. | |
| logicalViewId | Yes | Required. The ID used for the logical view within its instance, e.g., `mylogicalview`. |
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 provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds the constraint that logical_view_id can be up to 128 characters and includes an example query, but doesn't disclose side effects, permissions, or error conditions beyond what annotations already 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?
Three concise sentences plus a clear example. No superfluous content; every sentence adds value.
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 presence of an output schema, the description does not need to detail return values. It adequately covers inputs, provides an example, and adds a constraint. However, it omits mention of optional fields like deletionProtection, which are in the schema but not highlighted.
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 coverage is 100%, so baseline is 3. The description adds the character limit for logical_view_id and provides an example of the logical_view query, adding minor value 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 tool creates a new Bigtable logical view, which is a specific verb-resource pair. It distinguishes from sibling tools like create_table and create_instance by focusing on logical views.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention scenarios where create_logical_view is preferable to other create tools or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_tableBIdempotentInspect
Create a new table in the specified instance.
| Name | Required | Description | Default |
|---|---|---|---|
| tableId | Yes | Required. The ID to be used when referring to the new table within its instance, e.g., just `mytable`. | |
| projectId | Yes | Required. The project ID (e.g., "my-project"). If not known from the context, the Agent should attempt to get the current project ID from the gcloud config by running `gcloud config get-value project`. If the attempt fails, prompt the user for the project ID. | |
| instanceId | Yes | Required. The instance ID within the project where the table will be created (e.g., "my-instance"). | |
| columnFamilies | No | Optional. The names of the column families to be created in the table. Example: `["cf1", "cf2"]`. The tool mapping will apply a default garbage collection policy (e.g., keeping only the latest version) to each column family. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The unique name of the table. Values are of the form `projects/{project}/instances/{instance}/tables/_a-zA-Z0-9*`. Views: `NAME_ONLY`, `SCHEMA_VIEW`, `REPLICATION_VIEW`, `STATS_VIEW`, `FULL` |
| stats | No | Output only. Only available with STATS_VIEW, this includes summary statistics about the entire table contents. For statistics about a specific column family, see ColumnFamilyStats in the mapped ColumnFamily collection above. |
| granularity | No | Immutable. The granularity at which timestamps are stored in this table. Timestamps not matching the granularity will be rejected. If unspecified at creation time, the value will be set to `MILLIS`. Views: `SCHEMA_VIEW`, `FULL`. |
| restoreInfo | No | Output only. If this table was restored from another data source (e.g. a backup), this field will be populated with information about the restore. |
| rowKeySchema | No | The row key schema for this table. The schema is used to decode the raw row key bytes into a structured format. The order of field declarations in this schema is important, as it reflects how the raw row key bytes are structured. Currently, this only affects how the key is read via a GoogleSQL query from the ExecuteQuery API. For a SQL query, the _key column is still read as raw bytes. But queries can reference the key fields by name, which will be decoded from _key using provided type and encoding. Queries that reference key fields will fail if they encounter an invalid row key. For example, if _key = "some_id#2024-04-30#\x00\x13\x00\xf3" with the following schema: { fields { field_name: "id" type { string { encoding: utf8_bytes {} } } } fields { field_name: "date" type { string { encoding: utf8_bytes {} } } } fields { field_name: "product_code" type { int64 { encoding: big_endian_bytes {} } } } encoding { delimited_bytes { delimiter: "#" } } } The decoded key parts would be: id = "some_id", date = "2024-04-30", product_code = 1245427 The query "SELECT _key, product_code FROM table" will return two columns: /------------------------------------------------------\ | _key | product_code | | --------------------------------------|--------------| | "some_id#2024-04-30#\x00\x13\x00\xf3" | 1245427 | \------------------------------------------------------/ The schema has the following invariants: (1) The decoded field values are order-preserved. For read, the field values will be decoded in sorted mode from the raw bytes. (2) Every field in the schema must specify a non-empty name. (3) Every field must specify a type with an associated encoding. The type is limited to scalar types only: Array, Map, Aggregate, and Struct are not allowed. (4) The field names must not collide with existing column family names and reserved keywords "_key" and "_timestamp". The following update operations are allowed for row_key_schema: - Update from an empty schema to a new schema. - Remove the existing schema. This operation requires setting the `ignore_warnings` flag to `true`, since it might be a backward incompatible change. Without the flag, the update request will fail with an INVALID_ARGUMENT error. Any other row key schema update operation (e.g. update existing schema columns names or types) is currently unsupported. |
| clusterStates | No | Output only. Map from cluster ID to per-cluster table state. If it could not be determined whether or not the table has data in a particular cluster (for example, if its zone is unavailable), then there will be an entry for the cluster with UNKNOWN `replication_status`. Views: `REPLICATION_VIEW`, `ENCRYPTION_VIEW`, `FULL` |
| columnFamilies | No | The column families configured for this table, mapped by column family ID. Views: `SCHEMA_VIEW`, `STATS_VIEW`, `FULL` |
| changeStreamConfig | No | If specified, enable the change stream on this table. Otherwise, the change stream is disabled and the change stream is not retained. |
| deletionProtection | No | Set to true to make the table protected against data loss. i.e. deleting the following resources through Admin APIs are prohibited: * The table. * The column families in the table. * The instance containing the table. Note one can still delete the data stored in the table through Data APIs. |
| tieredStorageConfig | No | Rules to specify what data is stored in each storage tier. Different tiers store data differently, providing different trade-offs between cost and performance. Different parts of a table can be stored separately on different tiers. If a config is specified, tiered storage is enabled for this table. Otherwise, tiered storage is disabled. Only SSD instances can configure tiered storage. |
| automatedBackupPolicy | No | If specified, automated backups are enabled for this table. Otherwise, automated backups are disabled. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds minimal context beyond this, stating only that it creates a table, which aligns with the annotations but doesn't provide additional details like error conditions, permissions needed, or rate limits. 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 extremely concise—a single sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and wastes no words, making it efficient for quick understanding by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (creating a table with 4 parameters), rich annotations (covering safety and idempotency), and the presence of an output schema (which handles return values), the description is mostly complete. However, it lacks usage guidelines and doesn't address sibling tool distinctions, leaving a minor gap in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for all parameters (e.g., projectId includes fallback instructions, tableId clarifies format, columnFamilies explains defaults). The description adds no parameter semantics beyond what the schema already provides, so it meets the baseline for high schema coverage without compensating 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 action ('Create') and resource ('new table in the specified instance'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'create_instance', which also creates resources in the same system, leaving some ambiguity about when to use one versus the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_instance' or 'delete_table'. It doesn't mention prerequisites (e.g., needing an existing instance), exclusions, or typical use cases, 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.
delete_instanceADestructiveIdempotentInspect
Delete an instance from a project. The request requires the 'name' field to be set in the format 'projects/{project}/instances/{instance}'. Example: { "name": "projects/my-project/instances/my-instance" } Before executing the deletion, you MUST confirm the action with the user by stating the full instance name and asking for "yes/no" confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The unique name of the instance to be deleted. Values are of the form `projects/{project}/instances/{instance}`. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies a mandatory user confirmation step and provides an example request format. Annotations already indicate destructiveHint=true (mutation), readOnlyHint=false, idempotentHint=true, and openWorldHint=true, so the description doesn't contradict them. However, it doesn't elaborate on side effects (e.g., data loss, billing implications) or error conditions, which would be helpful given the destructive nature.
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 front-loaded with the core purpose, followed by essential details (request format, example, confirmation requirement) in three concise sentences. Each sentence serves a clear purpose: stating the action, specifying input requirements, and mandating safety protocols. There is no redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (destructive operation), rich annotations (covering safety and idempotency), and existing output schema, the description is largely complete. It covers purpose, input guidance, and a critical safety step. However, for a destructive tool, it could benefit from mentioning irreversible consequences or linking to verification tools like get_instance, though the confirmation requirement partially addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents the single 'name' parameter. The description adds practical value by reinforcing the required format ('projects/{project}/instances/{instance}') and providing a concrete example, which aids understanding beyond the schema's technical description. It doesn't introduce new parameter details but enhances usability.
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 ('an instance from a project'), distinguishing it from siblings like delete_table (which targets tables) and get_instance/list_instances (which are read-only). The verb+resource combination is precise and unambiguous.
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 explicitly states when to use this tool (to delete an instance) and includes a critical prerequisite: 'Before executing the deletion, you MUST confirm the action with the user by stating the full instance name and asking for "yes/no" confirmation.' This provides clear guidance on usage context and safety measures, though it doesn't name specific alternatives like get_instance for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_logical_viewADestructiveIdempotentInspect
Deletes a Bigtable logical view within a specified instance.
The request requires the name field to be set in the format 'projects/{project}/instances/{instance}/logicalViews/{logical_view}'.
Example: { "name": "projects/my-project/instances/my-instance/logicalViews/my-logical-view" }
Before executing the deletion, you MUST confirm the action with the user by stating the full logical view name and asking for "yes/no" confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| etag | No | Optional. The current etag of the logical view. If an etag is provided and does not match the current etag of the logical view, deletion will be blocked and an ABORTED error will be returned. | |
| name | Yes | Required. The unique name of the logical view to be deleted. Format: `projects/{project}/instances/{instance}/logicalViews/{logical_view}`. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description adds a critical behavioral instruction: before deletion, the agent MUST confirm with the user by stating the full name and asking for yes/no confirmation. This requirement is not in annotations and provides essential 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 concise: two sentences and a clear instruction. It is front-loaded with purpose and example, and every sentence adds necessary 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 presence of output schema and full annotations, the description covers the essential aspects: purpose, required format, and a critical behavioral rule. It does not detail error codes or return values, but these are covered by schema and annotations.
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% for both parameters. The description adds value by providing a concrete example of the 'name' format, which reinforces the schema information. No additional context is needed for the etag parameter as it is well-described in 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 tool's purpose: 'Deletes a Bigtable logical view within a specified instance.' It specifies the verb (deletes) and resource (logical view), and distinguishes from sibling tools like delete_table and delete_instance by naming the exact resource type.
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 deleting a logical view, and sibling tools operate on different resources (instances, tables, etc.), so no explicit alternatives are needed. However, no direct guidance on when-not-to-use is given, but the purpose is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_tableADestructiveIdempotentInspect
Delete a table.
The request requires the 'name' field to be set in the format 'projects/{project}/instances/{instance}/tables/{table}'.
Example: { "name": "projects/my-project/instances/my-instance/tables/my-table" }
The table must exist. You can use list_tables to verify.
Before executing the deletion, you MUST confirm the action with the user by stating the full table name and asking for "yes/no" confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The unique name of the table to be deleted. Values are of the form `projects/{project}/instances/{instance}/tables/{table}`. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive, non-read-only operation (destructiveHint: true, readOnlyHint: false). The description adds valuable behavioral context beyond annotations: it specifies the table must exist, mentions using list_tables for verification, and most importantly, mandates user confirmation before execution. This provides critical workflow guidance 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 well-structured and front-loaded with the core purpose. Each sentence adds value: format requirements, existence verification, and confirmation protocol. While slightly longer than minimal, every sentence serves a clear purpose in guiding proper tool usage.
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 operation with comprehensive annotations (including destructiveHint: true) and an output schema exists, the description provides excellent contextual completeness. It covers prerequisites, verification methods, safety protocols, and format requirements, making it complete for a dangerous operation even with structured fields already providing some information.
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 the single 'name' parameter. The description adds minimal value beyond the schema by providing an example format and mentioning the format requirement, but doesn't add significant semantic context that isn't already in the schema's description field.
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 a table') and distinguishes it from siblings like 'delete_instance' by specifying the resource type. It goes beyond just restating the name by providing operational context about what the tool actually does.
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 explicit guidance on when to use this tool: 'The table must exist. You can use `list_tables` to verify.' It also specifies a critical prerequisite: 'Before executing the deletion, you MUST confirm the action with the user by stating the full table name and asking for "yes/no" confirmation.' This gives clear alternative actions and conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_instanceBRead-onlyInspect
Get information about an instance. The request requires the 'name' field to be set in the format 'projects/{project}/instances/{instance}'. Example: { "name": "projects/my-project/instances/my-instance" }
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The unique name of the requested instance. Values are of the form `projects/{project}/instances/{instance}`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The unique name of the instance. Values are of the form `projects/{project}/instances/a-z+[a-z0-9]`. |
| tags | No | Optional. Input only. Immutable. Tag keys/values directly bound to this resource. For example: - "123/environment": "production", - "123/costCenter": "marketing" Tags and Labels (above) are both used to bind metadata to resources, with different use-cases. See https://cloud.google.com/resource-manager/docs/tags/tags-overview for an in-depth overview on the difference between tags and labels. |
| type | No | The type of the instance. Defaults to `PRODUCTION`. |
| state | No | Output only. The current state of the instance. |
| labels | No | Labels are a flexible and lightweight mechanism for organizing cloud resources into groups that reflect a customer's organizational needs and deployment strategies. They can be used to filter resources and aggregate metrics. * Label keys must be between 1 and 63 characters long and must conform to the regular expression: `\p{Ll}\p{Lo}{0,62}`. * Label values must be between 0 and 63 characters long and must conform to the regular expression: `[\p{Ll}\p{Lo}\p{N}_-]{0,63}`. * No more than 64 labels can be associated with a given resource. * Keys and values must both be under 128 bytes. |
| edition | No | Optional. The edition of the instance. See Edition for details. |
| createTime | No | Output only. A commit timestamp representing when this Instance was created. For instances created before this field was added (August 2021), this value is `seconds: 0, nanos: 1`. |
| displayName | No | Required. The descriptive name for this instance as it appears in UIs. Can be changed at any time, but should be kept globally unique to avoid confusion. |
| satisfiesPzi | No | Output only. Reserved for future use. |
| satisfiesPzs | No | Output only. Reserved for future use. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering safety and scope. The description adds minimal behavioral context by specifying the required name format and providing an example, but doesn't disclose additional traits like rate limits, authentication needs, or response behavior beyond what annotations imply.
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 front-loaded with the core purpose, followed by essential formatting details and a clear example. Every sentence serves a functional role without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), high schema coverage (100%), presence of annotations, and an output schema (which handles return values), the description is reasonably complete. It covers the purpose and usage mechanics adequately, though it lacks contextual guidance on when to use this tool versus siblings.
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 schema fully documenting the single required 'name' parameter. The description adds an example format ('projects/{project}/instances/{instance}') and a concrete example, which provides some practical clarification but doesn't significantly enhance the semantic understanding beyond the schema's 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 tool's purpose as 'Get information about an instance,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_table' or 'list_instances,' which would require more specific scope or context information.
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' or 'get_table.' It only explains how to format the request, not the contextual scenarios where retrieving a single instance's information is appropriate compared to listing multiple instances or accessing table data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_logical_viewARead-onlyInspect
Get information about the specified logical view.
The request requires the name field to be set in the format 'projects/{project}/instances/{instance}/logicalViews/{logical_view}'.
Example: { "name": "projects/my-project/instances/my-instance/logicalViews/my-logical-view" }
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The unique name of the requested logical view. Values are of the form `projects/{project}/instances/{instance}/logicalViews/{logical_view}`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | Identifier. The name of the logical view. |
| query | No | Required. The logical view's select query. |
| deletionProtection | No | Optional. Set to true to make the LogicalView protected against deletion. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds only the name format requirement, not additional behavioral context like error handling or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a helpful example, no redundant 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?
With an output schema and thorough parameter documentation, the description provides everything needed for a simple get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'name' parameter. The description adds a concrete example and emphasizes the requirement, adding value 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 action ('Get information') and resource ('logical view'), distinguishing it from sibling tools like create, delete, update, list, and get for other 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 explains the required name format but does not provide guidance on when to use this tool versus alternatives like list_logical_views or other get operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tableBRead-onlyInspect
Get metadata information about the specified table. The request requires the 'name' field to be set in the format 'projects/{project}/instances/{instance}/tables/{table}'. Example: { "name": "projects/my-project/instances/my-instance/tables/my-table" }
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The unique name of the requested table. Values are of the form `projects/{project}/instances/{instance}/tables/{table}`. | |
| view | No | The view to be applied to the returned table's fields. Defaults to `SCHEMA_VIEW` if unspecified. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | The unique name of the table. Values are of the form `projects/{project}/instances/{instance}/tables/_a-zA-Z0-9*`. Views: `NAME_ONLY`, `SCHEMA_VIEW`, `REPLICATION_VIEW`, `STATS_VIEW`, `FULL` |
| stats | No | Output only. Only available with STATS_VIEW, this includes summary statistics about the entire table contents. For statistics about a specific column family, see ColumnFamilyStats in the mapped ColumnFamily collection above. |
| granularity | No | Immutable. The granularity at which timestamps are stored in this table. Timestamps not matching the granularity will be rejected. If unspecified at creation time, the value will be set to `MILLIS`. Views: `SCHEMA_VIEW`, `FULL`. |
| restoreInfo | No | Output only. If this table was restored from another data source (e.g. a backup), this field will be populated with information about the restore. |
| rowKeySchema | No | The row key schema for this table. The schema is used to decode the raw row key bytes into a structured format. The order of field declarations in this schema is important, as it reflects how the raw row key bytes are structured. Currently, this only affects how the key is read via a GoogleSQL query from the ExecuteQuery API. For a SQL query, the _key column is still read as raw bytes. But queries can reference the key fields by name, which will be decoded from _key using provided type and encoding. Queries that reference key fields will fail if they encounter an invalid row key. For example, if _key = "some_id#2024-04-30#\x00\x13\x00\xf3" with the following schema: { fields { field_name: "id" type { string { encoding: utf8_bytes {} } } } fields { field_name: "date" type { string { encoding: utf8_bytes {} } } } fields { field_name: "product_code" type { int64 { encoding: big_endian_bytes {} } } } encoding { delimited_bytes { delimiter: "#" } } } The decoded key parts would be: id = "some_id", date = "2024-04-30", product_code = 1245427 The query "SELECT _key, product_code FROM table" will return two columns: /------------------------------------------------------\ | _key | product_code | | --------------------------------------|--------------| | "some_id#2024-04-30#\x00\x13\x00\xf3" | 1245427 | \------------------------------------------------------/ The schema has the following invariants: (1) The decoded field values are order-preserved. For read, the field values will be decoded in sorted mode from the raw bytes. (2) Every field in the schema must specify a non-empty name. (3) Every field must specify a type with an associated encoding. The type is limited to scalar types only: Array, Map, Aggregate, and Struct are not allowed. (4) The field names must not collide with existing column family names and reserved keywords "_key" and "_timestamp". The following update operations are allowed for row_key_schema: - Update from an empty schema to a new schema. - Remove the existing schema. This operation requires setting the `ignore_warnings` flag to `true`, since it might be a backward incompatible change. Without the flag, the update request will fail with an INVALID_ARGUMENT error. Any other row key schema update operation (e.g. update existing schema columns names or types) is currently unsupported. |
| clusterStates | No | Output only. Map from cluster ID to per-cluster table state. If it could not be determined whether or not the table has data in a particular cluster (for example, if its zone is unavailable), then there will be an entry for the cluster with UNKNOWN `replication_status`. Views: `REPLICATION_VIEW`, `ENCRYPTION_VIEW`, `FULL` |
| columnFamilies | No | The column families configured for this table, mapped by column family ID. Views: `SCHEMA_VIEW`, `STATS_VIEW`, `FULL` |
| changeStreamConfig | No | If specified, enable the change stream on this table. Otherwise, the change stream is disabled and the change stream is not retained. |
| deletionProtection | No | Set to true to make the table protected against data loss. i.e. deleting the following resources through Admin APIs are prohibited: * The table. * The column families in the table. * The instance containing the table. Note one can still delete the data stored in the table through Data APIs. |
| tieredStorageConfig | No | Rules to specify what data is stored in each storage tier. Different tiers store data differently, providing different trade-offs between cost and performance. Different parts of a table can be stored separately on different tiers. If a config is specified, tiered storage is enabled for this table. Otherwise, tiered storage is disabled. Only SSD instances can configure tiered storage. |
| automatedBackupPolicy | No | If specified, automated backups are enabled for this table. Otherwise, automated backups are disabled. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering safety and scope. The description adds minimal behavioral context by specifying the required parameter format and providing an example, but doesn't elaborate on rate limits, authentication needs, or what 'metadata information' specifically includes beyond what the schema provides.
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 appropriately sized with three sentences: a purpose statement, a requirement clarification, and an example. It's front-loaded with the core purpose and avoids unnecessary elaboration, though the example could be slightly more concise.
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, rich annotations (covering safety and scope), 100% schema coverage, and the presence of an output schema, the description is reasonably complete. It covers the essential usage pattern but lacks guidance on tool selection versus siblings, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents both parameters. The description adds value by emphasizing the required 'name' field format and providing an example, but doesn't explain parameter semantics beyond what's already in the schema (e.g., it doesn't clarify the practical impact of different 'view' options).
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 as 'Get metadata information about the specified table,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate this from sibling tools like 'get_instance' or 'list_tables' beyond the obvious resource difference (table vs instance vs list).
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 'get_table' over 'list_tables' (for detailed metadata vs listing), nor does it discuss prerequisites or context for usage beyond the required parameter format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_instancesBRead-onlyInspect
List information about instances in a project. The request requires the 'parent' field to be set in the format 'projects/{project}'. Example: { "parent": "projects/my-project" }
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The unique name of the project for which a list of instances is requested. Values are of the form `projects/{project}`. | |
| pageToken | No | DEPRECATED: This field is unused and ignored. |
Output Schema
| Name | Required | Description |
|---|---|---|
| instances | No | The list of requested instances. |
| nextPageToken | No | DEPRECATED: This field is unused and ignored. |
| failedLocations | No | Locations from which Instance information could not be retrieved, due to an outage or some other transient condition. Instances whose Clusters are all in one of the failed locations may be missing from `instances`, and Instances with at least one Cluster in a failed location may only have partial information returned. Values are of the form `projects//locations/` |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and open-world behavior, so the description doesn't need to repeat these. It adds useful context by specifying the required 'parent' field format and providing an example, which helps clarify how to invoke the tool. However, it doesn't disclose additional behavioral traits like pagination, rate limits, or auth needs beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose statement, requirement, and example. It's front-loaded with the core function and avoids unnecessary details. However, the example could be integrated more seamlessly, and there's slight redundancy with the schema, keeping it from a perfect 5.
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, rich annotations (read-only, non-destructive, open-world), and the presence of an output schema, the description is reasonably complete. It covers the essential purpose and invocation details. However, it lacks guidance on usage relative to siblings and doesn't mention the deprecated 'pageToken' parameter, leaving minor gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds minimal value by reiterating the required 'parent' field and its format, but doesn't provide new semantics beyond the schema. With high coverage, the baseline is 3, as the description doesn't significantly enhance parameter 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 tool's purpose: 'List information about instances in a project.' It specifies the verb ('List') and resource ('instances in a project'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_instance' or 'list_tables,' which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the required 'parent' field but doesn't compare it to siblings like 'get_instance' (for single instance details) or 'list_tables' (for tables within instances). There's no mention of prerequisites or exclusions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_logical_viewsARead-onlyInspect
List information about all logical views within a specified instance.
The request requires the parent field to be set in the format 'projects/{project}/instances/{instance}'.
Example: { "parent": "projects/my-project/instances/my-instance" }
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The unique name of the instance for which the list of logical views is requested. Values are of the form `projects/{project}/instances/{instance}`. | |
| pageSize | No | Optional. The maximum number of logical views to return. The service may return fewer than this value | |
| pageToken | No | Optional. A page token, received from a previous `ListLogicalViews` call. Provide this to retrieve the subsequent page. When paginating, all other parameters provided to `ListLogicalViews` must match the call that provided the page token. |
Output Schema
| Name | Required | Description |
|---|---|---|
| logicalViews | No | The logical views in the instance. |
| 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?
Annotations already provide readOnly and non-destructive hints. Description adds the 'list all' scope and parent requirement, but no additional behavioral details like pagination behavior or rate limits.
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?
Two concise sentences, front-loaded with the action, no redundant 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 the presence of an output schema, the description covers the key aspect (parent requirement). It could mention pagination, but the schema already handles that. Overall sufficient for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the parent format with a concrete example, going beyond the schema's 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 it lists logical views within an instance, specifying the required parent parameter format. It distinguishes from siblings like create_logical_view and get_logical_view.
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?
Provides clear context on the required parent field and example, but does not explicitly differentiate from get_logical_view or state when to use list vs. other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tablesARead-onlyInspect
List all tables in a specified instance. The request requires the 'parent' field to be set in the format 'projects/{project}/instances/{instance}'. Example: { "parent": "projects/my-project/instances/my-instance" }
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | The view to be applied to the returned tables' fields. Only NAME_ONLY view (default), REPLICATION_VIEW and ENCRYPTION_VIEW are supported. | |
| parent | Yes | Required. The unique name of the instance for which tables should be listed. Values are of the form `projects/{project}/instances/{instance}`. | |
| pageSize | No | Maximum number of results per page. A page_size of zero lets the server choose the number of items to return. A page_size which is strictly positive will return at most that many items. A negative page_size will cause an error. Following the first request, subsequent paginated calls are not required to pass a page_size. If a page_size is set in subsequent calls, it must match the page_size given in the first request. | |
| pageToken | No | The value of `next_page_token` returned by a previous call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tables | No | The tables present in the requested instance. |
| nextPageToken | No | Set if not all tables could be returned in a single response. Pass this value to `page_token` in another request to get the next page of results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. Annotations indicate read-only, open-world, and non-destructive operations, but the description clarifies that the request requires a specific 'parent' field format and provides an example. This enhances the agent's understanding of how to properly invoke the tool, though it doesn't mention pagination behavior or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. It uses only three sentences: one stating the purpose, one specifying the required parameter format, and one providing an example. Every sentence adds essential information with zero wasted words, 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 moderate complexity (4 parameters, 1 required), rich annotations, 100% schema coverage, and presence of an output schema, the description is reasonably complete. It covers the core purpose and key invocation requirement. The main gap is lack of usage guidance relative to sibling tools, but otherwise it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds minimal value by emphasizing the required 'parent' field format and providing an example, but doesn't explain parameter interactions or usage beyond what's in the 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 tool's purpose: 'List all tables in a specified instance.' It provides a specific verb ('List') and resource ('tables'), but doesn't explicitly differentiate it from sibling tools like 'list_instances' or 'get_table'. The purpose is unambiguous but lacks sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_instances' (for listing instances instead of tables) or 'get_table' (for retrieving a single table). There's no context about prerequisites or when this tool is appropriate versus other listing or retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_logical_viewAIdempotentInspect
Updates a Bigtable logical view within a specified instance. You can update the GoogleSQL query and/or the deletion protection setting.
At least one field to update (e.g., query or deletion_protection) must be provided in logical_view field.
Update query example: { "project_id": "my-project", "instance_id": "my-instance", "logical_view_id": "my-logical-view", logical_view: { "query": "SELECT CF FROM my-table" } }
Update deletion protection example: { "project_id": "my-project", "instance_id": "my-instance", "logical_view_id": "my-logical-view", logical_view: { "deletion_protection": true } }
Update query and deletion protection example: { "project_id": "my-project", "instance_id": "my-instance", "logical_view_id": "my-logical-view", logical_view: { "query": "SELECT CF FROM my-table", "deletion_protection": true } }
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | Required. The project ID (e.g., "my-project"). If not known from the context, the Agent should attempt to get the current project ID from the gcloud config by running `gcloud config get-value project`. If the attempt fails, prompt the user for the project ID. | |
| instanceId | Yes | Required. The instance ID within the project where the logical view will be created (e.g., "my-instance"). | |
| logicalView | Yes | Required. The logical view to update. | |
| logicalViewId | Yes | Required. The ID used for the logical view within its instance, e.g., `mylogicalview`. |
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 idempotent and non-destructive write behavior. The description adds context about which specific fields can be updated (query and deletion protection), providing useful detail beyond what annotations offer. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and field details, followed by examples. It is clear and well-structured, though the examples add length. Every sentence contributes value.
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 4 required parameters and existing output schema, the description sufficiently covers what the tool does and how to use it. It includes examples and the condition that at least one field must be provided, making it comprehensive for a straightforward update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all parameters. The description adds examples of how to structure the logicalView parameter, but does not provide additional semantic meaning beyond what the schema already conveys.
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 'Updates' and the resource 'Bigtable logical view', and specifies that it updates query and/or deletion protection. This distinguishes it from siblings like create_logical_view and delete_logical_view.
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 gives usage constraints (at least one field must be provided) but does not explicitly state when to use this tool over alternatives like create_logical_view or get_logical_view. It implies the logical view already exists, but does not mention prerequisites.
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!