Skip to main content
Glama

Recent check results of a monitor

monitor_results
Read-onlyIdempotent

The monitor’s check results, newest first. With resolution=raw (the default) each result is one check by one probe, filterable by status; for HTTP, API and keyword monitors it also says where the response time went, in milliseconds: dns_ms, connect_ms, tls_ms, server_ms (waiting for the first byte) and download_ms, null when the location did not measure them, and response_bytes, how big the answer’s body was (null for a HEAD request, or a location on an older version). Its meta holds what the check saw: a keyword check’s page_bytes and, when it failed, an excerpt of the page’s text (at most 512 bytes); a ping’s sent, received, loss_pct and jitter_ms; a DNS check’s records with their ttl and the resolver asked (null for the location’s own); a redirect check’s hops, each url (without its query) and status; a heartbeat’s run_duration_ms when the check-in sent duration, and for a run your agent reported, its exit_code, job_run_id and, when it failed, the masked last lines of its output — only when you can manage servers (cloud.write, on your role and on your token); otherwise output is left out and output_hidden is true. output_removed says who removed that output and when (by, at). Individual results are kept for 3 days. With resolution=hour or day each row sums one hour or one day across probes: checks by outcome (checks_up, checks_degraded for slow checks, checks_down for failures), up_percent and the p50 and p95 response times, reaching back as far as your plan keeps history. Set the window with from and to (ISO 8601; default: everything kept for raw, the last 24 hours for hours, the last 30 days for days), narrow it to one probe region, and page with page and per_page (up to 500, default 50). A range longer than the resolution allows — 3 days raw, 31 days by hour, 366 days by day — is refused with range_too_large. window repeats the range that was applied. Newest first. For uptime or response times over a period, monitor_stats is one call.

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": {
      "monitor_id": "<monitor_id>"
    },
    "name": "monitor_results"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoOnly results up to this time (ISO 8601).
fromNoOnly results from this time on (ISO 8601).
pageNoPage number, from 1.
statusNoOnly results with this status, e.g. down.
per_pageNoRows per page, up to 500 (default 50).
monitor_idYesThe monitor id, from list_monitors or the number of a search hit monitor:N.
resolutionNoraw: each check (last 3 days, up to 3 days per call); hour or day: summed per hour (up to 31 days) or per day (up to 366 days).
organization_idNoThe organization to read. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / monitor_id / description
      Previous value: -"The monitor id, from list_monitors."New value: +"The monitor id, from list_monitors or the number of a search hit monitor:N."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds substantial context beyond them: 3-day raw retention, range caps per resolution, the exact `range_too_large` refusal, the `window` echo, permission-gated field visibility tied to cloud.write with `output_hidden`/`output_removed` flags, and null semantics for measurements a location did not take.

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?

Purpose and ordering are front-loaded and no sentence is purely filler, but the second sentence is a single sprawling run-on enumerating every per-check metric and per-check-type meta field, which makes it hard to scan. A short field-level list would have preserved the information with far less cognitive load.

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 describing return shape, and it does: it enumerates timing breakdowns, per-check-type meta contents, aggregation fields for hour/day rows, and pagination plus the applied `window`. For a read tool of this complexity, nothing material an agent needs 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 meaning the schema does not: resolution-dependent defaults for `from`/`to` (everything kept for raw, 24 hours for hour, 30 days for day), the 3-day/31-day/366-day range ceilings, and where `monitor_id` comes from. It does not restate parameter types, which is correct given the schema already does that.

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 statement: "The monitor's check results, newest first," naming the exact entity and ordering. The final sentence explicitly routes a competing need (uptime/response times over a period) to the sibling monitor_stats, so the agent can distinguish it from the nearest alternative 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?

It gives real selection guidance: raw is the default and returns one check per probe, while hour/day aggregate across probes, and it names monitor_stats as the one-call alternative for period-level uptime or response times. What it lacks is an explicit boundary for cases like bulk cross-monitor queries, but for the main fork in behaviour the choice condition is spelled out.

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.