Server Details
Gain visibility into the performance, availability, and health of your apps and infrastructure.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 9 of 9 tools scored. Lowest: 3.1/5.
Each tool has a clearly distinct purpose with no overlap. The tools are organized around specific resources (alerts, alert policies, dashboards, metrics, timeseries) and actions (get vs list), making it easy for an agent to select the right tool. Even list_metric_descriptors and query_range serve unique discovery and querying functions.
All tools follow a consistent verb_noun naming pattern using snake_case. The verbs 'get' and 'list' are used appropriately for single-item retrieval versus collection listing, and resource names are consistently pluralized where needed. This creates a predictable and readable naming convention throughout.
With 9 tools, this server is well-scoped for Google Cloud Monitoring operations. Each tool serves a clear purpose in the monitoring workflow, from discovery (list_metric_descriptors) to configuration review (list_alert_policies) to data retrieval (list_timeseries, query_range). The count feels complete without being overwhelming.
The tool set provides excellent coverage for monitoring data retrieval and configuration review, but lacks write operations for creating or modifying alerts, policies, or dashboards. While the read-focused tools form a coherent set for monitoring observation, the absence of write capabilities represents a minor gap in full lifecycle management.
Available Tools
9 toolsget_alertARead-onlyIdempotentInspect
Use this as the primary tool to get information about a specific alert. An alert is the representation of a violation of an alert policy. This is useful for understanding the details of a specific alert.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The name of the alert. The format is: projects/[PROJECT_ID_OR_NUMBER]/alerts/[ALERT_ID] The `[ALERT_ID]` is a system-assigned unique identifier for the alert. |
Output Schema
| Name | Required | Description |
|---|---|---|
| log | No | The log information associated with the alert. This field is only populated for log-based alerts. |
| name | No | Identifier. The name of the alert. The format is: projects/[PROJECT_ID_OR_NUMBER]/alerts/[ALERT_ID] The `[ALERT_ID]` is a system-assigned unique identifier for the alert. |
| state | No | Output only. The current state of the alert. |
| metric | No | The metric type and any metric labels preserved from the incident's generating condition. |
| policy | No | The snapshot of the alert policy that generated this alert. |
| metadata | No | The metadata of the monitored resource. |
| openTime | No | The time when the alert was opened. |
| resource | No | The monitored resource type and any monitored resource labels preserved from the incident's generating condition. |
| closeTime | No | The time when the alert was closed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide strong behavioral hints (read-only, non-destructive, idempotent, closed-world). The description adds minimal context beyond this - it doesn't mention authentication needs, rate limits, or what specific details are returned. With comprehensive annotations, the bar is lower, but the description could still add more operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each add value. The first sentence establishes the primary purpose, and the second provides context about what alerts represent and when to use the tool. There's no wasted verbiage, though it could be slightly more structured with clearer separation of purpose versus usage guidance.
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 comprehensive annotations, 100% schema coverage, and an output schema exists (so return values are documented elsewhere), the description provides adequate context. It explains what the tool does and when to use it at a high level. For a simple read operation with good structured documentation, this level of description is reasonably 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?
Schema description coverage is 100% with the single 'name' parameter fully documented in the schema. The description doesn't add any parameter information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'get information about a specific alert' and explains what an alert represents ('violation of an alert policy'). It distinguishes from siblings like 'list_alerts' by specifying retrieval of a single alert. However, it doesn't explicitly contrast with 'get_alert_policy' which retrieves policy details rather than alert instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance: 'Use this as the primary tool to get information about a specific alert' and 'This is useful for understanding the details of a specific alert.' It implies usage when you need details of a known alert versus listing multiple alerts. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'list_alerts' for browsing alerts without specific identifiers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_alert_policyARead-onlyIdempotentInspect
Use this as the primary tool to get information about a specific alerting policy. Alerting policies define the conditions under which you want to be notified about issues with your services. This is useful for understanding the details of a specific alert configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The alerting policy to retrieve. The format is: projects/[PROJECT_ID_OR_NUMBER]/alertPolicies/[ALERT_POLICY_ID] |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | Identifier. Required if the policy exists. The resource name for this policy. The format is: projects/[PROJECT_ID_OR_NUMBER]/alertPolicies/[ALERT_POLICY_ID] `[ALERT_POLICY_ID]` is assigned by Cloud Monitoring when the policy is created. When calling the alertPolicies.create method, do not include the `name` field in the alerting policy passed as part of the request. |
| enabled | No | Whether or not the policy is enabled. On write, the default interpretation if unset is that the policy is enabled. On read, clients should not make any assumption about the state if it has not been populated. The field should always be populated on List and Get operations, unless a field projection has been specified that strips it out. |
| combiner | No | How to combine the results of multiple conditions to determine if an incident should be opened. If `condition_time_series_query_language` is present, this must be `COMBINE_UNSPECIFIED`. |
| severity | No | Optional. The severity of an alerting policy indicates how important incidents generated by that policy are. The severity level will be displayed on the Incident detail page and in notifications. |
| validity | No | Read-only description of how the alerting policy is invalid. This field is only set when the alerting policy is invalid. An invalid alerting policy will not generate incidents. |
| conditions | No | A list of conditions for the policy. The conditions are combined by AND or OR according to the `combiner` field. If the combined conditions evaluate to true, then an incident is created. A policy can have from one to six conditions. If `condition_time_series_query_language` is present, it must be the only `condition`. If `condition_monitoring_query_language` is present, it must be the only `condition`. |
| userLabels | No | User-supplied key/value data to be used for organizing and identifying the `AlertPolicy` objects. The field can contain up to 64 entries. Each key and value is limited to 63 Unicode characters or 128 bytes, whichever is smaller. Labels and values can contain only lowercase letters, numerals, underscores, and dashes. Keys must begin with a letter. Note that Prometheus {alert name} is a [valid Prometheus label names](https://prometheus.io/docs/concepts/data_model/#metric-names-and-labels), whereas Prometheus {rule group} is an unrestricted UTF-8 string. This means that they cannot be stored as-is in user labels, because they may contain characters that are not allowed in user-label values. |
| displayName | No | A short name or phrase used to identify the policy in dashboards, notifications, and incidents. To avoid confusion, don't use the same display name for multiple policies in the same project. The name is limited to 512 Unicode characters. The convention for the display_name of a PrometheusQueryLanguageCondition is "{rule group name}/{alert name}", where the {rule group name} and {alert name} should be taken from the corresponding Prometheus configuration file. This convention is not enforced. In any case the display_name is not a unique key of the AlertPolicy. |
| alertStrategy | No | Control over how this alerting policy's notification channels are notified. |
| documentation | No | Documentation that is included with notifications and incidents related to this policy. Best practice is for the documentation to include information to help responders understand, mitigate, escalate, and correct the underlying problems detected by the alerting policy. Notification channels that have limited capacity might not show this documentation. |
| creationRecord | No | A read-only record of the creation of the alerting policy. If provided in a call to create or update, this field will be ignored. |
| mutationRecord | No | A read-only record of the most recent change to the alerting policy. If provided in a call to create or update, this field will be ignored. |
| notificationChannels | No | Identifies the notification channels to which notifications should be sent when incidents are opened or closed or when new violations occur on an already opened incident. Each element of this array corresponds to the `name` field in each of the `NotificationChannel` objects that are returned from the `ListNotificationChannels` method. The format of the entries in this field is: projects/[PROJECT_ID_OR_NUMBER]/notificationChannels/[CHANNEL_ID] |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds minimal behavioral context beyond this, only noting it's for 'understanding details' without specifying return format, error conditions, or rate limits. Since annotations provide the core behavioral traits, the description adds some value but not rich additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded: the first states the purpose, the second explains alerting policies, and the third provides usage context. There is no wasted text, but it could be slightly more concise by integrating the second sentence more tightly with the first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 required parameter), rich annotations covering safety and idempotency, and the presence of an output schema (which means return values are documented elsewhere), the description is reasonably complete. It covers purpose and basic usage, though it could benefit from more explicit differentiation from sibling tools to be fully comprehensive.
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, with the 'name' parameter fully documented in the schema. The description does not add any parameter-specific information beyond what's in the schema, such as examples or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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: 'to get information about a specific alerting policy' and explains that 'Alerting policies define the conditions under which you want to be notified about issues with your services.' This provides a specific verb ('get information') and resource ('specific alerting policy'), but it doesn't explicitly distinguish this from sibling tools like 'get_alert' or 'list_alert_policies' beyond mentioning '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 provides some implied usage context: 'This is useful for understanding the details of a specific alert configuration' and mentions 'specific alerting policy,' which suggests it's for retrieving individual policies rather than lists. However, it doesn't explicitly state when to use this tool versus alternatives like 'list_alert_policies' or 'get_alert,' nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dashboardARead-onlyIdempotentInspect
Use this as the primary tool to retrieve a single specific custom monitoring dashboard from a Google Cloud project using the resource name of the requested dashboard. Custom monitoring dashboards let users view and analyze data from different sources in the same context. This is often used as a follow on to list_dashboards to get full details on a specific dashboard.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The resource name of the Dashboard. The format is one of: - `dashboards/[DASHBOARD_ID]` (for system dashboards) - `projects/[PROJECT_ID_OR_NUMBER]/dashboards/[DASHBOARD_ID]` (for custom dashboards). |
Output Schema
| Name | Required | Description |
|---|---|---|
| etag | No | `etag` is used for optimistic concurrency control as a way to help prevent simultaneous updates of a policy from overwriting each other. An `etag` is returned in the response to `GetDashboard`, and users are expected to put that etag in the request to `UpdateDashboard` to ensure that their change will be applied to the same version of the Dashboard configuration. The field should not be passed during dashboard creation. |
| name | No | Identifier. The resource name of the dashboard. |
| labels | No | Labels applied to the dashboard |
| rowLayout | No | The content is divided into equally spaced rows and the widgets are arranged horizontally. |
| gridLayout | No | Content is arranged with a basic layout that re-flows a simple list of informational elements like widgets or tiles. |
| annotations | No | Configuration for event annotations to display on this dashboard. |
| displayName | No | Required. The mutable, human-readable name. |
| columnLayout | No | The content is divided into equally spaced columns and the widgets are arranged vertically. |
| mosaicLayout | No | The content is arranged as a grid of tiles, with each content widget occupying one or more grid blocks. |
| dashboardFilters | No | Filters to reduce the amount of data charted based on the filter criteria. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it clarifies that this tool retrieves 'full details' on a dashboard, which implies richer output than a list operation. Annotations already cover read-only, non-destructive, and idempotent behavior, so the description appropriately focuses on usage context rather than repeating those traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence clearly states the tool's purpose and primary use, followed by explanatory context. Every sentence adds value—explaining custom dashboards and sibling relationships—without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), rich annotations (covering safety and idempotency), and the presence of an output schema, the description is complete. It adequately explains the tool's role, usage context, and relationship to siblings, without needing to detail return values or behavioral traits already covered elsewhere.
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 coverage is 100%, so the schema fully documents the single parameter 'name'. The description mentions the parameter generically ('using the resource name') but does not add syntax or format details beyond what the schema provides. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('retrieve a single specific custom monitoring dashboard') and resource ('from a Google Cloud project'), distinguishing it from siblings like list_dashboards by focusing on individual retrieval rather than listing. It explicitly mentions the resource name parameter, reinforcing the specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states this is the 'primary tool' for retrieval, specifies when to use it ('often used as a follow on to list_dashboards to get full details on a specific dashboard'), and distinguishes it from the sibling list_dashboards by clarifying the difference between listing and detailed retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_alert_policiesARead-onlyIdempotentInspect
Use this as the primary tool to list the alerting policies in a Google Cloud project. Alerting policies define the conditions under which you want to be notified about issues with your services. This is useful for understanding what alerts are currently configured.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The [project](https://cloud.google.com/monitoring/api/v3#project_name) whose alert policies are to be listed. The format is: projects/[PROJECT_ID_OR_NUMBER] Note that this field names the parent container in which the alerting policies to be listed are stored. To retrieve a single alerting policy by name, use the GetAlertPolicy operation, instead. | |
| filter | No | Optional. If provided, this field specifies the criteria that must be met by alert policies to be included in the response. For more details, see [sorting and filtering](https://cloud.google.com/monitoring/api/v3/sorting-and-filtering). | |
| orderBy | No | Optional. A comma-separated list of fields by which to sort the result. Supports the same set of field references as the `filter` field. Entries can be prefixed with a minus sign to sort by the field in descending order. For more details, see [sorting and filtering](https://cloud.google.com/monitoring/api/v3/sorting-and-filtering). | |
| pageSize | No | Optional. The maximum number of results to return in a single response. | |
| pageToken | No | Optional. If this field is not empty then it must contain the `nextPageToken` value returned by a previous call to this method. Using this field causes the method to return more results from the previous method call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| totalSize | No | The total number of alert policies in all pages. This number is only an estimate, and may change in subsequent pages. https://aip.dev/158 |
| alertPolicies | No | The returned alert policies. |
| nextPageToken | No | If there might be more results than were returned, then this field is set to a non-empty value. To see the additional results, use that value as `page_token` in the next call to this method. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds useful context about the tool being 'primary' for listing policies and explains what alerting policies are, but doesn't disclose additional behavioral traits like pagination behavior (implied by pageSize/pageToken) or rate limits. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that each serve a purpose: stating the primary use, defining alerting policies, and explaining utility. It's front-loaded with the main purpose. While efficient, it could be slightly more concise by integrating the sibling tool guidance from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, 1 required), rich annotations, 100% schema coverage, and presence of an output schema, the description provides adequate context. It explains the tool's role and value, though it could better integrate guidance on when to use alternatives. The output schema means return values don't need explanation in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with comprehensive parameter documentation in the input schema. The description doesn't add any parameter-specific information beyond what's already in the schema. It mentions the general purpose of listing policies but provides no additional syntax, format, or usage details for parameters. Baseline 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'list the alerting policies in a Google Cloud project' and explains that 'Alerting policies define the conditions under which you want to be notified about issues with your services.' It provides a specific verb ('list') and resource ('alerting policies'), but doesn't explicitly differentiate from sibling tools like 'list_alerts' or 'get_alert_policy'.
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 usage: 'Use this as the primary tool to list the alerting policies' and 'This is useful for understanding what alerts are currently configured.' It mentions an alternative ('To retrieve a single alerting policy by name, use the GetAlertPolicy operation') in the schema description, but this guidance isn't in the main description text itself. No explicit exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_alertsARead-onlyIdempotentInspect
Use this as the primary tool to list the alerts in a Google Cloud project. An alert is the representation of a violation of an alert policy. This is useful for understanding current and past violations of an alert policy.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional. An alert is returned if there is a match on any fields belonging to the alert or its subfields. | |
| parent | Yes | Required. The name of the project to list alerts for. | |
| orderBy | No | Optional. A comma-separated list of fields in `Alert` to use for sorting. The default sort direction is ascending. To specify descending order for a field, add a `desc` modifier. The following fields are supported: * `open_time` * `close_time` For example, `close_time desc, open_time` will return the alerts closed most recently, with ties broken in the order of older alerts listed first. If the field is not set, the results are sorted by `open_time desc`. | |
| pageSize | No | Optional. The maximum number of results to return in a single response. If not set to a positive number, at most 50 alerts will be returned. The maximum value is 1000; values above 1000 will be coerced to 1000. | |
| pageToken | No | Optional. If non-empty, `page_token` must contain a value returned as the `next_page_token` in a previous response to request the next set of results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| alerts | No | The list of alerts. |
| totalSize | No | The estimated total number of matching results for this query. |
| nextPageToken | No | If not empty, indicates that there may be more results that match the request. Use the value in the `page_token` field in a subsequent request to fetch the next set of results. The token is encrypted and only guaranteed to return correct results for 72 hours after it is created. If empty, all results have been returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds minimal behavioral context beyond this - it mentions the tool lists 'current and past violations' which suggests historical data access, but doesn't disclose pagination behavior, rate limits, or authentication requirements. With comprehensive annotations, the bar is lower, and the description adds some value but not rich behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each serve a purpose. The first sentence establishes the primary function, and the second provides domain context about what alerts represent. There's no wasted language, though it could be slightly more front-loaded with sibling differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive annotations (covering safety, idempotency, and world scope), 100% schema description coverage, and the presence of an output schema, the description provides adequate context. It explains the domain concept (alerts as policy violations) and positions the tool as primary for listing. For a read-only listing tool with good structured data, this level of description is reasonably 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?
Schema description coverage is 100%, with all 5 parameters well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'Google Cloud project' which relates to the 'parent' parameter, but this is already clear from the schema. With complete schema coverage, the baseline is 3 even without parameter details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'list the alerts in a Google Cloud project' with the explanation that 'An alert is the representation of a violation of an alert policy.' This provides a specific verb (list) and resource (alerts) with domain context. However, it doesn't explicitly differentiate from sibling tools like 'get_alert' or 'list_alert_policies' beyond mentioning 'primary tool' for listing alerts.
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 some usage context: 'Use this as the primary tool to list the alerts' and mentions it's 'useful for understanding current and past violations.' However, it doesn't explicitly state when to use this versus alternatives like 'get_alert' (for single alert details) or 'list_alert_policies' (for policies rather than violations). The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_dashboardsARead-onlyIdempotentInspect
Use this as the primary tool to retrieve a list of existing custom monitoring dashboards in a Google Cloud project. Custom monitoring dashboards let users view and analyze data from different sources in the same context. This is useful for understanding what custom dashboards are currently configured and available in a given project.
| Name | Required | Description | Default |
|---|---|---|---|
| parent | Yes | Required. The scope of the dashboards to list. The format is: projects/[PROJECT_ID_OR_NUMBER] | |
| pageSize | No | A positive number that is the maximum number of results to return. If unspecified, a default of 1000 is used. | |
| pageToken | No | Optional. If this field is not empty then it must contain the `nextPageToken` value returned by a previous call to this method. Using this field causes the method to return additional results from the previous method call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| dashboards | No | The list of requested dashboards. |
| nextPageToken | No | If there are more results than have been returned, then this field is set to a non-empty value. To see the additional results, use that value as `page_token` in the next call to this method. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide strong behavioral hints (read-only, non-destructive, idempotent, closed-world). The description adds useful context about the tool being 'primary' for listing dashboards and explains what custom dashboards are, but doesn't disclose additional behavioral traits like pagination details, rate limits, or authentication requirements beyond what annotations cover. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that each serve a purpose: stating the tool's primary use, explaining what custom dashboards are, and highlighting its utility. It's front-loaded with the core function. While efficient, the second sentence about dashboards could be slightly trimmed for tighter focus on the tool itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations (covering safety and behavior), 100% schema coverage, and the presence of an output schema, the description is complete enough. It clearly defines the tool's role, resource, and context without needing to explain parameters or return values, which are handled by structured fields. No significant gaps remain for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining 'parent' format or pagination behavior. However, the baseline of 3 is appropriate since the schema carries the full burden of parameter documentation effectively.
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 ('retrieve a list'), resource ('existing custom monitoring dashboards'), and scope ('in a Google Cloud project'). It distinguishes this tool from siblings like 'get_dashboard' (singular retrieval) and 'list_metric_descriptors' (different resource type) by explicitly naming the resource and context.
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 ('as the primary tool to retrieve a list of existing custom monitoring dashboards') and explains its utility ('useful for understanding what custom dashboards are currently configured'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the distinction is implied through resource specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_metric_descriptorsARead-onlyIdempotentInspect
Use this as the primary tool to discover the types of metrics available in a Google Cloud project. This is a good first step to understanding what data is available for monitoring and building dashboards or alerts.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The [project](https://cloud.google.com/monitoring/api/v3#project_name) on which to execute the request. The format is: projects/[PROJECT_ID_OR_NUMBER] | |
| filter | No | Optional. If this field is empty, all custom and system-defined metric descriptors are returned. Otherwise, the [filter](https://cloud.google.com/monitoring/api/v3/filters) specifies which metric descriptors are to be returned. For example, the following filter matches all [custom metrics](https://cloud.google.com/monitoring/custom-metrics): metric.type = starts_with("custom.googleapis.com/") | |
| pageSize | No | Optional. A positive number that is the maximum number of results to return. The default and maximum value is 10,000. If a page_size <= 0 or > 10,000 is submitted, will instead return a maximum of 10,000 results. | |
| pageToken | No | Optional. If this field is not empty then it must contain the `nextPageToken` value returned by a previous call to this method. Using this field causes the method to return additional results from the previous method call. | |
| activeOnly | No | Optional. If true, only metrics and monitored resource types that have recent data (within roughly 25 hours) will be included in the response. - If a metric descriptor enumerates monitored resource types, only the monitored resource types for which the metric type has recent data will be included in the returned metric descriptor, and if none of them have recent data, the metric descriptor will not be returned. - If a metric descriptor does not enumerate the compatible monitored resource types, it will be returned only if the metric type has recent data for some monitored resource type. The returned descriptor will not enumerate any monitored resource types. |
Output Schema
| Name | Required | Description |
|---|---|---|
| nextPageToken | No | If there are more results than have been returned, then this field is set to a non-empty value. To see the additional results, use that value as `page_token` in the next call to this method. |
| metricDescriptors | No | The metric descriptors that are available to the project and that match the value of `filter`, if present. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-destructive, idempotent operation with a closed world. The description adds value by framing it as a discovery tool for metric types, which helps the agent understand its exploratory nature. However, it doesn't provide additional behavioral details like pagination handling or rate limits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences. The first sentence states the primary purpose, and the second explains its role as a first step. Every sentence adds value without redundancy, making it efficient and 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?
Given the tool's moderate complexity (5 parameters, 1 required), rich annotations, and the presence of an output schema, the description is reasonably complete. It effectively communicates the tool's role in metric discovery. However, it could be slightly more comprehensive by hinting at output structure or linking to sibling tools for deeper context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining the 'name' parameter's project format or 'filter' usage. Baseline 3 is appropriate since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'discover the types of metrics available in a Google Cloud project' and mentions it's for 'monitoring and building dashboards or alerts.' It specifies the verb ('discover') and resource ('metric types'), but doesn't explicitly differentiate from sibling tools like list_timeseries or list_dashboards, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'primary tool to discover metric types' and 'good first step to understanding what data is available.' It implies when to use it (initial exploration) but doesn't explicitly state when not to use it or name alternatives among siblings, such as list_timeseries for actual data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_timeseriesBRead-onlyIdempotentInspect
Lists time series data from the Google Cloud Monitoring API
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The [project](https://cloud.google.com/monitoring/api/v3#project_name), organization or folder on which to execute the request. The format is: projects/[PROJECT_ID_OR_NUMBER] organizations/[ORGANIZATION_ID] folders/[FOLDER_ID] | |
| view | Yes | Required. Specifies which information is returned about the time series. | |
| filter | Yes | Required. A [monitoring filter](https://cloud.google.com/monitoring/api/v3/filters) that specifies which time series should be returned. The filter must specify a single metric type, and can additionally specify metric labels and other information. For example: metric.type = "compute.googleapis.com/instance/cpu/usage_time" AND metric.labels.instance_name = "my-instance-name" | |
| orderBy | No | Unsupported: must be left blank. The points in each time series are currently returned in reverse time order (most recent to oldest). | |
| interval | Yes | Required. The time interval for which results should be returned. Only time series that contain data points in the specified interval are included in the response. | |
| pageSize | No | A positive number that is the maximum number of results to return. If `page_size` is empty or more than 100,000 results, the effective `page_size` is 100,000 results. If `view` is set to `FULL`, this is the maximum number of `Points` returned. If `view` is set to `HEADERS`, this is the maximum number of `TimeSeries` returned. | |
| pageToken | No | If this field is not empty then it must contain the `nextPageToken` value returned by a previous call to this method. Using this field causes the method to return additional results from the previous method call. | |
| aggregation | No | Specifies the alignment of data points in individual time series as well as how to combine the retrieved time series across specified labels. By default (if no `aggregation` is explicitly specified), the raw time series data is returned. | |
| secondaryAggregation | No | Apply a second aggregation after `aggregation` is applied. May only be specified if `aggregation` is specified. |
Output Schema
| Name | Required | Description |
|---|---|---|
| unit | No | The unit in which all `time_series` point values are reported. `unit` follows the UCUM format for units as seen in https://unitsofmeasure.org/ucum.html. If different `time_series` have different units (for example, because they come from different metric types, or a unit is absent), then `unit` will be "{not_a_unit}". |
| timeSeries | No | One or more time series that match the filter included in the request. |
| unreachable | No | Cloud regions that were unreachable which may have caused incomplete data to be returned. |
| nextPageToken | No | If there are more results than have been returned, then this field is set to a non-empty value. To see the additional results, use that value as `page_token` in the next call to this method. |
| executionErrors | No | Query execution errors that may have caused the time series data returned to be incomplete. |
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, so the bar is lower. The description adds no additional behavioral context (e.g., rate limits, authentication needs, or data retention constraints). It neither contradicts nor enriches 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 a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema with 100% coverage, rich annotations, and an output schema (implied by 'Has output schema: true'), the description is reasonably complete. However, it could better address the tool's role relative to siblings or high-level use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline but not providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Lists time series data from the Google Cloud Monitoring API', which provides a clear verb ('Lists') and resource ('time series data'). However, it lacks specificity about scope or differentiation from sibling tools like 'query_range' or 'list_metric_descriptors', making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'query_range' or 'list_metric_descriptors'. The description does not mention prerequisites, context, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_rangeBRead-onlyIdempotentInspect
Evaluate a PromQL query in a range of time
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | The end time to evaluate the query for. Either floating point UNIX seconds or RFC3339 formatted timestamp. | |
| name | Yes | Required. The project on which to execute the request. Data associcated with the project's workspace stored under the The format is: projects/[PROJECT_ID_OR_NUMBER]. Open source API but used as a request path prefix to distinguish different virtual Prometheus instances of Google Prometheus Engine. | |
| step | No | The resolution of query result. Either a Prometheus duration string (https://prometheus.io/docs/prometheus/latest/querying/basics/#time-durations) or floating point seconds. This non-standard encoding must be used for compatibility with the open source API. Clients may still implement timeouts at the connection level while ignoring this field. | |
| query | No | A PromQL query string. Query language documentation: https://prometheus.io/docs/prometheus/latest/querying/basics/. | |
| start | No | The start time to evaluate the query for. Either floating point UNIX seconds or RFC3339 formatted timestamp. | |
| timeout | No | An upper bound timeout for the query. Either a Prometheus duration string (https://prometheus.io/docs/prometheus/latest/querying/basics/#time-durations) or floating point seconds. This non-standard encoding must be used for compatibility with the open source API. Clients may still implement timeouts at the connection level while ignoring this field. | |
| location | No | Location of the resource information. Has to be "global" now. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | The Prometheus API response payload. Typically present when status is 'success'. |
| error | No | The error message. Present when status is 'error'. |
| status | Yes | Indicates if the API call was successful or resulted in an error. |
| warnings | No | A list of warnings that occurred while processing the request. |
| errorType | No | The type of error (e.g., 'bad_data', 'timeout'). Present when status is 'error'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover key traits (read-only, non-destructive, idempotent), so the description doesn't need to repeat these. It adds some value by specifying the query type ('PromQL') and time range context, but doesn't elaborate on behavioral aspects like rate limits, authentication needs, or error handling, resulting in a baseline score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, PromQL evaluation), annotations provide safety context, and an output schema exists, the description is reasonably complete. However, it could better address usage context or output expectations to fully guide the agent, slightly limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema thoroughly documents all 7 parameters. The description doesn't add meaningful semantic details beyond implying time-range evaluation, so it meets the baseline without compensating for gaps, as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Evaluate') and resource ('a PromQL query in a range of time'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from potential siblings like 'list_timeseries' or 'list_metric_descriptors' that might also retrieve time-series data, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like analyzing historical metrics, comparing with real-time queries, or prerequisites such as needing a valid PromQL query. This lack of contextual direction leaves the agent without usage cues.
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!