Loading ToolBench
Model Context Protocol server for Uptimepage uptime monitoring platform. Provides tools to read and write monitors, incidents, status pages, and related observability data.
Strong foundation with 27 well-named tools following verb_noun convention (get_, list_, create_, update_, pause_, resume_, acknowledge_, resolve_, publish_, post_, add_, run_). All tools have descriptions (avg 156 chars, within 10-1024 baseline). Input schemas present with type definitions for all parameters. However, output schemas are not documented in the provided source, and several parameter descriptions lack constraint details (enums, ranges, formats). Error handling guidance is minimal. Tool annotations (readOnlyHint, destructiveHint) are declared in features but not visible in schema definitions. Composition is strong, tools are single-responsibility and chainable (e.g., list_monitors → get_monitor → update_monitor). Security posture is good: no credentials in parameters, write operations request confirmation.
Acknowledge an incident: take ownership and halt escalation. Internal/operational only — does NOT post anything to the public status page. Use post_incident_update for customer-facing updates. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.
Add monitors as components to a status page.
Create a monitor for an http, tcp, ping, dns, tls_cert, domain_expiry or heartbeat check. The check is run once before anything is saved and the result is shown to the user along with every setting it would apply; where the client can show a prompt, nothing is created unless they approve; otherwise the monitor is created on the token's scope and the trial result comes back with it. Bind it to alerts as you create it: pass channel_ids from list_notification_channels (this needs the channels:read scope), and if the org has no channel yet, say so rather than leaving a monitor that pages nobody. Leave regions unset unless the user named where they want the check to run from — omitted, it probes from the operator's default set, which is already the intended coverage; naming more regions than the plan allows is refused outright. Request headers and a request body can be set, but a credential must be referenced rather than pasted: write `Bearer {{ my_key }}` and call list_variables for the keys this org has. A URL carrying a username or password is refused, and browser flows cannot be created here — add those in the app. Not read-only.
Create a status page.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Get a single monitor's full configuration, current state, and recent check history') but formal output schema definitions are not visible in source. LLMs cannot plan downstream tool calls or extract specific fields without knowing response structure.
Parameter constraints not formalized. 'state' and 'type' parameters accept enums (e.g., 'state' in list_monitors) but valid values are not declared in schema. Descriptions mention 'Filter by monitor state' without listing valid states. LLMs cannot validate input and may hallucinate invalid values.
create_monitor description is verbose (>500 chars) and mixes multiple concerns: validation, credential handling, region defaults, and alert binding. While comprehensive, it risks overwhelming LLMs. Should split into shorter description + separate parameter-level guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2025-06-18+ | v2 |
Get a single incident's full details including updates and affected components.
Get metrics for an incident over a time window.
Get a single monitor's full configuration, current state, and recent check history.
Get a monitor's incident history with optional time window and pagination.
Org health summary: per-state monitor totals and the worst currently-failing monitors. The one-shot answer to 'what is broken right now?'. Read-only.
Get the org's current usage against plan quotas.
Get a single status page's full configuration and current component states.
List incidents with optional state/severity filters and cursor pagination.
List monitors with optional state/type/tag filters and cursor pagination. Each item carries its current state and last-checked time. Read-only.
List notification channels (email, Slack, PagerDuty, etc.) configured for the org.
List probe regions available for monitor checks.
List status pages with optional filters and cursor pagination.
List all tags used in the org's monitors.
List secret variables (API keys, credentials) available for use in monitor checks.
Pause a monitor (stop its checks until resumed). Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
Post a customer-facing update to an incident on the public status page.
Publish an incident to the public status page.
Resolve an incident (mark the operational state resolved). Internal only — does not post to the public status page. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only.
Resume a paused monitor (restart its checks). Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. Not read-only; idempotent.
Run a check on a monitor immediately and record the result. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. A down result may fire the org's normal alerts. Heartbeat monitors cannot be probed (they wait for your systems to ping them). Not read-only.
Update a component on a status page.
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.
Update a status page's configuration.
Pagination cursors documented but no total count or result limit stated. list_monitors, list_incidents, list_status_pages accept 'cursor' but descriptions do not specify max results per page or whether a 'total' field is returned. Agents cannot estimate remaining items or plan batch sizes.
Error recovery guidance absent. Descriptions note confirmation behavior ('Asks for confirmation where the client can show a prompt') but do not explain what happens if confirmation is denied, or what errors are retryable. No guidance for LLM on next steps after failure.