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

TableJSON 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.
`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

TableJSON 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.
`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.

AddedOct 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond annotations: explains that checks still run and incidents still open, that an open incident at window end pages then, that subscribers are notified at schedule and end, and the time constraints (RFC 3339, future, ≤30 days). Annotations only give readOnly=false, idempotent=false, destructive=false, so the description carries meaningful behavioral context.

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-loads purpose and effect, then alternatives, then constraints. Dense but every sentence adds value. Slightly long yet not wasteful.

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?

Output schema exists, so return value explanation is unnecessary. The description covers scope, side effects, notifications, and timing constraints, making it complete for a mutation tool.

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 coverage is 100%, so parameter meanings are documented in the schema. The description adds the suppress_alerts default and time constraints, but these largely duplicate schema descriptions. 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 (schedule) and resource (maintenance window), plus the effect on monitors and status pages. Explicitly distinguishes from pause_monitor, naming the sibling and giving the selection condition.

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 ('planned work') and when-not via the alternative ('Prefer this over pause_monitor for planned work'). Also states the paging-hold default condition, giving the agent clear routing guidance.

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.