fettle-mcp

Overview Schema Source Related Servers Discussions Admin

List a status page's incidents

list_status_page_incidents

Read-onlyIdempotent

List incidents shown on a status page, newest first, including manual and Fettle-opened outages, to find the incident_id for post_status_page_update.

Instructions

List the incidents shown on one status page, newest first, both posted by a person and opened by Fettle. Each has id, title, status, is_auto (opened by Fettle from a monitor), started_at, resolved_at, notified_at (when subscribers were first emailed; null if never), component_ids and updates (the timeline, oldest first, each with id, status, body, created_by and created_at). Use it to find the incident_id for post_status_page_update. Monitor outages behind the scenes are list_incidents. Returns a page: items plus total, 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.
`page_id`	Yes	The status page's uuid from list_status_pages. An id that is not a status page of this organization is a 404.

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.

Changed4 schema fields changedv0.6.1Oct 20, 2026

addedInput schema / properties / page / description

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

addedInput schema / properties / page_id / description

Added value: +"The status page's uuid from list_status_pages. An id that is not a status page of this organization is a 404."

addedInput schema / properties / size / description

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

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "items": {
+      "items": {
+        "properties": {
+          "component_ids": {
+            "items": {
+              "format": "uuid",
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "id": {
+            "format": "uuid",
+            "type": "string"
+          },
+          "is_auto": {
+            "type": "boolean"
+          },
+          "notified_at": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "resolved_at": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "started_at": {
+            "type": "string"
+          },
+          "status": {
+            "description": "Known values: INVESTIGATING, IDENTIFIED, MONITORING, RESOLVED.",
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "updates": {
+            "items": {
+              "properties": {
+                "body": {
+                  "type": "string"
+                },
+                "created_at": {
+                  "type": "string"
+                },
+                "created_by": {
+                  "anyOf": [
+                    {
+                      "format": "uuid",
+                      "type": "string"
+                    },
+                    {
+                      "type": "null"
+                    }
+                  ]
+                },
+                "id": {
+                  "format": "uuid",
+                  "type": "string"
+                },
+                "status": {
+                  "description": "Known values: INVESTIGATING, IDENTIFIED, MONITORING, RESOLVED.",
+                  "type": "string"
+                }
+              },
+              "required": [
+                "id",
+                "status",
+                "body",
+                "created_by",
+                "created_at"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "id",
+          "title",
+          "status",
+          "is_auto",
+          "started_at",
+          "resolved_at",
+          "notified_at",
+          "component_ids",
+          "updates"
+        ],
+        "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 already cover the read-only, idempotent, non-destructive profile, so the bar is lower. The description adds ordering behavior ('newest first', updates 'oldest first') and field semantics such as is_auto meaning Fettle-opened from a monitor and notified_at being null if never emailed. It does not discuss filtering or rate limits, but the added behavioral context is substantive.

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 core verb and scope, then the returned fields, then the sibling routing. It is dense and slightly long, but nearly every clause conveys return shape or routing information rather than filler.

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?

Combined with a 100%-covered schema, full annotations, and an output schema, the description supplies ordering, field semantics, pagination behavior, and sibling routing. 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% and all three parameters (page, size, page_id) are fully documented in the schema, including defaults and the 404 case for page_id. The description adds nothing beyond that, so the 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?

States a specific verb and resource ('List the incidents shown on one status page'), scopes it to a single page, and explicitly distinguishes itself from the sibling list_incidents ('Monitor outages behind the scenes are list_incidents'). An agent can route 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?

Gives both the when-to-use rationale ('Use it to find the incident_id for post_status_page_update') and the when-not/alternative ('Monitor outages behind the scenes are list_incidents'). This is explicit routing guidance, not inference.

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

Deploy Server