Uptimepage

Post maintenance update

post_maintenance_update

Post an update to a maintenance window: say the work is running late, that it finished, or what changed. Works on an upcoming, running or completed window (a completed window is read-only otherwise, so this is how to add a closing note), not on a cancelled one. The update shows on the status pages that show the window and goes to their email and webhook subscribers; it cannot be edited or removed. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Input Schema

Name	Required	Description	Default
`id`	Yes	The window id (from `list_maintenance`).
`message`	Yes	What readers should know now, up to 2000 characters: the work runs late, it finished, or what changed. Write it for the people reading the status page, and give any time with its zone. Markdown: `bold`, `_italic_`, `[links](url)`, lists and `` `code` ``; every line break is kept and raw HTML shows as typed.

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 / message / description

Previous value: -"What readers should know now, up to 2000 characters: the work runs\nlate, it finished, or what changed. Write it for the people reading\nthe status page, and give any time with its zone."New value: +"What readers should know now, up to 2000 characters: the work runs\nlate, it finished, or what changed. Write it for the people reading\nthe status page, and give any time with its zone.\nMarkdown: `**bold**`, `_italic_`, `[links](url)`, lists and `` `code` ``;\nevery line break is kept and raw HTML shows as typed."

AddedOct 15, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description explains the downstream effects: updates appear on status pages and go to email and webhook subscribers, and cannot be edited or removed. It also discloses the confirmation-prompt behavior and token-scope fallback, which are important operational details for a non-read-only action.

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?

The description is front-loaded with the core action and then adds scope, effects, and confirmation behavior in compact sentences. Every sentence provides useful operational context without repetition.

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?

The description covers the tool's action, valid window states, user-visible effects, immutability, and confirmation behavior. With an output schema present and 100% parameter documentation, no critical information is missing for correct invocation.

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%, so the schema already documents both parameters in detail, including the message length and Markdown support. The description reinforces the message intent but does not add syntax or constraints beyond the schema.

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?

The description uses a specific verb and resource: posting an update to a maintenance window, with concrete examples of what the update can say. It also distinguishes this from window-editing operations by noting that a completed window is read-only otherwise, so this is the way to add a closing note.

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?

It clearly states when the tool works: upcoming, running, or completed windows, and explicitly excludes cancelled windows. It does not explicitly name update_maintenance or cancel_maintenance as alternatives, but the state-based guidance is clear enough for correct use.

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.