SolidPing

Official

Overview Schema Source Related Servers Discussions Admin

List results

list_results

Read-onlyIdempotent

Query raw or aggregated monitoring results with filters by check, status, region, and time range for trend analysis or window inspection.

Instructions

Query monitoring results (raw or aggregated) with filtering by check, type, status, region, period type, and time range. Use this for trend analysis or to inspect a specific window. For investigating a single check's current state, use diagnose_check instead. Returns {data, pagination, window, effectiveFilter}: data holds the result rows, window the time bounds actually queried, and effectiveFilter the period filter that ran after defaulting. Defaults: if periodType is omitted it falls back to "hour"; if periodStartAfter is omitted it falls back to a window matched to the finest periodType requested (raw=1h, hour=24h, day=30d, month=365d). Read-only: works with mcp:read tokens.

Input Schema

TableJSON Schema

Name	Required	Description
`size`	No	Max results (1-100, default 20).
`with`	No	Comma-separated extra fields: durationMs — response time in ms durationMinMs — min response time in the bucket (aggregated rows only) durationMaxMs — max response time in the bucket (aggregated rows only) region — region the check ran in metrics — per-execution metrics output — full check output incl. error messages availabilityPct — uptime % (aggregated rows only) checkSlug — slug of the check checkName — human name of the check Example: "durationMs,output".
`cursor`	No	Opaque pagination cursor returned by a previous response. Omit on the first page.
`region`	No	Comma-separated region slugs, e.g. "eu-west-1,us-east-1".
`status`	No	Comma-separated result statuses. Allowed: up, down, created, running, abandoned. "down" covers every genuine failure (down, timeout, error); "abandoned" is separate on purpose — it marks an attempt nothing was ever reported for, which is excluded from availability and is NOT downtime. Example: "down" or "down,abandoned".
`checkUid`	No	Comma-separated check UIDs or slugs to filter by, e.g. "api-prod,db-prod".
`checkType`	No	Comma-separated check types. Allowed: http, tcp, icmp, dns, heartbeat, email, domain, ssl, smtp, udp, ssh, pop3, imap, websocket, postgresql, ftp, sftp, js, mysql, redis, mongodb, mssql, oracle, clickhouse, grpc, kafka, mqtt, a2s, minecraft, rabbitmq, snmp, docker, browser, freebox_line, dnsbl, sip, kubernetes, ntp, rdp, vnc, prometheus, private-location, crawl, health. Example: "http,dns".
`periodType`	No	Comma-separated period types. Allowed: raw (single executions), hour, day, month (rollups). Defaults to "hour" when omitted. Example: "raw".
`periodEndBefore`	No	RFC3339 timestamp (exclusive upper bound), e.g. "2026-05-03T11:00:00Z".
`periodStartAfter`	No	RFC3339 timestamp (inclusive lower bound), e.g. "2026-05-03T10:14:22Z". Defaults to a window matched to periodType when omitted (raw=1h, hour=24h, day=30d, month=365d).

Output Schema

TableJSON Schema

Name	Required	Description
`data`	No	Result rows on this page: raw executions or aggregated rollups.
`window`	No	Time window the server actually queried.
`pagination`	No	Cursor pagination for this filter.
`effectiveFilter`	No	Period filter that actually ran, after the tool's defaulting.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.38.5Oct 15, 2026

changedInput schema / properties / checkType / description

Previous value: -"Comma-separated check types. Allowed: http, tcp, icmp, dns, ssl, heartbeat, domain. Example: \"http,dns\"."New value: +"Comma-separated check types. Allowed: http, tcp, icmp, dns, heartbeat, email, domain, ssl, smtp, udp, ssh, pop3, imap, websocket, postgresql, ftp, sftp, js, mysql, redis, mongodb, mssql, oracle, clickhouse, grpc, kafka, mqtt, a2s, minecraft, rabbitmq, snmp, docker, browser, freebox_line, dnsbl, sip, kubernetes, ntp, rdp, vnc, prometheus, private-location, crawl, health. Example: \"http,dns\"."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "data": {
+      "description": "Result rows on this page: raw executions or aggregated rollups.",
+      "items": {
+        "properties": {
+          "availabilityPct": {
+            "description": "Uptime % for the bucket (with=availabilityPct, aggregated rows only).",
+            "type": "number"
+          },
+          "checkName": {
+            "description": "Check name (with=checkName).",
+            "type": "string"
+          },
+          "checkSlug": {
+            "description": "Check slug (with=checkSlug).",
+            "type": "string"
+          },
+          "checkUid": {
+            "description": "UID of the check this result belongs to.",
+            "type": "string"
+          },
+          "durationMs": {
+            "description": "Response time in ms (with=durationMs).",
+            "type": "number"
+          },
+          "periodStart": {
+            "description": "RFC3339 start of the period (raw: execution time).",
+            "type": "string"
+          },
+          "periodType": {
+            "description": "Aggregation level: raw, hour, day or month.",
+            "type": "string"
+          },
+          "region": {
+            "description": "Region the check ran in (with=region).",
+            "type": "string"
+          },
+          "status": {
+            "description": "Result status: up, down, created, running, abandoned…",
+            "type": "string"
+          },
+          "uid": {
+            "description": "Result UID (time-ordered).",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "effectiveFilter": {
+      "description": "Period filter that actually ran, after the tool's defaulting.",
+      "properties": {
+        "periodEndBefore": {
+          "description": "Applied upper bound (RFC3339); absent when not requested.",
+          "type": "string"
+        },
+        "periodStartAfter": {
+          "description": "Applied lower bound (RFC3339); set by the default when not requested.",
+          "type": "string"
+        },
+        "periodType": {
+          "description": "Period types queried, e.g. [\"hour\"].",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "pagination": {
+      "description": "Cursor pagination for this filter.",
+      "properties": {
+        "cursor": {
+          "description": "Opaque cursor for the next page; absent on the last page.",
+          "type": "string"
+        },
+        "size": {
+          "description": "Page size used for this response.",
+          "type": "integer"
+        }
+      },
+      "type": "object"
+    },
+    "window": {
+      "description": "Time window the server actually queried.",
+      "properties": {
+        "clamped": {
+          "description": "True when the server moved periodStartAfter forward (raw requests are clamped to the raw-retention band).",
+          "type": "boolean"
+        },
+        "periodEndBefore": {
+          "description": "Effective exclusive upper bound (RFC3339); absent when the query has none.",
+          "type": "string"
+        },
+        "periodStartAfter": {
+          "description": "Effective inclusive lower bound (RFC3339); absent when the query has none.",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

First observedv0.32.1Sep 26, 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 safety is covered; the description goes further by disclosing defaulting behavior (periodType falls back to 'hour', periodStartAfter falls back to a window matched to periodType) and the auth scope (mcp:read tokens). It stops short of describing rate limits or exact aggregation semantics, which keeps it below a 5.

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?

Front-loaded with purpose and routing before the return-shape and defaults detail. Minor redundancy: the periodType/periodStartAfter default rules are repeated from the schema descriptions, costing a little efficiency but not readability.

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 10-parameter read tool with an output schema and full annotation coverage, the description supplies everything needed: filtering scope, sibling routing, fallback defaults, and the auth profile. Nothing an agent needs 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all ten parameters. The description largely restates the periodType/periodStartAfter defaults that are already in the schema rather than adding new syntax or format meaning, so baseline 3 applies.

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?

Specific verb (Query) plus resource (monitoring results) with scope detail (raw or aggregated) and filtering dimensions named. It explicitly distinguishes itself from the diagnose_check sibling, so an agent can select correctly without opening the 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?

States the intended use cases ('trend analysis or to inspect a specific window') and names the alternative with the condition that selects it ('For investigating a single check's current state, use diagnose_check instead'). When-to-use and when-not are both explicit.

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