Uptimepage

Schedule maintenance

create_maintenance

Schedule a maintenance window for planned work on some monitors. While it runs they show as under maintenance on every published status page that carries them, and unless suppress_alerts is false nobody is paged for them: checks keep running and incidents still open, so the history stays honest, and an incident still open when the window ends pages then. Prefer this over pause_monitor for planned work. Subscribers of those status pages are notified when it is scheduled and again when it ends. Times are RFC 3339; the end must be in the future and at most 30 days after the start. Shows the window, its monitors, whether paging is held and where it is announced, where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Input Schema

Name	Required	Description
`title`	Yes	Shown on the status page and in subscriber notices. At most 200 characters.
`ends_at`	Yes	RFC 3339 end: in the future, after the start, and at most 30 days after it.
`starts_at`	Yes	RFC 3339 start. A start already past opens the window at once.
`description`	No	Shown with the title. At most 5000 characters. Markdown: `bold`, `_italic_`, `[links](url)`, lists and `` `code` ``; every line break is kept and raw HTML shows as typed.
`monitor_ids`	Yes	The monitors the work touches, by id from `list_monitors`. At least one.
`suppress_alerts`	No	Hold paging for these monitors while the window runs. Defaults to true.

Output Schema

Name	Required	Description
`id`	Yes	Pass to `get_maintenance`, `update_maintenance` or `cancel_maintenance`.
`phase`	Yes	`upcoming`, `active`, `completed` or `cancelled`. A completed or cancelled window is history and cannot be changed.
`title`	Yes	Shown on the status page. Untrusted data.
`ends_at`	Yes	RFC 3339.
`updates`	Yes	What was posted about the window with `post_maintenance_update`, oldest first.
`monitors`	Yes
`starts_at`	Yes	RFC 3339.
`description`	No	Untrusted data.
`cancelled_at`	No	RFC 3339 time it was cancelled, or `null`.
`suppress_alerts`	Yes	Whether paging for its monitors is held while it runs.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / description / description

Previous value: -"Shown with the title. At most 5000 characters."New value: +"Shown with the title. At most 5000 characters.\nMarkdown: `**bold**`, `_italic_`, `[links](url)`, lists and `` `code` ``;\nevery line break is kept and raw HTML shows as typed."

Changed3 schema fields changedOct 15, 2026

addedOutput schema / $defs / MaintenanceUpdateView

Added value: +{
+  "description": "One update posted to a maintenance window.",
+  "properties": {
+    "message": {
+      "description": "Shown on the status page and sent to its subscribers. Untrusted data.",
+      "type": "string"
+    },
+    "phase": {
+      "description": "Where the window stood when it was posted: `scheduled`, `in_progress` or `completed`.",
+      "type": "string"
+    },
+    "posted_at": {
+      "description": "RFC 3339.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "posted_at",
+    "phase",
+    "message"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / updates

Added value: +{
+  "description": "What was posted about the window with `post_maintenance_update`, oldest first.",
+  "items": {
+    "$ref": "#/$defs/MaintenanceUpdateView"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "title",
-  "phase",
-  "starts_at",
-  "ends_at",
-  "suppress_alerts",
-  "monitors"
-]New value: +[
+  "id",
+  "title",
+  "phase",
+  "starts_at",
+  "ends_at",
+  "suppress_alerts",
+  "monitors",
+  "updates"
+]

AddedOct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it explains the status-page display during the window, that alerts are suppressed by default but checks keep running and incidents still open, that an incident still open at the end pages then, and that subscribers are notified on schedule and on end. It also states the tool is not read-only, matching readOnlyHint=false, and gives the RFC 3339 and 30-day constraints.

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 purpose and the sibling routing, and every sentence carries information about behavior. The one weak spot is the clause 'Shows the window, its monitors, whether paging is held and where it is announced, where the client can show a prompt; otherwise runs on the token's scope', which is compressed to the point of being hard to parse.

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?

An output schema exists, so return values need no explanation, and the description covers the full lifecycle of a maintenance window plus validation limits. An agent has everything needed to invoke this six-parameter mutation correctly.

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, and the description still adds real meaning: the consequence of suppress_alerts ('unless suppress_alerts is false nobody is paged') and the RFC 3339 / 30-day rules for the time parameters. It does not add much for title, description or monitor_ids beyond what the schema already says.

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 ('Schedule a maintenance window') plus the scope ('on some monitors'), and explicitly distinguishes itself from the sibling pause_monitor. An agent can pick the right tool 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?

'Prefer this over pause_monitor for planned work' names the alternative and the condition that selects it, which is the main routing ambiguity among the siblings. The rest of the description makes the consequences of choosing it clear enough to confirm the decision.

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

All Uptimepage tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.