fettle-mcp

Overview Schema Source Related Servers Discussions Admin

Create a maintenance window

create_maintenance_window

Schedule one-time or recurring maintenance windows to silence alerts for selected monitors or an entire organization during deploys and planned downtime.

Instructions

Create a one-time or recurring maintenance window that silences alerts for some or all monitors. While a window is in effect its monitors keep being checked, but no incident opens and no alert goes out. Use it around a deploy or reboot instead of pause_monitor; it does not cover heartbeats (use pause_heartbeat). For a recurring schedule run preview_maintenance_window first. Requires a key with the write scope. The plan caps how many windows exist (403 past it or when the plan has none; see max_maintenance_windows in get_plan_usage). An invalid argument or schedule is a 422 naming it. Returns the window. Example: {"name": "Deploy", "scope": "MONITOR", "monitor_ids": [""], "dtstart": "2026-10-14T22:00:00", "duration_minutes": 30}

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Display name, 1 to 255 characters.
`rrule`	No	Repeats the window: one iCal RRULE without the RRULE: prefix, at most 1024 characters, for example FREQ=WEEKLY;BYDAY=SU;BYHOUR=3. Hourly, minutely and secondly frequencies are refused. Omit it for a one-time window.
`scope`	Yes	ORG covers every monitor of the organization and ignores monitor_ids; MONITOR covers only monitor_ids.
`dtstart`	Yes	The first start, an ISO 8601 date-time in the wall-clock time of timezone, for example 2026-10-14T22:00:00. A UTC offset or Z is a 422.
`enabled`	No	Default true; false stores the window without effect.
`timezone`	No	IANA zone name such as Europe/Berlin, at most 64 characters. The schedule repeats in it, so a weekly 03:00 stays 03:00 across daylight-saving changes. Defaults to the organization's timezone.
`monitor_ids`	No	Monitor uuids from list_monitors, at least one when scope is MONITOR. An id that is not a monitor of this organization is a 404.
`duration_minutes`	Yes	How long each occurrence lasts, 1 to 40320 minutes.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`rrule`	Yes
`scope`	Yes	Known values: MONITOR, ORG.
`dtstart`	Yes
`enabled`	Yes
`timezone`	Yes
`created_at`	Yes
`monitor_ids`	No
`duration_minutes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.6.1Oct 20, 2026

addedInput schema / properties / dtstart / description

Added value: +"The first start, an ISO 8601 date-time in the wall-clock time of timezone, for example 2026-10-14T22:00:00. A UTC offset or Z is a 422."

addedInput schema / properties / duration_minutes / description

Added value: +"How long each occurrence lasts, 1 to 40320 minutes."

addedInput schema / properties / enabled / description

Added value: +"Default true; false stores the window without effect."

addedInput schema / properties / monitor_ids / description

Added value: +"Monitor uuids from list_monitors, at least one when scope is MONITOR. An id that is not a monitor of this organization is a 404."

addedInput schema / properties / name / description

Added value: +"Display name, 1 to 255 characters."

addedInput schema / properties / rrule / description

Added value: +"Repeats the window: one iCal RRULE without the RRULE: prefix, at most 1024 characters, for example FREQ=WEEKLY;BYDAY=SU;BYHOUR=3. Hourly, minutely and secondly frequencies are refused. Omit it for a one-time window."

addedInput schema / properties / scope / description

Added value: +"ORG covers every monitor of the organization and ignores monitor_ids; MONITOR covers only monitor_ids."

addedInput schema / properties / timezone / description

Added value: +"IANA zone name such as Europe/Berlin, at most 64 characters. The schedule repeats in it, so a weekly 03:00 stays 03:00 across daylight-saving changes. Defaults to the organization's timezone."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "created_at": {
+      "type": "string"
+    },
+    "dtstart": {
+      "type": "string"
+    },
+    "duration_minutes": {
+      "type": "integer"
+    },
+    "enabled": {
+      "type": "boolean"
+    },
+    "id": {
+      "format": "uuid",
+      "type": "string"
+    },
+    "monitor_ids": {
+      "items": {
+        "format": "uuid",
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "name": {
+      "type": "string"
+    },
+    "rrule": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "scope": {
+      "description": "Known values: MONITOR, ORG.",
+      "type": "string"
+    },
+    "timezone": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "enabled",
+    "scope",
+    "dtstart",
+    "duration_minutes",
+    "rrule",
+    "timezone",
+    "created_at"
+  ],
+  "type": "object"
+}

First observedv0.5.4Oct 20, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations only cover the safety profile (readOnly=false, idempotent=false, destructive=false), and the description adds substantial behavior beyond that: monitors keep being checked but no incident/alert fires, write-scope auth is required, plan caps produce a 403, and invalid args produce a 422 naming the field. Return value is only named, but an output schema exists. Slight gap is that idempotency/duplicate-creation behavior is not discussed, though the annotation hints it.

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?

Front-loaded with the purpose in sentence one, then behavior, alternatives, auth, error modes, and a worked example in descending priority. Dense but every sentence carries distinct operational information; nothing is redundant with the name or 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?

For an 8-param write tool with annotations and an output schema, the description supplies the missing pieces an agent needs: effect on monitoring, sibling routing, auth scope, quota failure mode, validation failure mode, and a concrete call. Nothing material is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description goes modestly beyond by giving a complete example call that demonstrates the MONITOR-scope + monitor_ids + dtstart + duration_minutes combination and pointing at list_monitors as the id source, which helps the agent assemble a valid request rather than just read field docs.

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 ('Create a ... maintenance window') and immediately qualifies scope ('one-time or recurring', 'some or all monitors') and effect ('silences alerts'). It also distinguishes itself from pause_monitor and pause_heartbeat, so an agent can route correctly without opening a 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?

Explicit when-to-use ('around a deploy or reboot'), explicit alternative ('instead of pause_monitor'), explicit exclusion ('does not cover heartbeats (use pause_heartbeat)'), and a precondition for the recurring case ('run preview_maintenance_window first'). 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