Pingstack

List check runs

list_check_runs

Read-onlyIdempotent

List one check's individual runs inside a window, oldest first, 20 per page: each run's id, when it was received (received_at), how long it took in milliseconds (duration_ms, null when no time was measured) and the probe_id or resolver_id it came from. A run is one heartbeat received or one probe or lookup made. It shows exactly when a check ran and which probe or resolver each run came from; daily totals and latency percentiles are separate reads. days is 7, 14, 30 or 90 and defaults to 30; asking for more than the plan's limits.run_history_days returns quota_exceeded. An unknown check id returns not_found. Request payloads, source IPs and credentials are never returned. time_zone (an IANA name) sets the zone for the window and timestamps; the default is UTC, and the response names its zone. next_cursor is null on the last page.

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": {
      "id": "<id>"
    },
    "name": "list_check_runs"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Check id (check_…).
`days`	No	Days of individual runs, up to the plan's limit. Defaults to 30, or the plan's limit when shorter.
`limit`	No	Items per page, 1 to 100. Defaults to 20.
`cursor`	No	next_cursor from the previous page. Omit for the first page; next_cursor is null on the last.
`time_zone`	No	IANA time zone for days and timestamps, such as America/Chicago. Defaults to UTC.

Output Schema

Name	Required	Description	Default
`id`	Yes
`items`	Yes
`end_at`	Yes
`start_at`	Yes
`time_zone`	Yes
`next_cursor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses ordering (oldest first), default and maximum page size, error outcomes (quota_exceeded for windows beyond plans.limit history, not_found for unknown ids), timezone behavior, and the null next_cursor sentinel. It also states a privacy guarantee that request payloads, source IPs, and credentials are never returned, which is information an agent cannot get from structured fields.

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?

It is front-loaded with the core purpose and return fields, and every clause is substantive. The single dense block is slightly run-on, mixing return fields, errors, and timezone rules, and it partially repeats schema details such as the days enum and cursor null sentinel.

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 paginated list tool with an output schema and full annotation coverage, the description supplies everything an agent needs to call it correctly: defaults, plan limits, pagination termination, error cases, timezone scope, and privacy boundaries. Nothing material is left to inference.

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 already 100%, so the baseline is 3; the description adds meaning on top by stating the plan-limit interaction for days and the quota_exceeded consequence, that time_zone governs both the window and the timestamps, and that the response names its zone. It also mentions fields the schema does not (received_at, duration_ms nullability, probe_id/resolver_id), which is extra but slightly misaligned with parameter semantics.

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 names a specific verb and resource ('List one check's individual runs inside a window') and states the scope, ordering, and page size. It also explicitly separates itself from the aggregate reads ('daily totals and latency percentiles are separate reads'), so an agent can distinguish it from get_check_history and get_check_metrics without opening their schemas.

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 makes clear this is for individual run-level detail in a bounded window, and it explicitly says aggregation belongs to other reads, which is effective routing guidance. It doesn't name those sibling tools, so the agent still has to match the phrase to a tool name, but the when-to-use boundary is clear.

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

All Pingstack tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?