Pingstack

Get check latency metrics

get_check_metrics

Read-onlyIdempotent

Read recorded latency counts, min, mean, p50, p95 and max for 7, 14, 30 or 90 calendar days, up to the plan's limits.run_history_days. probe_id or resolver_id narrows the result to one source. Not an availability estimate. time_zone (an IANA name) sets the zone for days and timestamps; the default is UTC, and responses name their zone.

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": "get_check_metrics"
  }
}

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.
`probe_id`	No	Only runs from this probe location, by the probe_id a run reports.
`time_zone`	No	IANA time zone for days and timestamps, such as America/Chicago. Defaults to UTC.
`resolver_id`	No	Only runs from this DNS resolver, by the resolver_id a run reports.

Output Schema

Name	Required	Description	Default
`id`	Yes
`end_at`	Yes
`probe_id`	Yes
`start_at`	Yes
`run_count`	Yes
`time_zone`	Yes
`resolver_id`	Yes
`max_duration_ms`	Yes
`min_duration_ms`	Yes
`p50_duration_ms`	Yes
`p95_duration_ms`	Yes
`measurement_count`	Yes
`average_duration_ms`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: results are capped by the plan's run_history_days, days defaults to 30 or the plan limit, and responses echo the time zone used.

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?

Four compact sentences, front-loaded with the returned measures and the scope of days. Minor redundancy in re-explaining time_zone (already in the schema) and the dense 'limits.run_history_days' phrasing, but nothing is wasted.

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 read-only metrics tool with an output schema and full schema coverage, the description covers what an agent still needs: plan caps, defaults, source filtering, and time zone handling. Nothing required to call it correctly 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 baseline is 3, but the description adds meaning: the day values are calendar days bounded by plan limits, probe_id/resolver_id act as single-source filters, and time_zone governs both day bucketing and timestamps with a UTC default.

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 (Read) and resource (recorded latency counts, min, mean, p50, p95, max) with the exact window options. The line 'Not an availability estimate' actively separates it from the uptime sibling, so an agent can choose 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 Guidelines4/5

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

Gives clear selection context: use it for latency distributions, not availability, and narrow with probe_id or resolver_id when a single source is wanted. It stops short of naming the alternative tool explicitly, so the negative case is implied rather than routed.

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?