Uptimepage

Retune monitor

update_monitor

DestructiveIdempotent

Change how loudly a monitor is watched: check interval, alert confirmations, recovery notices, reminder interval, tags, group, the multi-region detection quorum, and which notification channels it alerts (channel_ids replaces the whole set, and needs the channels:read scope). It cannot change what the check watches — name, address, assertions, expected status, headers, body, probe regions and owner are refused. A monitor managed by Terraform is refused outright. Shows the old and new value of every field before it runs, where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Input Schema

Name	Required	Description
`id`	Yes	The monitor id (from `list_monitors`).
`tags`	No	Replaces the whole tag list. Read the monitor first: a tag left out of this list is removed. At most 50 tags, each at most 50 characters.
`group_name`	No	Operator-side grouping label. Send `null` to clear it; omit to keep it.
`channel_ids`	No	Replaces the whole set of alerted channels, by id from `list_notification_channels`. Read the monitor first: a channel left out of this list stops being alerted. An empty list silences the monitor.
`interval_secs`	No	Seconds between checks. Held to the plan's floor and the check kind's own floor, whichever is higher.
`region_policy`	No	Detection quorum across probe regions.
`notify_recovery`	No	Whether recovery is announced to the monitor's channels.
`alert_confirmations`	No	Consecutive failing checks before the monitor alerts. Minimum 1. Raising it quietens a flapping monitor at the cost of alerting later.
`recovery_period_secs`	No	Seconds a recovered monitor must stay healthy before its incident closes, 0 to 1800. Raising it folds a flapping monitor's short outages into one incident, at the cost of announcing recovery later.
`renotify_interval_secs`	No	Seconds before the first reminder while an outage stays unacknowledged; each further reminder waits twice as long, up to a day. 0 turns reminders off; otherwise at least 60.

Output Schema

Name	Required	Description	Default
`id`	Yes
`changes`	Yes	What moved. Empty when every value sent already matched the stored one, in which case nothing was written and no confirmation was asked for.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 9, 2026

addedInput schema / properties / recovery_period_secs

Added value: +{
+  "description": "Seconds a recovered monitor must stay healthy before its incident\ncloses, 0 to 1800. Raising it folds a flapping monitor's short outages\ninto one incident, at the cost of announcing recovery later.",
+  "format": "uint32",
+  "minimum": 0,
+  "type": [
+    "integer",
+    "null"
+  ]
+}

AddedSep 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that channel_ids and tags are full replacements (not merges), that Terraform-managed monitors are refused outright, and that the client previews old vs. new values before running or else acts on the token's scope. This is exactly the kind of consequence detail a destructiveHint=true mutation needs.

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 the core purpose and tightly organized into editable fields, refused fields, and execution behavior. It is dense but every clause carries operational weight; only the density of the long opening sentence slightly taxes readability.

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 a 10-parameter mutation with an output schema present, the description covers scope requirements, refusal conditions, replacement semantics, and preview behavior, leaving nothing an agent needs to call it correctly unaddressed.

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, but the description adds real meaning on top of it: replacement vs. additive semantics for channel_ids and tags, the scope requirement, and the explicit list of non-editable parameters that error rather than no-op. This meaningfully compensates beyond what the schema states.

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 precise verb (change) and resource (monitor), then enumerates exactly which fields are mutable (interval, alert confirmations, recovery, renotify, tags, group, region quorum, channels) and which are refused. This distinguishes it clearly from create_monitor, pause_monitor, and set_monitor_state without needing to name them.

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 strong when/when-not guidance: it names the preconditions (channels:read scope for channel_ids, Terraform-managed monitors are refused) and the excluded field set. It does not explicitly route to a sibling for the refused operations, but the constraints are clear enough to prevent misuse.

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.