mcp-uptime-kuma

Create Maintenance

createMaintenance

Schedules a new maintenance window. During maintenance, the monitors in monitorIDs are suppressed and show MAINTENANCE status instead of DOWN. A window created without monitorIDs suppresses nothing.

Instructions

Schedules a new maintenance window. During maintenance, the monitors in monitorIDs are suppressed and show MAINTENANCE status instead of DOWN. A window created without monitorIDs suppresses nothing. Use strategy "manual" for a window you switch on and off with resumeMaintenance / pauseMaintenance.

Input Schema

Name	Required	Description
`cron`	No	Cron expression for when the window starts, e.g. "30 3 * * *" (03:30 daily), for the cron strategy
`title`	Yes	Title of the maintenance window
`active`	No	Whether the window is active (default: true). For a manual window, active means in maintenance right now.
`strategy`	Yes	Scheduling strategy: single=one-time, recurring-interval=every N days, recurring-weekday=specific weekdays, recurring-day-of-month=specific dates, cron=starts on a cron expression and lasts durationMinutes, manual=on whenever active
`timezone`	No	Timezone the dates and times are in (e.g. "America/New_York", "UTC"). Omit to follow the server timezone.
`weekdays`	No	Days of week (0=Sunday … 6=Saturday) for recurring-weekday strategy
`dateRange`	No	[start, end] as local wall-clock times in the window's timezone, e.g. ["2026-10-08T10:00", "2026-10-08T12:00"] — the format Uptime Kuma's own UI stores. Required for single; optional bounds for recurring strategies; ignored for manual.
`timeRange`	No	Daily [{hours, minutes}, {hours, minutes}] start and end. Required for the recurring-* strategies, ignored otherwise.
`monitorIDs`	No	IDs of the monitors this window suppresses. A window with no monitors suppresses nothing. On update this REPLACES the current list; pass [] to detach all.
`daysOfMonth`	No	Days of month (1-31) for recurring-day-of-month strategy
`description`	No	Description or reason for the maintenance
`intervalDay`	No	Interval in days for recurring-interval strategy
`durationMinutes`	No	How long each window lasts, in minutes, for the cron strategy

Output Schema

Name	Required	Description	Default
`ok`	Yes
`msg`	No
`monitorIDs`	No
`maintenanceID`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv0.12.0Oct 12, 2026

changedInput schema / properties / active / description

Previous value: -"Whether the window is active (default: true)"New value: +"Whether the window is active (default: true). For a manual window, active means in maintenance right now."

addedInput schema / properties / cron

Added value: +{
+  "description": "Cron expression for when the window starts, e.g. \"30 3 * * *\" (03:30 daily), for the cron strategy",
+  "type": "string"
+}

changedInput schema / properties / dateRange / description

Previous value: -"Date range as [startISO, endISO] (required for single strategy)"New value: +"[start, end] as local wall-clock times in the window's timezone, e.g. [\"2026-10-08T10:00\", \"2026-10-08T12:00\"] — the format Uptime Kuma's own UI stores. Required for single; optional bounds for recurring strategies; ignored for manual."

removedInput schema / properties / description / default
```
Removed value: -""
```

addedInput schema / properties / durationMinutes

Added value: +{
+  "description": "How long each window lasts, in minutes, for the cron strategy",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / monitorIDs

Added value: +{
+  "description": "IDs of the monitors this window suppresses. A window with no monitors suppresses nothing. On update this REPLACES the current list; pass [] to detach all.",
+  "items": {
+    "minimum": 0,
+    "type": "integer"
+  },
+  "type": "array"
+}

changedInput schema / properties / strategy / description

Previous value: -"Scheduling strategy: single=one-time, recurring-interval=every N days, recurring-weekday=specific weekdays, recurring-day-of-month=specific dates, manual=manually activated"New value: +"Scheduling strategy: single=one-time, recurring-interval=every N days, recurring-weekday=specific weekdays, recurring-day-of-month=specific dates, cron=starts on a cron expression and lasts durationMinutes, manual=on whenever active"

changedInput schema / properties / strategy / enum

Previous value: -[
-  "single",
-  "recurring-interval",
-  "recurring-weekday",
-  "recurring-day-of-month",
-  "manual"
-]New value: +[
+  "single",
+  "recurring-interval",
+  "recurring-weekday",
+  "recurring-day-of-month",
+  "cron",
+  "manual"
+]

changedInput schema / properties / timeRange / description

Previous value: -"Start and end time within the day as [{hours, minutes}, {hours, minutes}]"New value: +"Daily [{hours, minutes}, {hours, minutes}] start and end. Required for the recurring-* strategies, ignored otherwise."

addedInput schema / properties / timeRange / items / properties / hours / maximum
```
Added value: +23
```
addedInput schema / properties / timeRange / items / properties / hours / minimum
```
Added value: +0
```
changedInput schema / properties / timeRange / items / properties / hours / type
```
Previous value: -"number"New value: +"integer"
```
addedInput schema / properties / timeRange / items / properties / minutes / maximum
```
Added value: +59
```
addedInput schema / properties / timeRange / items / properties / minutes / minimum
```
Added value: +0
```
changedInput schema / properties / timeRange / items / properties / minutes / type
```
Previous value: -"number"New value: +"integer"
```

changedInput schema / properties / timezone / description

Previous value: -"Timezone (e.g. \"America/New_York\", \"UTC\"). Defaults to server timezone."New value: +"Timezone the dates and times are in (e.g. \"America/New_York\", \"UTC\"). Omit to follow the server timezone."

addedOutput schema / properties / monitorIDs

Added value: +{
+  "items": {
+    "type": "number"
+  },
+  "type": "array"
+}

Changed2 schema fields changedv0.11.9Aug 21, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv0.0.0-devAug 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the load and does disclose real behavior: monitors in monitorIDs are suppressed and reported as MAINTENANCE rather than DOWN, and a window without monitorIDs suppresses nothing. It stops short of authentication/permission requirements or side effects on existing windows, but the core suppression semantics are communicated.

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?

Three sentences, front-loaded with the core action and effect, then the no-monitor edge case, then the manual-strategy pointer. No filler or restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter create tool with full schema coverage and an output schema, the description covers the essential behavioral contract (suppression semantics, empty monitorIDs, manual strategy). It omits permission/prerequisite context, which is a minor but real gap for a mutation tool with no annotations.

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 description coverage is 100%, so a 3 is the baseline; the description earns an extra point by explaining the cross-parameter relationship between monitorIDs and suppression and by clarifying that 'manual' means the window is on whenever active, which links strategy to the pause/resume tools.

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 ('Schedules a new maintenance window') plus the concrete effect on monitors (suppressed, show MAINTENANCE instead of DOWN). It also names the related siblings resumeMaintenance/pauseMaintenance for the manual strategy, so an agent can distinguish it from updateMaintenance or the on/off tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit guidance for the 'manual' strategy and routes the agent to resumeMaintenance/pauseMaintenance for toggling such windows. It does not, however, contrast createMaintenance with updateMaintenance for existing windows, so the exclusion set is incomplete.

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