Skip to main content
Glama

Get Resource Usage

resource_usage_get
Read-only

Current resource usage for an app's environment(s): CPU and memory usage against configured limits, network bytes, and (for each environment's database add-on) connection count, storage, average query time, and backup size. Also returns meters: the app's hosting/infrastructure metered usage for the CURRENT BILLING PERIOD (bandwidth GB, autoscaling uptime hours, database storage MB) against its plan limit.

UNITS: read these before interpreting a number: cpu.utilization is a FRACTION 0 to 1 of cpu.configured (the configured vCPU count, a free-form string like "1" or "2"), NOT a percentage and NOT an absolute vCPU figure; multiply by 100 yourself for a percent, or combine with cpu.configured if you need "42% of 2 vCPU" phrasing. memory is the opposite: used_mb/configured_mb are both already ABSOLUTE megabytes. network.egress_bytes/ingress_bytes are bytes, but NOT a cumulative total and NOT necessarily fresh: the collector sums these counters over a trailing ~30-minute WINDOW and rewrites the row every ~2 minutes, so consecutive reads overlap heavily (do not sum them to get a total), and when a window's true sum is zero, the row keeps its PREVIOUS byte count while still stamping a current sampled_at, so a quiet environment can look like a fresh nonzero reading.

These are PERIODIC SAMPLES, not live reads. Meridian's collector samples every ~2 minutes over a rolling ~30-minute window, so a number can be up to a few minutes stale. meters, in contrast, refresh on their OWN, SLOWER cadence: HOURLY, via the usage:sync-meters schedule, so a meter value can lag the environment snapshot by up to an hour; check each meter's own as_of rather than assuming it is as fresh as the rest of the payload. For trends over time (a chart, an alert on a rate of change), use resource_usage_history instead.

Each meters entry: limit: null means UNLIMITED, limit: 0 means NO ALLOWANCE was granted at all (both distinct from a positive cap). unlimited makes the null case explicit. used: null means the meter has never been measured for this app (distinct from 0, measured-and-idle); as_of is the measurement timestamp, null exactly when used is null. remaining is null when unlimited or when used is null; otherwise max(0, limit - used). over_limit is always false when unlimited or unmeasured.

Takes the app_id returned by apps_list. Optionally scope to one environment_id (from environments_list); omitted returns every environment. An environment that has never deployed, or that the collector has not sampled yet, is still returned, with sampled_at: null and every usage field null, never dropped or errored. disk usage is deliberately absent: Cloud Run has no persistent disk, so the platform never has a number to report there.

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>"
    },
    "name": "resource_usage_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
app_idYesThe app uuid returned by `apps_list`.
environment_idNoScope to a single environment uuid returned by `environments_list`. Omitted: every environment of the app.
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.6/5.0
Behavior5/5

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

Annotations already mark this as a safe read, but the description adds substantial behavior beyond them: periodic ~2-minute sampling over a ~30-minute rolling window, meters refreshing hourly on a separate schedule, and the trap where a quiet environment retains a previous nonzero byte count under a fresh `sampled_at`. It also documents edge cases (never-deployed environments returned with all-null fields, `disk` deliberately absent) that an agent could not otherwise predict.

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?

Purpose is front-loaded and the unit-interpretation block is genuinely load-bearing, since misreading `cpu.utilization` as a percentage would produce wrong answers. It is long, though, and a few passages restate themselves (the fraction-vs-percentage warning is repeated in two forms), which keeps it short of a 5.

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?

There is no output schema, so the description carries the full burden of explaining return values, and it does: field-level unit semantics, the `meters` null triad (`limit: null` unlimited vs `limit: 0` no allowance vs `used: null` unmeasured), and derived-field rules for `remaining` and `over_limit`. Nothing an agent needs to interpret the payload correctly is missing.

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 description coverage is 100%, so all three parameters are already documented, which sets the baseline at 3. The description reinforces `app_id` provenance and `environment_id` scoping behavior but never mentions `organization_id` or its slug-vs-uuid resolution, so it adds little beyond the schema.

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 (current resource usage for an app's environments) and enumerates exactly what is returned: CPU/memory against configured limits, network bytes, per-environment database add-on metrics, and billing-period `meters`. It explicitly distinguishes itself from `resource_usage_history`, so an agent can route 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 Guidelines5/5

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

Gives an explicit when-not: 'For trends over time (a chart, an alert on a rate of change), use `resource_usage_history` instead.' It also names the source tools for its inputs (`apps_list` for `app_id`, `environments_list` for `environment_id`) and states the default behavior when `environment_id` is omitted.

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