fettle-mcp

Overview Schema Source Related Servers Discussions Admin

Get an incident

get_incident

Read-onlyIdempotent

Fetch a full incident by ID, including all alert attempts, to see who acknowledged it and whether notifications were delivered.

Instructions

Read one incident in full, with every alert sent for it. It has id, monitor_id or heartbeat_id (exactly one is set), started_at, resolved_at, cause, cause_detail, last_notified_at, acknowledged_at, acknowledged_by, renotify_count and notification_logs (each alert attempt: id, channel_type, destination, event TRIGGERED, RESOLVED or SSL_EXPIRY, sent_at, status PENDING, SENT or FAILED, and error). Use it to tell who acknowledged an incident and whether its alerts were delivered. destination is an email address, a Telegram chat id, or only scheme://host/… of a webhook. To find incidents use list_incidents; to stop its reminders use acknowledge_incident.

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.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds valuable context beyond annotations: exactly one of monitor_id or heartbeat_id is set, notification_logs fields with event/status/error semantics, and destination formats. Missing only auth or rate-limit details, which are minor for a read tool.

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 core purpose. The long enumeration of return fields is somewhat redundant with the existing output schema, making the description longer than strictly necessary. Still well-structured and every sentence serves a purpose for an agent.

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 single-parameter read tool with an output schema and rich annotations, the description covers purpose, usage, alternatives, return content, and destination formats. 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 the single required parameter is fully documented in the schema (uuid from list_incidents, 404 for wrong organization). The description adds no parameter-specific syntax or constraints 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.

Purpose5/5

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

States a specific verb 'Read' and resource 'incident' with scope 'in full, with every alert sent for it'. Explicitly distinguishes from siblings by naming list_incidents and acknowledge_incident, so an agent can tell it apart 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?

Explicitly states the use case: 'Use it to tell who acknowledged an incident and whether its alerts were delivered.' Names alternatives: list_incidents to find incidents and acknowledge_incident to stop reminders. Provides both when-to-use and when-to-use-alternatives.

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

Deploy Server