Skip to main content
Glama
Cloady

Cloady

Official
by Cloady

Query App Metrics

queryAppMetrics
Read-only

Run an instant PromQL query against an app’s own metrics to inspect resource usage, replicas, uptime, requests, and alerts, returning Prometheus’s result unchanged.

Instructions

Runs a PromQL query at one instant against the app's own metrics, kept for 62 days, and returns Prometheus's answer unchanged. Only the app's series are visible, whatever the query selects. Every series carries namespace, the app's (getWorkspace returns each app's), and most carry container, the compose service, and pod. Resources: container_cpu_usage_seconds_total, container_spec_cpu_quota / container_spec_cpu_period (the CPU limit), container_memory_working_set_bytes, container_spec_memory_limit_bytes, container_fs_reads_bytes_total, container_fs_writes_bytes_total, container_oom_events_total, and container_network_receive_bytes_total / container_network_transmit_bytes_total, which carry only pod, so match them as pod=~"<service>-[a-z0-9]+-[a-z0-9]+". Replicas: kube_pod_container_status_ready, kube_pod_container_status_restarts_total, kube_pod_container_status_waiting_reason and kube_pod_container_status_last_terminated_reason (reason), and kube_deployment_spec_replicas / kube_deployment_status_replicas_available, whose deployment is the service. Volumes: kubelet_volume_stats_used_bytes and kubelet_volume_stats_capacity_bytes, whose persistentvolumeclaim is the compose volume (each service's volumes in getWorkspace). Requests to the service the app's address routes to: traefik_service_requests_total (code, method, protocol) and traefik_service_request_duration_seconds_bucket (le). Uptime checks are method="HEAD", so leave them out with method!="HEAD", and a scale-to-zero function reports as container="<service>-fn". Uptime: cloady:probe_success:serving (kind="auto" is the check of the app's address) and cloady:service_up:serving, each service's availability from 0 to 1. Spans, once the app sends OpenTelemetry traces: traces_spanmetrics_calls_total and traces_spanmetrics_latency_bucket (span_name, span_kind, status_code, http_status). RabbitMQ: rabbitmq_detailed_queue_messages_ready. Alert rules: ALERTS (alertname, alertstate, container, cloady_metric), whose alertstate="firing" samples are the app's incident history. queryAppMetricsRange runs a query over a range. 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>",
      "appSlug": "<appSlug>",
      "query": "<query>"
    },
    "name": "queryAppMetrics"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNo
timeNoWhen to evaluate the query, as Unix seconds or RFC 3339; now when absent
queryYesA PromQL expression
regionNo
appSlugYes
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.4/5.0
Behavior5/5

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

The annotations already establish read-only, non-destructive, open-world behavior, and the description adds important context beyond them: 62-day retention, app-scoped visibility, unchanged Prometheus responses, and error behavior when the store refuses a query. It also notes that the endpoint can be used as a Grafana data source path.

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?

The core purpose and scope are front-loaded, and most of the long resource catalogue is relevant for correct PromQL construction. The description is still a dense single block that would benefit from clearer structure, but it contains little obvious filler.

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

Completeness5/5

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

For a complex metrics-query tool with no output schema, the description is unusually complete: it explains scope, retention, available metric families and labels, error handling, and the range-query sibling. The optional env and region parameters are not documented, but that is a minor gap relative to the overall coverage.

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

Parameters3/5

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

Schema coverage is only 33%, and the description heavily enriches the query parameter by listing PromQL metric names, labels, and matching conventions. However, it does not explain env, region, workspaceSlug, or appSlug semantics, so it only partially compensates for the low schema coverage.

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?

The description states a specific verb and scope: it runs a PromQL query at one instant against the app's own metrics and returns Prometheus's answer unchanged. It also distinguishes this from queryAppMetricsRange by noting the sibling handles range queries.

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?

The description gives clear context for instant queries and names queryAppMetricsRange as the range alternative. It does not explicitly compare against streamAppMetrics or queryWorkspaceMetrics, so the when-to-use guidance is strong but not exhaustive.

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