Skip to main content
Glama
Cloady

Cloady

Official
by Cloady

Query Workspace Metrics

queryWorkspaceMetrics
Read-only

Runs a PromQL query at one instant across all workspace apps or filtered by env and region, returning the store's response unchanged for metric analysis.

Instructions

Runs a PromQL query at one instant across the metrics of every app in the workspace, or only those in env and region, and returns Prometheus's answer unchanged. Group by namespace to tell the apps apart. The labels and series are queryAppMetrics'. A query the store refuses comes back with the store's own status and error. The path is the store's own, so a Grafana data source can point here too.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspaceSlug": "<workspaceSlug>",
      "query": "<query>"
    },
    "name": "queryWorkspaceMetrics"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNoOnly the apps in this env; every env when absent
timeNoWhen to evaluate the query, as Unix seconds or RFC 3339; now when absent
queryYesA PromQL expression
regionNoOnly the apps in this region; every region when absent
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (read-only, open-world, non-destructive), and the description adds genuinely new behavior: the answer is returned unchanged as Prometheus sends it, refusals surface the store's own status plus `error`, and the path is compatible with a Grafana data source. It does not mention limits on series volume or cardinality, which is the main remaining gap for a fan-out metrics query.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the verb and scope, then layered with grouping advice, error behavior, and the Grafana note — each sentence carries information. The final Grafana sentence is the least load-bearing for an agent choosing a tool, but it is not filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly takes on responsibility for the return value (raw Prometheus response, error object on refusal) and explains how to disambiguate series across apps. Complete enough to call correctly; only rate/cardinality expectations are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80%, so the baseline is 3, but the description adds real semantics beyond the schema: `time` is framed as instant evaluation, env/region are framed as app filters within the workspace, and the namespace grouping advice tells the agent how to actually make use of the returned labels. The only undocumented parameter, workspaceSlug, is implicitly explained by "every app in the workspace."

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Runs a PromQL query ... across the metrics of every app in the workspace") and pins down the temporal mode with "at one instant," which separates it from the range sibling queryAppMetricsRange. It also names queryAppMetrics explicitly as the tool whose labels and series are reused, so an agent can distinguish workspace-wide from per-app scope without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is clear: instant evaluation across all apps, optionally narrowed by env and region, with a note that grouping by namespace separates apps. What's missing is an explicit routing rule — it never says to use queryAppMetrics for a single app or queryAppMetricsRange for a time series, leaving that inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools