Server Details
Interact with your Google Cloud Datastream 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 4.2/5 across 10 of 10 tools scored. Lowest: 3.5/5.
Tools have distinct purposes, but 'get_stream_object' and 'lookup_stream_object' could be confused; they differ in lookup method (by name vs by source identifier), which is a subtle distinction.
All tools follow a consistent verb_noun pattern in snake_case, e.g., delete_stream, list_connection_profiles, get_operation.
10 tools cover the core operations on streams, stream objects, connection profiles, and static IPs without being excessive or insufficient.
Missing creation and update tools for streams and connection profiles; only list, get, delete, and run are available. Agents cannot create resources, limiting full lifecycle management.
Available Tools
10 toolsdelete_streamADestructiveInspect
Deletes 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). |
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 destructiveHint=true, readOnlyHint=false, openWorldHint=false, and idempotentHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it discloses that the tool returns a long-running operation, requires polling with get_operation, and has timing constraints (minutes to complete, poll every 10 seconds). However, it doesn't mention potential side effects like data loss or dependencies, which could be relevant for a destructive 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 efficiently structured: the first sentence states the purpose, followed by bullet points for parameter format and behavioral details. Every sentence adds value—no redundancy or fluff. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with long-running response), the description is complete: it explains the purpose, parameter format, return behavior (long-running operation), and post-invocation steps (polling with get_operation). With annotations covering safety and an output schema likely detailing the operation response, no critical gaps remain. It effectively complements the structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed documentation for both parameters (name and requestId). The description adds semantic context by explaining the format of the 'name' parameter with a concrete example ('projects/my-project/locations/us-central1/streams/my-streams'), which clarifies usage beyond the schema's generic description. It doesn't add details for requestId, but the schema already covers it thoroughly.
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 ('Deletes a stream') and resource ('a stream, specified by the provided resource 'name' parameter'), distinguishing it from sibling tools like get_stream, list_streams, or run_stream. It provides a concrete example of the resource format, making the purpose unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (to delete a stream) and provides clear guidance on what to do after invocation: 'Use the 'get_operation' tool with the returned operation name to poll its status until it completes.' It also specifies timing constraints ('Operation may take several minutes; do not check more often than every ten seconds'), offering comprehensive usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_operationARead-onlyIdempotentInspect
Gets 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.nameshould be the name returned by the tool that initiated the operation.nameshould be in the format of:projects/{project}/locations/{location}/operations/{operation}.
Returns
An
Operationobject 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
responsefield that contains the result of the operation and indicates that it was successful.A
errorfield that indicates any errors that occurred during the operation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of the operation resource. |
Output Schema
| Name | Required | Description |
|---|---|---|
| done | No | If the value is `false`, it means the operation is still in progress. If `true`, the operation is completed, and either `error` or `response` is available. |
| name | No | The server-assigned name, which is only unique within the same service that originally returns it. If you use the default HTTP mapping, the `name` should be a resource name ending with `operations/{unique_id}`. |
| error | No | The error result of the operation in case of failure or cancellation. |
| metadata | No | Service-specific metadata associated with the operation. It typically contains progress information and common metadata such as create time. Some services might not provide such metadata. Any method that returns a long-running operation should document the metadata type, if any. |
| response | No | The normal, successful response of the operation. If the original method returns no data on success, such as `Delete`, the response is `google.protobuf.Empty`. If the original method is standard `Get`/`Create`/`Update`, the response should be the resource. For other methods, the response should have the type `XxxResponse`, where `Xxx` is the original method name. For example, if the original method name is `TakeSnapshot()`, the inferred response type is `TakeSnapshotResponse`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: it explains the polling pattern ('called repeatedly until the operation is complete'), rate limiting guidance ('Do not check more than every ten seconds'), and response structure details for incomplete vs. complete operations. This significantly enhances understanding without contradicting 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-structured with clear sections (Usage, Parameters, Returns) and front-loaded information. Most sentences earn their place by providing essential guidance, though the Returns section could be slightly more concise. Overall, it's appropriately sized and organized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (polling operation status), rich annotations, 100% schema coverage, and the presence of an output schema, the description is complete. It covers purpose, usage context, parameter semantics, behavioral details (polling frequency, response structure), and return value explanations, providing all necessary context for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema: it specifies that the name 'should be the name returned by the tool that initiated the operation' and provides the exact format 'projects/{project}/locations/{location}/operations/{operation}'. This clarifies usage and constraints, elevating the score above baseline.
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 with specific verb+resource ('Gets the status of a long-running operation') and distinguishes it from siblings by explaining it's for checking operations returned by other tools like `run_stream`. This is not a tautology and provides meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('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.') and includes a sibling reference, making it clear when this tool is appropriate versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_streamARead-onlyIdempotentInspect
Get 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the parameter format and example, which provides some contextual transparency but no new behavioral traits beyond what annotations offer.
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 short, with two sentences front-loading the main action and a bullet point for format. Every part is useful and no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and an output schema, the description adequately explains the parameter format and purpose. It lacks usage guidance but is otherwise complete for its complexity level.
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% and the schema describes the parameter as 'Required. The name of the stream resource to get.' The tool description adds meaningful context by specifying the exact resource name format with an example, going 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 'Get details of the stream specified by the provided resource name', which is a specific verb+resource. It distinguishes from siblings like list_streams (which lists) and get_stream_object (which gets stream objects), though it could be more explicit about differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_streams or get_stream_object. It does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stream_objectARead-onlyIdempotentInspect
Get 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the resource name format but no additional behavioral traits. No contradiction.
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 sentences, no fluff. The first sentence clearly states the purpose, and the second provides an actionable example. Properly front-loaded.
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 single-parameter tool with an output schema, the description thoroughly covers the input parameter. No missing context 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?
Schema coverage is 100% with a minimal description. The description adds significant value by specifying the exact resource name pattern and providing a concrete example, which goes beyond the schema's generic 'name of the stream object resource'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('stream object'), and provides a specific name format with an example. It distinguishes itself from siblings like 'list_stream_objects' (listing vs. getting details).
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 vs. alternatives like 'lookup_stream_object' or 'list_stream_objects'. The description implies usage for getting a single object by name, but lacks when-not or alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_connection_profilesARead-onlyIdempotentInspect
Lists 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds context by demonstrating filtering and example usage, though it does not further elaborate on pagination behavior beyond what's in the schema.
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 purpose. The example is helpful but slightly lengthy; however, it does not waste words.
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 and full parameter documentation, the description adequately covers the tool's function. It could mention typical use cases, but the example provides enough context for 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 coverage is 100%, so all parameters are already described. The description provides an example that illustrates parameter usage but does not add new semantic information 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 it lists connection profiles in a given project and location, with a detailed example showing filtering by create time and display name. This distinguishes it from sibling tools like list_streams or list_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?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., list_streams). It does not mention when not to use it or what prerequisites might apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_static_ipsARead-onlyIdempotentInspect
Lists 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' |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive, and idempotent behavior, but the description adds valuable context beyond that: it specifies the return limit ('Returns up to 100 IP addresses') and clarifies the resource format with an example. This enhances understanding of the tool's operational constraints without contradicting 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 efficiently structured in three sentences: purpose, behavioral constraint, and parameter clarification. Each sentence adds value without redundancy, and key information is front-loaded. The bullet point format for the example enhances readability without wasting space.
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 (one parameter), rich annotations (covering safety and idempotency), and the presence of an output schema, the description is complete. It covers purpose, usage context, behavioral limits, and parameter formatting, providing all necessary context for an agent to use it 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 fully documents the 'name' parameter. The description repeats the format example from the schema but doesn't add new semantic meaning beyond what's already in the structured data. 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 specific action ('Lists static IP addresses'), identifies the resource ('of the provided resource name'), and specifies the purpose ('that need to be allowlisted by the customer when using the static-IP connectivity method'). It distinguishes itself from siblings like 'list_streams' or 'list_connection_profiles' by focusing on static IPs for allowlisting.
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 context for when to use this tool: when customers need to allowlist IPs for static-IP connectivity. It doesn't explicitly state when not to use it or name specific alternatives among siblings, but the context is sufficient to understand its application scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_stream_objectsARead-onlyIdempotentInspect
Lists 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only and idempotent hints. The description adds behavioral context: partial results, explicit parent format, and implied pagination support (from schema). This adds value beyond the 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 concise with three sentences, each serving a purpose: action definition, parameter example, clarification of scope. No fluff; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description covers the key behavioral aspects: what is listed, partial details, pagination, and alternative for full details. It is complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds significant value beyond the schema by providing an example of the parent parameter format and specifying the default (50) and maximum (1000) for pageSize. This enriches 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 it lists stream objects in a stream, provides an example of the parent parameter format, and distinguishes from the sibling `get_stream_object` by noting that not all details are returned. This meets the criteria for a specific verb+resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (to list stream objects) and when to use an alternative (`get_stream_object` for full details). It also provides context about partial results, offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_streamsARead-onlyIdempotentInspect
Lists 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true, destructiveHint: false, and idempotentHint: true. The description adds pagination behavior and filtering details but does not contradict annotations. It adds moderate value beyond 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-structured with a clear example, but the example block adds length. Every sentence is informative, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values need no explanation. The description covers all parameters, pagination, and filtering in sufficient detail. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description adds meaning through an example that demonstrates filtering and clarifies pagination behavior (e.g., pageSize default and note on next_page_token). This exceeds schema descriptions alone.
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 'Lists streams in a given project and location.' with a specific verb and resource. It distinguishes from sibling tools like delete_stream, get_stream, etc., which have different purposes.
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 an example suggesting usage for filtered listings but does not explicitly state when to use this tool over alternatives (e.g., get_stream for a single stream). No when-not or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_stream_objectARead-onlyIdempotentInspect
Lookup 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds that it is a lookup operation, but does not disclose additional behavioral traits like error handling, return values, or prerequisites 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 concise and well-structured: purpose first, then parameters with bullet points. Every sentence adds value, no fluff. It is appropriately sized for the complexity of 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?
Given the complexity of multiple source types and the presence of an output schema (not shown), the description adequately covers parameter usage. It misses any discussion of return values or error conditions, but the rules state output schema can carry that burden. Overall, complete enough for the tool's purpose.
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% description coverage, but the description adds significant value by providing real-world examples and formatting rules for different database identifiers (Oracle, MySQL, etc.). This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lookup a stream object by its source object identifier,' which clearly identifies the action, resource, and key. The verb 'lookup' is specific, and it is distinct from siblings like 'get_stream_object' or 'list_stream_objects'.
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 detailed parameter formats and examples, but does not explicitly state when to use this tool versus alternatives (e.g., when to use lookup vs get_stream_object or list_stream_objects). No when-not or alternative tool guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_streamAInspect
Starts 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. |
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 discloses that the tool returns a long-running operation and provides polling instructions. It mentions the operation may take several minutes. Annotations indicate readOnlyHint=false (mutating) and destructiveHint=false. The description adds useful behavioral context beyond annotations, though it could mention that starting an already running stream might fail.
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 short opening sentence, followed by a Parameters section and Returns section. It is concise, using clear headings and bullet points, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, output schema exists, annotations provided), the description covers all necessary aspects: purpose, parameter details with examples, return behavior (long-running operation), and polling guidance. It is complete 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?
Schema coverage is 100% for 3 parameters. The description adds significant value: for 'name', it provides an explicit format and example; for 'force', it explains default false; for 'cdcStrategy', it states 'If not set, the system's default value will be used.' This enriches the schema information.
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 'Starts an already created stream' with the resource name parameter. It distinguishes from sibling tools like get_stream or delete_stream by focusing on the action of starting a 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 provides context for when to use: after stream creation. It also includes guidance on using get_operation for polling status, and advises not to check more often than every ten seconds. While it does not explicitly list when not to use, it gives sufficient context for correct usage.
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!