Skip to main content
Glama

A server's CPU, memory, disk and load over time

server_metric_history
Read-onlyIdempotent

Time series InfraNest has stored for this server, as [unix seconds, value] pairs, oldest first, with the alert threshold that applies to each metric. Pick a comma-separated metrics list, then either a fixed range (live, h1, h12, h24, d7, d30; default h24) or your own window with from and to (ISO 8601) and optionally resolution: raw for every sample (kept for 48 hours, at most 48 hours per request) or hour for hourly averages (at most 92 days per request). Without resolution, raw samples are used when they still cover the window. A longer range is refused with range_too_large. Points are paged with page and per_page (up to 10,000, the default); pagination says how many points the window holds and window the range that was applied. normal gives each requested metric’s normal week: hours holds 168 entries, one per hour of the week starting Monday 00:00 UTC, each [p10, p50, p90] of that hour’s averages over up to 12 weeks (null for an hour with too little history). It stays empty until weeks reaches min_weeks (4), unless a peer server behind the same load balancer or with the same role lends its week — then borrowed_from names it. learning_since and reset_reason (resize, reinstall, role or source) say when and why the week started again. Maintenance windows, incident hours and a memory leak’s climb are not learned. Add include=stands_out for stands_out: up to three findings about the whole window (null when it spans more than one page), each with a metric, a kind and its unformatted values in the series’ units — crossed (minutes past the alert line), aboveNormal or belowNormal (minutes outside the normal range for those hours), step (the level before and after the deploy, change or restart in event), lastWeek (the average now and then, at the same hours a week earlier) and followsNetwork (load rising and falling with traffic). For a CPU or memory step or lastWeek, behind names the service, container or process that accounts for most of the change; it is null when none clearly does, and for a step whose either side is shorter than an hour, the workloads’ sampling interval. normal says where a step or a change landed against the normal range: within, above, below or null. Add include=peers for peers: the servers worth comparing with, those behind the same load balancer first (reason load_balancer, via naming it), then those with the same roles (role). For "was it under load at 03:00": a short window with resolution raw. Each metric carries the alert threshold that applies to it. For "is anything off this week", pass include=stands_out.

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": {
      "server_id": "<server_id>"
    },
    "name": "server_metric_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoEnd of your own window (ISO 8601); default now.
fromNoStart of your own window (ISO 8601), instead of range.
rangeNoA fixed window (default h24). Or pass from and to.
includeNostands_out for what stands out in the window, peers for the servers worth comparing with; comma-separated.
metricsNoComma-separated, default cpu_percent,memory_percent,worst_mount_percent,load_1.
server_idYesThe server id, from list_servers or the number of a search hit server:N.
resolutionNoraw: every sample (last 48 hours, up to 48 hours per call); hour: hourly averages (up to 92 days).
organization_idNoThe organization to read. Leave it out when the token reaches only one.

Output Schema

NameRequiredDescriptionDefault
factsNo
seriesNo
windowNo
app_urlNo
thresholdsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / include
      Added value: +{
      +  "description": "stands_out for what stands out in the window, peers for the servers worth comparing with; comma-separated.",
      +  "type": "string"
      +}
    • changedInput schema / properties / server_id / description
      Previous value: -"The server id, from list_servers."New value: +"The server id, from list_servers or the number of a search hit server:N."
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already mark this read-only, idempotent, non-destructive, and the description goes well beyond them: raw retention of 48 hours, 48h/92-day per-request ceilings, the `range_too_large` refusal, pagination defaults (10,000), when `stands_out` is null (multi-page window), and the learning lifecycle (empty until weeks>=4, borrowed_from, reset_reason). It even discloses negative behavior — what is NOT learned (maintenance windows, incident hours, memory-leak climb).

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

Conciseness3/5

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

Front-loaded correctly — the first sentence says what comes back and in what shape — but it is a single dense block that keeps expanding into output structure detail (`normal.hours`, the five `stands_out` kinds, `behind` semantics) that an output schema presumably already carries. Much of it earns its place as edge-case handling, but the density makes it hard to scan and several sentences duplicate structured data.

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 an 8-parameter, enum-bearing tool with an output schema and full annotation coverage, the description supplies what structured fields can't: window/resolution interaction, data retention limits, error signaling, and the semantics of the anomaly and peer sections. An agent can call it correctly and interpret limits without further documentation.

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?

With 100% schema coverage the baseline is 3, but the description adds real meaning: what each `range` value implies, the range-vs-from/to exclusivity, resolution defaults and the 'raw is used when it still covers the window' fallback, and how `include` values map to output sections. Caveat: it describes paging via `page` and `per_page`, which do not appear in the input schema, so an agent may try to pass parameters that aren't listed.

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

Purpose4/5

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

States a specific verb+resource: 'Time series InfraNest has stored for this server', with the value format (`[unix seconds, value]` pairs, oldest first) and per-metric thresholds. It is clearly distinguishable from incident/DNS siblings. However, it never names its nearest sibling `server_metrics` (presumably current values) or `server_attention`, so the agent must infer which of the two metric tools to reach for.

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?

Gives concrete routing scenarios: 'For "was it under load at 03:00": a short window with resolution raw' and 'For "is anything off this week", pass include=stands_out'. It also explains the fixed-range vs from/to choice and the resolution fallback rule. It stops short of explicit when-NOT-to-use guidance or naming an alternative tool (server_metrics) to use instead.

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.