fettle-mcp

Overview Schema Source Related Servers Discussions Admin

Rename a status page incident

update_status_page_incident

Idempotent

Rename a status page incident's title without notifying subscribers, requiring write access; use it to correct headlines while leaving status and updates unchanged.

Instructions

Change a status page incident's title without telling anyone: nothing is sent to subscribers. To change its status or add a message use post_status_page_update. Requires a key with the write scope. Returns the incident. Example: {"page_id": "", "incident_id": "", "title": "API errors in eu-central"}

Input Schema

TableJSON Schema

Name	Required	Description
`title`	Yes	The new headline, 1 to 255 characters.
`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.
`incident_id`	Yes	The status page incident's uuid from list_status_page_incidents (not from list_incidents). An unknown id is a 404.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`title`	Yes
`status`	Yes	Known values: INVESTIGATING, IDENTIFIED, MONITORING, RESOLVED.
`is_auto`	Yes
`updates`	Yes
`started_at`	Yes
`notified_at`	Yes
`resolved_at`	Yes
`component_ids`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.6.1Oct 20, 2026

addedInput schema / properties / incident_id / description

Added value: +"The status page incident's uuid from list_status_page_incidents (not from list_incidents). An unknown id is a 404."

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 / title / description

Added value: +"The new headline, 1 to 255 characters."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "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"
+}

First observedv0.5.4Oct 20, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), but the description adds behavior the annotations cannot express: no subscriber notification is sent, and a key with the write scope is required. It also states the return value. This is meaningful side-effect and auth context beyond structured fields.

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?

Four tight sentences: the action and its silent side effect come first, then the alternative tool, then auth, then a compact example. Every sentence carries a distinct fact and none is padding.

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 three-parameter, fully-required mutation with an output schema present, the description supplies the missing pieces: silent notification behavior, required write scope, the competing sibling tool, and ID provenance. Nothing an agent needs to call it correctly is absent.

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 each parameter already documents its source and error behavior ('from list_status_pages', 404 on unknown id), so the baseline is 3. The example restates the same ID provenance rather than adding new semantics such as title constraints or conflict behavior, so no credit above baseline.

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 — renaming a status page incident's title — and immediately clarifies the scope ('without telling anyone: nothing is sent to subscribers'). It explicitly distinguishes itself from the sibling post_status_page_update, which handles status changes and messages, so an agent can route correctly without opening either 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?

Names the alternative tool (post_status_page_update) and the exact condition that selects it ('to change its status or add a message'). It also states the positive condition for this tool: a silent title-only change. Nothing about when-to-use 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