Interact with your Google Cloud Datastream resources using natural language commands.
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.
Average 4.2/5 across 10 of 10 tools scored. Lowest: 3.5/5.
Tools are mostly distinct, targeting different resource types like streams, stream objects, connection profiles, and static IPs. The only potential ambiguity is between get_stream_object and lookup_stream_object, but descriptions clarify that one uses a resource name and the other uses a source object identifier.
All tool names consistently follow a verb_noun snake_case pattern (delete_stream, get_stream, list_streams, run_stream), making their usage predictable and easy to learn.
With 10 tools, the server is well-scoped for managing stream resources and metadata. Each tool has a clear purpose, and none feel redundant or unnecessary.
The set covers read operations, deletion, and starting streams, but lacks create/update operations for streams and connection profiles, which may require external tooling or manual intervention. This leaves some lifecycle gaps for agents.
delete_streamADeletes a stream, specified by the provided resource 'name' parameter.
The resource 'name' parameter is in the form: 'projects/{project name}/locations/{location}/streams/{stream name}', for example: 'projects/my-project/locations/us-central1/streams/my-streams'.
This tool returns a long-running operation. Use the 'get_operation' tool with the returned operation name to poll its status until it completes. Operation may take several minutes; do not check more often than every ten seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The name of the stream resource to delete. | |
| requestId | No | Optional. A 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). |
| 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`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive, and the description adds meaningful context: it returns a long-running operation and advises polling no more often than every ten seconds. This clarifies expected behavior beyond what annotations convey, though it does not discuss irreversibility or permission requirements.
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 and front-loaded with the primary action, followed by the resource format and operation handling guidance. Every sentence provides useful information without redundancy or filler.
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 destructiveHint set, an output schema present, and a detailed input schema, the description covers the key operational aspects: resource identification via name pattern, long-running operation behavior, and polling frequency. No critical gaps are evident for a deletion 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?
The schema has 100% coverage, so the baseline is 3, but the description adds value by providing a concrete name pattern and example for the 'name' parameter (projects/{project}/locations/{location}/streams/{stream}). This helps the agent construct valid input beyond the schema's basic 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 opens with 'Deletes a stream,' a specific verb and resource, and clarifies it operates on the provided resource 'name' parameter. This clearly distinguishes it from sibling tools like get_stream, list_streams, and run_stream.
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 clear context by explaining the resource name format and instructing to poll status via get_operation after deletion. It does not explicitly state when not to use the tool or mention alternatives, but for a deletion tool in this sibling set, the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_operationAGets the status of a long-running operation.
Usage
Some tools (for example, run_stream) return a long-running operation.
You can use this tool to get the status of the operation. It can be called repeatedly until
the operation is complete.
Parameters
name: The name of the operation to get.
name should be the name returned by the tool that initiated the operation.
name should be in the format of:
projects/{project}/locations/{location}/operations/{operation}.
Returns
An Operation object that contains the status of the operation.
If the operation is not complete, the response will be empty. Do not check more than every ten seconds.
If the operation is complete, the response will contain either:
A response field that contains the result of the operation and indicates that it was
successful.
A error field that indicates any errors that occurred during the operation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of the operation resource. |
| 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`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, idempotentHint=true), it adds meaningful behavioral details: the response is empty while incomplete, polling should not exceed every ten seconds, and completion returns either a response or error field. This gives the agent a clear model of the tool's behavior.
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 with separate Usage, Parameters, and Returns sections. Each sentence is informative and necessary, with no fluff or repetition. It is appropriately sized for the tool's simplicity.
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 one-parameter tool, annotations, and output schema, the description is remarkably complete. It covers usage, parameter format, return behavior, and polling guidance, leaving virtually no ambiguity for 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?
The schema only says 'The name of the operation resource.' The description adds crucial semantics: the name must be the one returned by the initiating tool and must follow the format projects/{project}/locations/{location}/operations/{operation}. This goes beyond the schema's minimal 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 'Gets the status of a long-running operation,' using a specific verb and resource. It distinguishes itself from siblings like get_stream by focusing on operations rather than streams.
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?
It explicitly explains when to use the tool: after a long-running operation is initiated by tools like run_stream. It also notes that it can be called repeatedly until completion, providing clear usage context and an example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_streamAGet details of the stream specified by the provided resource 'name' parameter.
The resource 'name' parameter is in the form: 'projects/{project name}/locations/{location}/streams/{stream name}', for example: 'projects/my-project/locations/us-central1/streams/my-streams'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The name of the stream resource to get. |
| Name | Required | Description |
|---|---|---|
| name | No | Output only. Identifier. The stream's name. |
| state | No | The state of the stream. |
| errors | No | Output only. Errors on the Stream. |
| labels | No | Labels. |
| ruleSets | No | Optional. Rule sets to apply to the stream. |
| createTime | No | Output only. The creation time of the stream. |
| updateTime | No | Output only. The last update time of the stream. |
| backfillAll | No | Automatically backfill objects included in the stream source configuration. Specific objects can be excluded. |
| displayName | No | Required. Display name. |
| backfillNone | No | Do not automatically backfill any objects. |
| satisfiesPzi | No | Output only. Reserved for future use. |
| satisfiesPzs | No | Output only. Reserved for future use. |
| sourceConfig | No | Required. Source connection profile configuration. |
| lastRecoveryTime | No | Output only. If the stream was recovered, the time of the last recovery. Note: This field is currently experimental. |
| destinationConfig | No | Required. Destination connection profile configuration. |
| customerManagedEncryptionKey | No | Immutable. A reference to a KMS encryption key. If provided, it will be used to encrypt the data. If left blank, data will be encrypted using an internal Stream-specific encryption key provisioned through KMS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the resource name format, which is more parameter semantics than behavioral disclosure. It does not describe error behavior, return format (though output schema exists), or other runtime traits, but with annotations present, the added context is sufficient for a basic get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence states the action and resource, the second provides the critical parameter format and example. Every phrase earns its place, making it clear and efficient.
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?
The tool is simple: a single required parameter, read-only, with an output schema and annotations covering safety. The description provides the necessary parameter format and context. While it does not explicitly discuss error handling or usage alternatives, the low complexity and rich structured metadata make the description sufficiently complete for an agent to select and invoke 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?
The schema describes 'name' simply as 'The name of the stream resource to get.' The tool description adds substantial meaning by providing the exact resource name format ('projects/{project name}/locations/{location}/streams/{stream name}') and an example ('projects/my-project/locations/us-central1/streams/my-streams'). This goes beyond the schema's brief description and helps the agent construct valid parameter values.
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 action: 'Get details of the stream specified by the provided resource name parameter.' It identifies the specific resource type (stream) and differentiates from siblings like get_stream_object and list_streams by focusing on a single stream's details. The verb and resource are specific 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 implies usage by specifying that it gets details for a given stream name, but it does not explicitly state when to use this tool over alternatives like list_streams or get_stream_object. There is no mention of exclusions or alternative tools, leaving the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stream_objectAGet details of the stream object specified by the provided resource 'name' parameter.
The resource 'name' parameter is in the form: 'projects/{project name}/locations/{location}/streams/{stream name}/objects/{stream object name}', for example: 'projects/my-project/locations/us-central1/streams/my-stream/objects/my-stream-object'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The name of the stream object resource to get. |
| Name | Required | Description |
|---|---|---|
| name | No | Output only. Identifier. The object resource's name. |
| errors | No | Output only. Active errors on the object. |
| createTime | No | Output only. The creation time of the object. |
| updateTime | No | Output only. The last update time of the object. |
| backfillJob | No | The latest backfill job that was initiated for the stream object. |
| displayName | No | Required. Display name. |
| sourceObject | No | The object identifier in the data source. |
| customizationRules | No | Output only. The customization rules for the object. These rules are derived from the parent Stream's `rule_sets` and represent the intended configuration for the object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the resource name format but does not disclose other behavioral traits like not-found behavior or response details; no contradiction with 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 compact and front-loaded with the purpose, followed by the necessary name format example. Every sentence contributes useful information with no filler.
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 simple single-parameter read operation with an output schema and rich annotations, the description covers the critical name formatting requirement. It does not explain when to choose this over sibling tools, but the provided format is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description is minimal ('The name of the stream object resource to get'), but the description provides a full resource path pattern with placeholders and a concrete example. This significantly enriches understanding of the single 'name' parameter.
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 a specific action ('Get details') and resource ('stream object') with an explicit resource name format. It does not explicitly distinguish from sibling tools like lookup_stream_object or get_stream, but the tool name and resource scope make the purpose clear.
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?
There is no guidance on when to use this tool versus alternatives such as lookup_stream_object or list_stream_objects. Usage is only implied: fetch a single stream object by its resource name. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_connection_profilesALists connection profiles in a given project and location.
For example:
{
parent: "projects/my-project/locations/us-central1"
create_time_after: 2025-10-02T10:15:33Z
create_time_before: 2025-10-03T00:00:00Z
display_name: bookstore
page_size: 100
}
will return up to 100 connection profiles in projects/my-project/locations/us-central1
that were created on or after 2025-10-02T10:15:33 UTC and before 2025-10-03T00:00:00 UTC,
and have "bookstore" in their display name.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The parent that owns the collection of connection profiles. Must be in the format `projects/*/locations/*`. For example: 'projects/my-project/locations/us-central1' | |
| pageSize | No | Optional. Use to limit the number of connection profiles returned. Valid values are between 1 and 1000 inclusive. Defaults to 1000 if not provided or outside of the valid range. Note that due to filtering, it is possible to get no results (but a next_page_token) so you should keep calling this method until you get a response with an empty next_page_token. | |
| pageToken | No | Optional. A page token, received from a previous `list_connection_profiles` call. Provide this to retrieve the subsequent page. When paginating, all other parameters provided to `list_connection_profiles` must match the call that provided the page token. | |
| displayName | No | Optional. Use to get connection profiles whose display name contains the provided name. | |
| createTimeAfter | No | Optional. Use to get connection profiles that were created on or after the provided date/time, formatted as RFC-3339. Common Examples: 2023-09-24T15:30:00Z or 2023-09-24T15:30:00.000+09:00. | |
| createTimeBefore | No | Optional. Use to get connection profiles that were created before the provided date/time, formatted as RFC-3339. Common Examples: 2023-09-24T15:30:00Z or 2023-09-24T15:30:00.000+09:00. |
| Name | Required | Description |
|---|---|---|
| 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. |
| connectionProfiles | No | List of connection profiles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds a concrete example that clarifies the combined filtering behavior on create_time and display_name, adding value beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with a clear purpose sentence followed by a detailed example. The example is somewhat lengthy but earns its place by illustrating parameter usage, making the description effective without being wasteful.
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 rich input schema, output schema, and clear annotations, the description is quite complete. The example aids understanding, though it could mention pagination or alternatives, but those are already covered by the schema and sibling context, respectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for all parameters (100% coverage), so the baseline is 3. The description's example uses snake_case names (e.g., page_size) that mismatch the schema's camelCase (pageSize), which could cause minor confusion, but it does not add substantial new meaning 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 that the tool lists connection profiles in a project and location, which is a specific verb+resource. However, it does not distinguish this from sibling list tools like list_streams or list_static_ips, so it 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 example implies usage with filters, but there is no explicit guidance on when to use this tool over alternatives, nor any exclusions or prerequisite conditions. The context is clear but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_static_ipsALists static IP addresses of the provided resource name that need to be allowlisted by the customer when using the static-IP connectivity method. Returns up to 100 IP addresses.
The resource 'name' parameter is in the form 'projects/{project name}/locations/{location}', for example: 'projects/my-project/locations/us-central1'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The resource name for the location for which static IPs should be returned. Must be in the format `projects/*/locations/*`. For example: 'projects/my-project/locations/us-central1' |
| Name | Required | Description |
|---|---|---|
| staticIps | No | list of static ips by account |
| nextPageToken | No | A token that can be sent as `page_token` to retrieve the next page. If this field is omitted, there are no subsequent pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the 100-IP limit and the required resource name format, which are useful behavioral details beyond the annotations. No contradiction found.
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 two concise sentences plus a helpful example bullet. It is front-loaded with the core purpose and includes no filler, earning every sentence.
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 tool with one simple parameter and an output schema, the description covers the essential context: what it does, why it is used, the return limit, and the required input format. Annotations cover the safety profile, so the description is complete.
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 coverage is 100%, and the schema already fully describes the 'name' parameter including format and example. The description repeats this information without adding new semantic details, so the baseline of 3 applies.
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 uses a specific verb ('Lists') and a clear resource ('static IP addresses of the provided resource name'), and it explains the purpose (allowlisting for static-IP connectivity). This clearly distinguishes it from sibling tools, none of which deal with static IPs.
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?
It provides clear context on when to use the tool: when the customer needs to allowlist static IPs for the static-IP connectivity method. It does not explicitly name alternative tools or define exclusions, but the context is sufficient to guide selection among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_stream_objectsALists stream objects in a given stream.
Parent parameter is in the form 'projects/{project name}/locations/{location}/streams/{stream name}', for example: 'projects/my-project/locations/us-central1/streams/my-stream'.
Not all the details of the stream objects are returned.
To get the full details of a specific stream object, use the 'get_stream_object' tool.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The parent stream that owns the collection of objects. | |
| pageSize | No | Optional. Maximum number of objects to return. Default is 50. The maximum value is 1000; values above 1000 will be coerced to 1000. | |
| pageToken | No | Optional. Page token received from a previous `ListStreamObjectsRequest` call. Provide this to retrieve the subsequent page. When paginating, all other parameters provided to `ListStreamObjectsRequest` must match the call that provided the page token. |
| Name | Required | Description |
|---|---|---|
| nextPageToken | No | A token, which can be sent as `page_token` to retrieve the next page. |
| streamObjects | No | List of stream objects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations by stating that 'Not all the details of the stream objects are returned,' which informs the agent about partial data before invocation.
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 the main purpose in the first sentence and three bullet points that each earn their place: parent format, partial-detail caveat, and pointer to the sibling tool. No redundant or vague language exists.
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 has a clear list operation, comprehensive annotations, and a full input schema (with output schema indicated), the description is complete enough. It covers the essential operational detail (partial results) and points to the alternative for full details, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all three parameters. The description adds extra meaning for the 'parent' parameter by providing a concrete format example ('projects/{project}/locations/{location}/streams/{stream}'), which is not present in the schema and aids correct construction.
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 opens with a clear verb and resource: 'Lists stream objects in a given stream.' It also specifies the exact parent format and explicitly contrasts with the sibling tool 'get_stream_object' for full details, making the purpose unambiguous and differentiated.
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 clear guidance on when to use this tool versus the alternative: 'To get the full details of a specific stream object, use the 'get_stream_object' tool.' This explicit referral helps an agent choose the right tool based on whether list-level or full-detail information is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_streamsALists streams in a given project and location.
For example:
{
parent: "projects/my-project/locations/us-central1"
create_time_after: 2025-10-02T10:15:33Z
create_time_before: 2025-10-03T00:00:00Z
display_name: bookstore
page_size: 100
running: true
}
will return up to 100 running streams in projects/my-project/locations/us-central1 that
were created on or after 2025-10-02T10:15:33 UTC and before 2025-10-03T00:00:00 UTC,
and have "bookstore" in their display name.
| Name | Required | Description | Default |
|---|---|---|---|
| failed | No | Optional. Use to get streams that are currently in state FAILED or FAILED_PERMANENTLY. | |
| parent | Yes | Required. The parent that owns the collection of streams. Must be in the format `projects/*/locations/*`. For example: 'projects/my-project/locations/us-central1' | |
| running | No | Optional. Use to get streams that are currently in state RUNNING. | |
| pageSize | No | Optional. Use to limit the number of streams returned. Valid values are between 1 and 1000 inclusive. Defaults to 1000 if not provided or outside of the valid range. Note that due to filtering, it is possible to get no results (but a next_page_token) so you should keep calling this method until you get a response with an empty next_page_token. | |
| pageToken | No | Optional. A page token, received from a previous `list_streams` call. Provide this to retrieve the subsequent page. When paginating, all other parameters provided to `list_streams` must match the call that provided the page token. | |
| displayName | No | Optional. Use to get streams whose display name contains the provided name. | |
| createTimeAfter | No | Optional. Use to get streams that were created on or after the provided date/time, formatted as RFC-3339. Common Examples: 2023-09-24T15:30:00Z or 2023-09-24T15:30:00.000+09:00. | |
| createTimeBefore | No | Optional. Use to get streams that were created before the provided date/time, formatted as RFC-3339. Common Examples: 2023-09-24T15:30:00Z or 2023-09-24T15:30:00.000+09:00. |
| Name | Required | Description |
|---|---|---|
| streams | No | List of streams |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds filter semantics (create_time_after, display_name, running) and an example, but does not disclose auth, rate limits, pagination, or output details. There is no contradiction with annotations, though the example uses 'page_size' whereas the schema specifies 'pageSize', which is a minor transparency inconsistency.
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 compact: one clear sentence followed by an illustrative JSON example. It is front-loaded with the core purpose and the example helps demonstrate usage, though the page_size vs pageSize mismatch slightly detracts from precision.
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 rich schema (8 parameters, all described) and presence of an output schema, the description is largely complete. It provides a concrete example and clarifies filter behavior. It could mention pagination behavior or explicit references to sibling tools, but the schema already covers pagination via pageSize/pageToken, so the tool is sufficiently described.
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 baseline is 3. The description's example demonstrates parameter usage but does not add meaning beyond the schema's individual parameter descriptions. However, the casing mismatch between the example (page_size) and schema (pageSize) could confuse an agent about the exact parameter name.
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 opens with 'Lists streams in a given project and location.', a specific verb+resource+scope phrase that clearly distinguishes the tool from siblings like get_stream (singular retrieval) and list_stream_objects (objects within streams). The included example reinforces the purpose by showing a valid request.
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 clearly implies this tool is used for listing streams with optional filters within a parent project/location. It does not explicitly state when to use it versus alternatives such as get_stream or list_stream_objects, but the first sentence and example provide clear context, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_stream_objectALookup a stream object by its source object identifier. Parameters:
The 'parent' parameter is the name of the stream in the form: 'projects/{project name}/locations/{location}/streams/{stream name}', for example: 'projects/my-project/locations/us-central1/streams/my-stream'.
The 'source_object_identifier' parameter is the source database object identifier. Different source databases have different identifier formats. Examples:
Oracle, PostgreSQL, SQL Server and Spanner databases the identifier is 'schema' and 'table'.
MySQL databases the identifier is 'database' and 'table'.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The parent stream that owns the collection of objects. | |
| sourceObjectIdentifier | Yes | Required. The source object identifier which maps to the stream object. |
| Name | Required | Description |
|---|---|---|
| name | No | Output only. Identifier. The object resource's name. |
| errors | No | Output only. Active errors on the object. |
| createTime | No | Output only. The creation time of the object. |
| updateTime | No | Output only. The last update time of the object. |
| backfillJob | No | The latest backfill job that was initiated for the stream object. |
| displayName | No | Required. Display name. |
| sourceObject | No | The object identifier in the data source. |
| customizationRules | No | Output only. The customization rules for the object. These rules are derived from the parent Stream's `rule_sets` and represent the intended configuration for the object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, idempotent, and non-destructive, and the description does not contradict these. The description adds useful context about parent path format and identifier structures, but it does not disclose behavioral traits like return format, pagination, or error handling. Since annotations cover the safety profile, this is adequate but not enriched.
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: a concise purpose statement followed by a bulleted parameter list. Each bullet provides concrete formatting guidance without being redundant. It is somewhat lengthy due to examples, but all content is relevant to correct tool invocation.
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?
The tool has two required parameters, one of which is a complex union of seven identifier types. The description adequately explains these formats, and since an output schema exists, the return value is already documented elsewhere. The only slight gap is that it doesn't mention any prerequisite or when this lookup would be preferable to listing, but the parameter coverage is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds significant value beyond the schema by providing the exact format for 'parent' (with an example) and outlining the different identifier formats for various source databases, which helps the agent construct valid parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does a 'lookup' of a 'stream object' by its 'source object identifier', which is a specific verb+resource+identifier combination. However, it does not explicitly distinguish itself from the sibling tool 'get_stream_object', which could also perform a lookup by another key.
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 the tool is intended for looking up a stream object when you have the source object identifier, which is a specific use case. It does not provide explicit when-to-use guidance or mention alternatives, but the parameter examples give context for how the tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_streamAInspectStarts an already created stream, specified by the provided resource 'name' parameter.
Parameters
'name': The resource name of the stream to start.
'name' should be in the format of: 'projects/{project name}/locations/{location}/streams/{stream name}', for example: 'projects/my-project/locations/us-central1/streams/my-streams'.
'force': Whether to run the stream without running prior configuration verification. The default is 'false'.
Returns
This tool returns a long-running operation. Use the 'get_operation' tool with the returned operation name to poll its status until it completes. Operation may take several minutes; do not check more often than every ten seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. Name of the stream resource to start, in the format: projects/{project_id}/locations/{location}/streams/{stream_name} | |
| force | No | Optional. Update the stream without validating it. | |
| cdcStrategy | No | Optional. The CDC strategy of the stream. If not set, the system's default value will be used. |
| 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`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is long-running, may take several minutes, and should not be polled more often than every ten seconds. This adds behavioral context beyond the annotations, which only indicate that the tool is not read-only, not idempotent, and not destructive. No contradiction with 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 well-organized with sections for purpose, parameters, and returns. It is reasonably concise, though it repeats the name format already present in the schema. Every sentence contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential workflow: start a stream, get a long-running operation, poll with get_operation, and respect the polling interval. It lacks specific error handling or prerequisites, but given the tool's simplicity and the existence of an output schema, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions, so the baseline is 3. The description adds value by providing a concrete format example for 'name' and clarifying the default for 'force'. It does not mention 'cdcStrategy', but the schema already explains it sufficiently.
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 'Starts an already created stream', using a specific verb and resource. It distinguishes itself from sibling tools like delete_stream, get_stream, and list_streams by focusing on the start 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 specifies when to use the tool (to start an existing stream) and provides a clear follow-up action: use get_operation to poll the returned long-running operation. It also explains the force parameter's role in skipping configuration verification, giving practical usage context.
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.
No comments yet. Be the first to start the discussion!
