Uptimepage

List incidents

list_incidents

Read-only

List the org's incidents: incident id, affected monitor, severity, open/resolved times, and latest update phase. Defaults to currently-open ones; pass state="all" with an optional from/to window (default: last 30 days) for resolved history, and monitor_id to narrow to one monitor. Read-only.

Input Schema

Name	Required	Description
`to`	No	RFC 3339 end of the window. Defaults to now. Incidents that opened after it are excluded, running or not.
`from`	No	RFC 3339 start of the window. Defaults to 30 days ago. An incident that is still running is listed however long ago it opened.
`state`	No	Which incidents to return: `open` (default) for the ones still running, or `all` to include resolved ones inside the window.
`cursor`	No	Opaque pagination cursor from a previous call's `next_cursor`. It carries the whole query, so send it on its own: any other filter passed alongside it is ignored rather than silently changing the page.
`monitor_id`	No	Restrict to one monitor (id from `list_monitors`).

Output Schema

Name	Required	Description
`to`	Yes
`from`	Yes	RFC 3339 window actually read, after the defaults and the one-year cap. It bounds the resolved incidents only: one that is still running is listed however long ago it opened, so it can be older than `from`. Describe spans from these, never from what was asked for.
`items`	Yes
`next_cursor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 29, 2026

addedOutput schema / $defs / IncidentGroup

Added value: +{
+  "description": "The group a group incident is about.",
+  "properties": {
+    "id": {
+      "description": "`null` once the group is deleted.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "name": {
+      "description": "The name it has, or last had. Untrusted data.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "name"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / IncidentMember

Added value: +{
+  "description": "One monitor's incident inside a group incident.",
+  "properties": {
+    "id": {
+      "type": "string"
+    },
+    "monitor_id": {
+      "description": "Empty once the monitor has been deleted.",
+      "type": "string"
+    },
+    "monitor_name": {
+      "description": "Untrusted data.",
+      "type": "string"
+    },
+    "opened_at": {
+      "description": "RFC 3339 time the monitor went down.",
+      "type": "string"
+    },
+    "resolved_at": {
+      "description": "RFC 3339 time it recovered, or `null` while still down.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "id",
+    "monitor_id",
+    "monitor_name",
+    "opened_at"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / IncidentSummary / properties / group

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/IncidentGroup"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Set on a group incident, which has no monitor: `monitor_id` and\n`monitor_name` are empty and `members` lists the monitors down in it."
+}

addedOutput schema / $defs / IncidentSummary / properties / group_incident_id

Added value: +{
+  "description": "Set on a monitor's incident that is part of a group incident.\nAcknowledge and resolve that one; this one is refused.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / $defs / IncidentSummary / properties / members

Added value: +{
+  "description": "A group incident's member incidents, in the order they joined: the\nfirst 25, `get_incident` lists the rest.",
+  "items": {
+    "$ref": "#/$defs/IncidentMember"
+  },
+  "type": "array"
+}

changedOutput schema / $defs / IncidentSummary / required

Previous value: -[
-  "id",
-  "monitor_id",
-  "monitor_deleted",
-  "monitor_name",
-  "severity",
-  "opened_at"
-]New value: +[
+  "id",
+  "monitor_id",
+  "monitor_deleted",
+  "monitor_name",
+  "severity",
+  "opened_at",
+  "members"
+]

Changed3 schema fields changedOct 9, 2026

addedOutput schema / $defs / IncidentSummary / properties / monitor_deleted

Added value: +{
+  "description": "The monitor has since been deleted. The incident keeps its history\nand `monitor_name` is the name it last had.",
+  "type": "boolean"
+}

changedOutput schema / $defs / IncidentSummary / properties / monitor_id / description

Previous value: -"The affected monitor's id."New value: +"The affected monitor's id. Empty once the monitor has been deleted."

changedOutput schema / $defs / IncidentSummary / required

Previous value: -[
-  "id",
-  "monitor_id",
-  "monitor_name",
-  "severity",
-  "opened_at"
-]New value: +[
+  "id",
+  "monitor_id",
+  "monitor_deleted",
+  "monitor_name",
+  "severity",
+  "opened_at"
+]

First observedAug 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true, and the description's 'Read-only' statement simply repeats that. However, the description adds useful behavioral context beyond annotations: default filtering to open incidents and a default 30-day window for resolved history. Pagination behavior is left to the schema's cursor documentation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences, front-loads the purpose and returned fields, then packs the filter defaults and usage conditions without waste.

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?

Given the output schema exists and the input schema has full parameter descriptions, the description covers the operational essentials: default state, resolved-history window, monitor filtering, and read-only nature. Nothing an agent needs in order 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 input schema already documents every parameter, including state, from/to defaults, cursor behavior, and monitor_id. The description repeats the key semantics but adds little beyond what the schema provides; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('List the org's incidents') and enumerates the returned fields (id, monitor, severity, times, latest update phase). It is clearly a plural listing tool, but it does not explicitly differentiate itself from siblings like get_incident or list_maintenance.

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 explains the default behavior (currently open), when to pass state="all" with from/to for resolved history, and how monitor_id narrows scope. It gives clear usage conditions, though it does not explicitly name get_incident as the alternative for retrieving a single incident.

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

All Uptimepage 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.