fettle-mcp

Overview Schema Source Related Servers Discussions Admin

List a monitor's check results

list_check_results

Read-onlyIdempotent

Retrieve a monitor's individual check results, newest first, to diagnose downtime: see which regions failed and the status code or error for each.

Instructions

List one monitor's individual check results, newest first, to find out why it is DOWN: which regions fail and with what status code or error. Each has id, region, checked_at, status, response_time_ms, status_code, error_message, details and maintenance_window_id (set when the check ran inside a window). For totals use get_uptime_summary or get_uptime_daily; for the incident they opened use list_incidents. Returns a page: items plus total (of matching results), page, size and pages.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number, 1 or more; default 1.
`size`	No	Rows per page, 1 to 100; default 25. Keep paging until you have seen total rows.
`region`	No	Keep one region's results: its exact code, up to 64 characters.
`status`	No	Keep results with this status only.
`monitor_id`	Yes	The monitor's uuid from list_monitors. An id that is not a monitor of this organization, or a deleted one, is a 404.
`period_days`	No	Keep results of the last N days, 1 to 365; without it every stored result is eligible.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`page`	Yes
`size`	Yes
`items`	Yes
`pages`	Yes
`total`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.6.1Oct 20, 2026

addedInput schema / properties / monitor_id / description

Added value: +"The monitor's uuid from list_monitors. An id that is not a monitor of this organization, or a deleted one, is a 404."

addedInput schema / properties / page / description

Added value: +"Page number, 1 or more; default 1."

addedInput schema / properties / period_days / description

Added value: +"Keep results of the last N days, 1 to 365; without it every stored result is eligible."

addedInput schema / properties / region / description

Added value: +"Keep one region's results: its exact code, up to 64 characters."

addedInput schema / properties / size / description

Added value: +"Rows per page, 1 to 100; default 25. Keep paging until you have seen total rows."

addedInput schema / properties / status / description

Added value: +"Keep results with this status only."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "items": {
+      "items": {
+        "properties": {
+          "checked_at": {
+            "type": "string"
+          },
+          "details": {
+            "anyOf": [
+              {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "error_message": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "id": {
+            "format": "uuid",
+            "type": "string"
+          },
+          "job_id": {
+            "type": "string"
+          },
+          "maintenance_window_id": {
+            "anyOf": [
+              {
+                "format": "uuid",
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "monitor_id": {
+            "format": "uuid",
+            "type": "string"
+          },
+          "region": {
+            "type": "string"
+          },
+          "response_time_ms": {
+            "anyOf": [
+              {
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "status": {
+            "description": "Known values: UP, DEGRADED, DOWN, ERROR.",
+            "type": "string"
+          },
+          "status_code": {
+            "anyOf": [
+              {
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "required": [
+          "id",
+          "monitor_id",
+          "region",
+          "checked_at",
+          "status",
+          "response_time_ms",
+          "status_code",
+          "error_message",
+          "details",
+          "job_id"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "page": {
+      "type": "integer"
+    },
+    "pages": {
+      "type": "integer"
+    },
+    "size": {
+      "type": "integer"
+    },
+    "total": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "items",
+    "total",
+    "page",
+    "size",
+    "pages"
+  ],
+  "type": "object"
+}

First observedv0.5.4Oct 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds ordering (newest first), the semantics of maintenance_window_id (set when the check ran inside a window), and the paging contract. It does not discuss result retention limits or any rate/volume caveats, so it falls short of the richest disclosure but clearly adds context beyond annotations.

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 the diagnostic purpose, then the returned fields, then routing to alternatives, then the pagination contract — a logical order with near-zero filler. The 'Returns a page: items plus total, page, size and pages' sentence is largely redundant given an output schema exists, which keeps it from a 5.

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 six-parameter paginated read tool with full schema coverage, an output schema and read-only annotations, the description supplies everything an agent needs: purpose, the diagnostic use case, sibling routing, field-level meaning for maintenance_window_id, and how to page. No material gap remains.

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 page, size, region, status, monitor_id and period_days are already documented, including enum values and the 404 case. The description adds no filter syntax or semantics beyond the field names it enumerates, so the baseline of 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?

States a specific verb and resource (list one monitor's individual check results) plus scope (newest first) and diagnostic intent ('to find out why it is DOWN'). An agent can distinguish it from list_monitors, get_uptime_summary and list_incidents without opening any 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?

Explicitly frames the when ('to find out why it is DOWN: which regions fail and with what status code or error') and names two alternatives with their selecting conditions: get_uptime_summary/get_uptime_daily for totals, list_incidents for the incident they opened. Nothing is left to inference.

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

Deploy Server