Skip to main content
Glama

Get Resource Usage History

resource_usage_history
Read-only

Time-range resource-usage history for ONE environment (CPU, memory, network/bandwidth, request throughput, latency percentiles, error rate, and instance count), read live from Cloud Monitoring.

UNITS: read these before interpreting a number: cpu and memory are FRACTIONS from 0 to 1 of the environment's configured limit (see limits), NOT percentages and NOT absolute values. Multiply by limits.cpu/limits.memory_mb to get an absolute vCPU/MB figure. network values are BYTES per step_seconds-second bucket (not a rate: divide by step_seconds for bytes/sec), and each bucket is an independent Cloud Monitoring aggregation (not an overlapping rolling window), so summing consecutive buckets is safe. throughput is requests per second. latency percentiles (p50/p95/p99) are in milliseconds. errors.value is 5xx requests per second and errors.rate is a percentage of total throughput. instances is a raw count. A null value in any series is a missing sample, not zero.

summary (min/avg/max/latest per metric, per percentile for latency, per direction for network) is ALWAYS returned for every metric the service came back with, regardless of metrics below, and is ALWAYS computed from the FULL, un-downsampled series. Nulls are skipped when computing it, and max_points below never affects it, so a spike or a dip cannot be averaged away from summary even when series is downsampled.

series (the raw time-stamped points) is returned ONLY for the metrics named in metrics, which is OPTIONAL and defaults to EMPTY. Omitting it (or passing []) returns summary only. summary already tells you whether a metric is worth asking for in series; requesting raw points for one or more named metrics is always a second, explicit call. Before downsampling, a raw series has roughly 60 points at range=1h, 288 at 24h, and 168 at 7d. Request metrics sparingly at wider ranges.

max_points (default 60, minimum 10, maximum 500) bounds how many points EACH requested series in series can return: a series longer than max_points is downsampled into at most max_points equal-width buckets, each bucket's fields AVERAGED across its points (nulls skipped; a bucket that is all-null for a field stays null), with each bucket's t taken from its first point. The response's downsampled is true when this happened to any requested series, and effective_step_seconds is then step_seconds multiplied by the bucket width in raw points (null when nothing was downsampled). Use it to label a chart's x-axis correctly.

Takes the app_id returned by apps_list and the REQUIRED environment_id returned by environments_list (this data is per Cloud Run service, so there is no "every environment" answer). Optional range: 1h, 24h (default), or 7d. For a live-right-now snapshot instead of history, use resource_usage_get.

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": {
      "app_id": "<app_id>",
      "environment_id": "<environment_id>"
    },
    "name": "resource_usage_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
rangeNoTime window: `1h`, `24h`, or `7d`. Default `24h`.
app_idYesThe app uuid returned by `apps_list`.
metricsNoWhich metrics to return raw `series` points for, subset of `cpu`, `memory`, `network`, `throughput`, `latency`, `errors`, `instances`. Default EMPTY: `summary` only. `summary` always covers every metric regardless of this filter.
max_pointsNoMaximum points per requested series in `series`; a longer series is downsampled (averaged into equal-width buckets). Default 60, minimum 10, maximum 500. Never affects `summary`, which always reflects the full series.
environment_idYesThe environment uuid returned by `environments_list`. Required. This data is per Cloud Run service.
organization_idNoAn organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint/destructiveHint; the description goes far beyond them, documenting null-as-missing-sample semantics, that `summary` is always computed from the full un-downsampled series and is immune to `max_points`, and precisely how downsampling averages buckets and sets `effective_step_seconds`/`downsampled`. It also forewarns that there is no cross-environment answer, which prevents a plausible misuse.

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?

Paragraph-per-topic structure with bold labels (UNITS, summary, series, max_points) is easy to scan, and nearly every sentence carries operational content. It is nonetheless long and repeats the metrics-defaults/`summary`-always-covers-everything point twice, and the critical sibling routing sits in the final sentence rather than being front-loaded.

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?

With no output schema, the description carries the full return-value burden and does so: it defines every metric's unit, the `summary` vs `series` split, the shape of `downsampled` and `effective_step_seconds`, and null handling. Nothing an agent needs to call this correctly or interpret the response is missing.

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 coverage is 100%, so the baseline is 3, but the description adds interpretive meaning: what `metrics` omitting means in practice (summary only, and that a second explicit call is needed for raw points), how `max_points` buckets are averaged and that `t` comes from the first point, and the point counts per range. The `organization_id`/`app_id` slug-resolution behavior is left entirely to the schema, which keeps it from a 5.

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?

Opens with a specific verb+resource+scope: time-range resource-usage history for ONE environment, enumerating the exact metrics returned and noting the data is read live from Cloud Monitoring. It also distinguishes itself from `resource_usage_get` (live snapshot) and names the prerequisite sources `apps_list` and `environments_list`, so an agent can place it among siblings without opening a schema.

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

Usage Guidelines5/5

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

Explicit routing: 'For a live-right-now snapshot instead of history, use `resource_usage_get`', plus 'requesting raw points ... is always a second, explicit call' and 'Request `metrics` sparingly at wider ranges.' It also states that `summary` should be consulted first to decide whether `series` is worth requesting, which is real when-to-use guidance rather than a restatement of the schema.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources