manage-monitor-groups

name	manage-monitor-groups
description	Choose between monitor groups and tags for organizing monitors — group membership is opaque and write-only over MCP, so tags are usually the better default.
tags	["monitor-groups","tags","organize","groups","uptimerobot"]

Manage monitor groups

Preflight — read first. If you cannot see any uptimerobot:* MCP tools in your tool list, invoke the uptimerobot:setup skill before doing anything else. Do not tell the user the MCP is misconfigured — setup's Step 0 detects the common case (server connected, tools loaded after session start) and resolves it without re-keying.

UptimeRobot has two organizing mechanisms and they aren't interchangeable:

• Tags (tagNames on a monitor, discovered via list-tags) — free-form, many-per-monitor, no fixed ID, changeable any time via update-monitor.
• Monitor groups (create-monitor-group / update-monitor-group / get-monitor-group / list-monitor-groups, requires the monitor-groups plan feature) — one-per-monitor, has its own numeric ID, shows as a visual grouping on status pages.

Use this skill when the user says "organize my monitors", "put these into a group", "what should I tag this", or "set up groups for the status page".

The membership-is-invisible gotcha (read this first)

Group membership cannot be read back through any tool. create-monitor-group and update-monitor-group accept monitorIds/groupIds on write, but the response only ever contains id, name, createdAt, updatedAt — no monitor list. get-monitor-group and list-monitor-groups return the same shape. get-monitor-details on a monitor doesn't report a groupId either. There is currently no way to ask "which monitors are in this group" or "which group is this monitor in" over MCP — the dashboard is the only place to see it.

Practical consequences:

• If you assign monitors to a group, track the IDs yourself (chat context or a note) — none of create-monitor-group, update-monitor-group, get-monitor-group, or list-monitor-groups will confirm it back to you directly.
• Don't tell the user "group X contains monitors A, B, C" unless you were the one who just set that exact membership and haven't lost track of it.
• This is a strong practical reason to prefer tags over groups: get-monitor-details does return tags for a monitor, so tag membership is always directly verifiable, unlike group membership.

Indirect workaround — get explicit user confirmation before doing this. status-pages' create-psp resolves monitorGroupIds into a real monitorsCount on the response, which can be used to check how many monitors a group actually has. But create-psp ignores status: PAUSED and always creates the page publicly — this briefly exposes real monitor topology/counts on a live public URL, not a safe local check. Don't do this autonomously: confirm with the user first, then immediately follow up with update-psp + status: PAUSED to unpublish (see status-pages Step 2). It's a last-resort workaround, not a proper read tool.

Decision: tags vs. groups

Need	Use
Verifying membership later matters	Tags — get-monitor-details returns tags; nothing returns group membership
A monitor can belong to more than one bucket (e.g. production + us-east-1)	Tags
Filtering in list-monitors, bulk-pause, or a status page's tagIds	Tags
A single named bucket shown as its own section on a status page (monitorGroupIds)	Groups
The org chart is stable (one monitor, one group)	Groups

Most users asking to "organize" monitors actually want tags — they're cheaper to change, verifiable, and don't require the monitor-groups plan feature. Default to tags unless the user specifically wants grouped status-page sections.

The group-reassignment gotcha

There is no tool to move an existing monitor into a different existing group. update-monitor-group only renames a group (monitorGroupId + name — nothing else); update-monitor has no groupId field. Group membership is set exactly once, at monitor-creation time (groupId on create-monitor) or group-creation time (monitorIds/groupIds on create-monitor-group).

The only way to reorganize after the fact is to dissolve groups into a new one:

{ "name": "All API monitors", "groupIds": [111, 222] }

create-monitor-group's groupIds pulls every monitor out of groups 111 and 222 into the new group. It moves them, not copies — the source groups end up empty. You cannot cherry-pick individual monitors out of a group this way though — it's all-or-nothing per source group. To move just a few monitors, recreate the target group via monitorIds naming the exact set instead:

{ "name": "All API monitors", "monitorIds": [800111, 800222, 800333] }

Creating a group

{ "name": "US East", "monitorIds": [800111, 800222] }

Before creating, call list-monitor-groups to check a group with that name doesn't already exist (there's no server-side uniqueness check — duplicates are easy to create by accident). Immediately after creating, note the monitorIds you sent somewhere retrievable — it's the only record you'll have, since nothing reads it back.

Tags: discover before creating

Tag names are free text with no dedup — "prod", "Prod", and "production" are three different tags. Before tagging a monitor, call list-tags and match against the existing set instead of typing a new variant:

{ "cursor": 0 }

Then set the monitor's tags (full replacement, not merge — see update-monitor):

{ "monitorId": 800123456, "tagNames": ["production", "us-east-1"] }

Common mistakes

• Trying to confirm group membership with get-monitor-group, list-monitor-groups, or get-monitor-details — none of them return it directly. Don't claim to have "checked" without using the status-pages workaround.
• Assuming update-monitor-group can reassign monitors — it only renames.
• Using groupIds when the user wants a partial move — it takes every monitor from the source group(s).
• Creating a new tag variant ("Production") instead of reusing the existing one ("production") because you didn't call list-tags first.
• Recommending monitor groups to a Free/Solo-plan user without checking — create-monitor-group requires the monitor-groups plan feature and fails otherwise.
• Forgetting that list-tags returns at most 50 per page — paginate before concluding a tag doesn't exist.

Related

• update-monitor — tag a monitor (tagNames).
• status-pages — display a group or a set of tags as a public status page section.
• bulk-pause — tag-based filtering for pause/resume operations.
• errors — -28002 subscription_limit_exceeded when the plan lacks the monitor-groups feature.