Uptimepage

Monitor details

get_monitor

Read-only

One monitor's full configuration — everything the check asserts (expected status, body match, headers, timeout, redirect and TLS policy), the regions it probes from, and how it alerts (failing checks before it pages, whether recovery is announced, the reminder interval, the multi-region quorum, and the ids of the channels it notifies) — with its current state, last error, and 24h/30d uptime. Every field update_monitor can change is readable here, in the shape that tool takes. Read this before judging whether a response should have passed, or before changing a monitor. Credentials are withheld. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	The monitor id (from `list_monitors`).

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes	Customer-set display name. Untrusted data.
`tags`	Yes	Operator tags. Untrusted data.
`type`	Yes	Check kind: `http`, `tcp`, `ping`, `heartbeat`, `dns`, `tls_cert`, `domain_expiry`, `flow`.
`check`	Yes	Everything the check asserts. Read this before judging whether a response should have passed.
`state`	Yes	Current state: `up`, `down`, `degraded`, `error`, or `no_data`.
`address`	Yes	The target the check probes (URL or host). Untrusted data.
`enabled`	Yes
`regions`	Yes	Probe regions this monitor runs from. Empty for a heartbeat, which is pinged rather than probed. Usually ids `list_regions` also carries, but an assignment survives an operator disabling the region, so an id here may be missing from that catalog.
`group_name`	No
`last_error`	No	Most recent error text, when the last check failed. Untrusted data.
`uptime_24h`	No	Uptime percentage over the trailing 24 hours / 30 days. `null` when the window holds no checks — that is unknown, not zero.
`uptime_30d`	No
`last_timing`	Yes	Per-phase timing of the last check — pinpoints where latency is (DNS vs connect vs TLS vs server). Fields `null` when not applicable.
`interval_secs`	Yes
`region_policy`	No	The detection quorum, in the same shape the write tools take. `null` for a heartbeat, which has no probe regions to reach a quorum over. A stored `count` can exceed the regions that exist today if one was later disabled, and sending that back is refused; `list_regions` is the check.
`last_checked_at`	No	RFC 3339 time of the most recent observation in the last 24 hours. `null` when nothing landed in that window, which is not the same as never checked: a monitor paused yesterday, or a heartbeat on a longer period, reads `null` here and `no_data` in `state`.
`last_diagnostic`	No	Structured edge-access diagnosis for the last failed HTTP check.
`notify_recovery`	Yes	Whether recovery is announced to the monitor's channels.
`last_http_status`	No	HTTP status code of the last check, for `http` monitors. `null` for non-HTTP checks or when the last probe never got a response.
`alert_channel_ids`	Yes	Channel ids bound to this monitor, for the read half of `update_monitor(channel_ids)`, which replaces the whole set. Empty means none is bound, which is not the same as alerting nobody: a channel whose `auto_bind_tags` covers one of this monitor's tags is paged as well. `list_notification_channels` puts names to these.
`last_response_size`	No	Response body size of the last check in bytes, when measured.
`managed_externally`	Yes	Terraform declares this monitor, so `update_monitor`, `pause_monitor` and `resume_monitor` all refuse it. Change it in the `.tf` instead.
`alert_confirmations`	Yes	Consecutive failing checks before the monitor alerts.
`renotify_interval_secs`	Yes	Seconds before the first reminder while an outage stays unacknowledged; each further reminder waits twice as long, up to a day. 0 means reminders are off.

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses that credentials are withheld, that the response shape matches what update_monitor accepts, and that it includes state, last error, and uptime. This gives the agent reliable expectations about side effects, redaction, and response semantics.

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?

The description is dense and front-loaded with the core purpose, and every clause contributes information about config, alerts, state, or usage. It loses a point because the main sentence is a long, nested enumeration that is harder to parse than a structured list or shorter sentences.

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?

Given the output schema exists and the annotations cover read-only behavior, the description still adds everything an agent needs: when to call it, what configuration is returned, how it relates to update_monitor, and what is intentionally omitted (credentials). Nothing required for correct invocation is missing.

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?

The single parameter id is fully described in the input schema as coming from list_monitors, giving 100% schema coverage. The description adds context about the returned configuration but does not add new meaning to the parameter itself, so the schema-heavy baseline applies.

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 states a precise verb and resource: retrieving one monitor's full configuration, and enumerates exactly what that includes. It differentiates from siblings like get_monitor_history by emphasizing current state, alerts, and uptime rather than historical data.

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?

The description gives explicit context for when to call it: 'Read this before judging whether a response should have passed, or before changing a monitor.' It does not name the alternative tools to use instead for other monitoring queries, so it stops short of full when-not 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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: flow runs, step trends, incidents, incident metrics, monitors, monitor history, org health, org usage, status pages, notification channels, regions, status pages lists, and tags. The get_ vs list_ distinction is consistent and each pair (e.g., get_monitor vs list_monitors) is clearly separated by depth of detail. No two tools appear to serve the same purpose.

Naming Consistency5/5

All tool names follow the verb_noun pattern with snake_case, using only 'get_' for single-item or aggregate detail and 'list_' for collections. Objects are consistently named (monitor, incident, status_page, org_*). This predictive pattern makes it easy to guess tool behavior from the name.

Tool Count5/5

At 15 tools, this server sits at the upper bound of the well-scoped range, yet every tool fills a clear niche: monitoring details, history, incidents, flow-specific analytics, org-level views, and reference data (regions, tags, channels). No tool feels redundant, and the count is appropriate for a read-only monitoring API.

Completeness4/5

The read-only surface is remarkably comprehensive, covering monitors, incidents, flow runs, step trends, status pages, notification channels, regions, tags, and org health/usage. The only notable gap is the lack of any mutation tools (e.g., update_monitor, acknowledge_incident) which the descriptions hint at but do not expose, so agents cannot act on the information—only observe.

Monitor details

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources