fettle-mcp

Overview Schema Source Related Servers Discussions Admin

Acknowledge an incident

acknowledge_incident

Idempotent

Mark an open incident as handled to stop repeat alerts while it's being worked on. The recovery alert still sends when the monitor resolves, and the incident remains open.

Instructions

Mark an open incident as being handled so its repeat alerts stop; the recovery alert still goes out when it resolves. Use it when someone is working on the outage. It does not close the incident (that happens when the monitor recovers) and it is not for status page incidents (post_status_page_update). Requires a key with the write scope. Acknowledging twice keeps the first acknowledgement; on a resolved incident it succeeds without effect on alerts. Returns the incident in the get_incident shape.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`incident_id`	Yes	The incident's uuid from list_incidents. An id that is not an incident of this organization is a 404.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`cause`	Yes	Known values: TIMEOUT, DNS_FAILURE, CONNECTION_REFUSED, TLS_INVALID, HTTP_4XX, HTTP_5XX, HTTP_UNEXPECTED_STATUS, KEYWORD_MISSING, TOO_MANY_REDIRECTS, TARGET_BLOCKED, PORT_STATE_MISMATCH, INVALID_TARGET, HEARTBEAT_MISSED, HEARTBEAT_FAILED, UNKNOWN.
`created_at`	Yes
`monitor_id`	No
`started_at`	Yes
`updated_at`	Yes
`resolved_at`	Yes
`cause_detail`	Yes
`heartbeat_id`	No
`renotify_count`	Yes
`acknowledged_at`	Yes
`acknowledged_by`	Yes
`last_notified_at`	Yes
`notification_logs`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.1Oct 20, 2026

addedInput schema / properties / incident_id / description

Added value: +"The incident's uuid from list_incidents. An id that is not an incident of this organization is a 404."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "acknowledged_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "acknowledged_by": {
+      "anyOf": [
+        {
+          "format": "uuid",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "cause": {
+      "description": "Known values: TIMEOUT, DNS_FAILURE, CONNECTION_REFUSED, TLS_INVALID, HTTP_4XX, HTTP_5XX, HTTP_UNEXPECTED_STATUS, KEYWORD_MISSING, TOO_MANY_REDIRECTS, TARGET_BLOCKED, PORT_STATE_MISMATCH, INVALID_TARGET, HEARTBEAT_MISSED, HEARTBEAT_FAILED, UNKNOWN.",
+      "type": "string"
+    },
+    "cause_detail": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "created_at": {
+      "type": "string"
+    },
+    "heartbeat_id": {
+      "anyOf": [
+        {
+          "format": "uuid",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "id": {
+      "format": "uuid",
+      "type": "string"
+    },
+    "last_notified_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "monitor_id": {
+      "anyOf": [
+        {
+          "format": "uuid",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "notification_logs": {
+      "items": {
+        "properties": {
+          "channel_type": {
+            "description": "Known values: EMAIL, TELEGRAM, WEBHOOK, SLACK, DISCORD.",
+            "type": "string"
+          },
+          "destination": {
+            "type": "string"
+          },
+          "error": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "event": {
+            "description": "Known values: TRIGGERED, RESOLVED, SSL_EXPIRY.",
+            "type": "string"
+          },
+          "id": {
+            "format": "uuid",
+            "type": "string"
+          },
+          "sent_at": {
+            "type": "string"
+          },
+          "status": {
+            "description": "Known values: PENDING, SENT, FAILED.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "channel_type",
+          "destination",
+          "event",
+          "sent_at",
+          "status",
+          "error"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "renotify_count": {
+      "type": "integer"
+    },
+    "resolved_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "started_at": {
+      "type": "string"
+    },
+    "updated_at": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "started_at",
+    "resolved_at",
+    "cause",
+    "cause_detail",
+    "last_notified_at",
+    "acknowledged_at",
+    "acknowledged_by",
+    "renotify_count",
+    "created_at",
+    "updated_at"
+  ],
+  "type": "object"
+}

First observedv0.5.4Oct 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: explains that only repeat alerts are suppressed while the recovery alert still sends, that the incident is closed by monitor recovery rather than by this call, that a write-scoped key is required, and the exact semantics of double-acknowledgement and acknowledging a resolved incident. These are non-obvious behaviors an agent could not derive from idempotentHint/destructiveHint alone.

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 effect and then layers constraints, auth, and edge-case semantics in four tight sentences. Dense but nearly every clause earns its place; only the trailing return-shape note is arguably redundant given the output schema.

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?

With rich annotations, a fully documented single parameter, and an output schema (the description just points at the get_incident shape), the description covers everything an agent needs: effect, exclusions, auth scope, idempotency, and error behavior.

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 the single parameter's uuid origin and 404 failure mode are fully documented in the schema, so the description adds no parameter detail. Baseline 3 is appropriate when the schema carries the parameter burden.

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+resource ('Mark an open incident as being handled') plus the precise effect (repeat alerts stop, recovery alert still fires). It explicitly disambiguates from the sibling that handles status page incidents, so an agent can route correctly without opening schemas.

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 explicit when-to-use ('when someone is working on the outage'), when-not ('it does not close the incident'), and names the alternative for the adjacent case ('post_status_page_update'). 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