Loading ToolBench
MCP server for UptyBots — connect AI assistants to your uptime monitors
UptyBots demonstrates solid tool design with consistent naming (verb_noun pattern), comprehensive descriptions (avg 180 chars), and explicit input schemas using Zod. All 15 tools are properly registered with descriptions and parameter types. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are correctly applied. Output schemas are declared for structured responses. However, some parameter descriptions lack actionable constraints (e.g., frequency/timeout ranges stated in description but not enforced in schema validation visible in code). Error handling returns structured responses but lacks recovery guidance (e.g., 'User not found, try search_users'). Parameter descriptions are strong but could be more concise (some exceed 200 chars). No evidence of batch operations or natural-identifier acceptance (e.g., monitor names alongside IDs).
Watch a JSON or REST endpoint where the response itself matters, not only that the host answered. Use it for health endpoints, webhooks and any API whose failure would be invisible to a plain page check. For an ordinary web page, create_http_monitor is lighter and enough.
Watch a domain name: when it will expire and whether the registrar still holds it. Use it for any domain you must not let lapse. The check runs daily and reports the soonest expiry date it finds across all the TLDs you own.
Watch a web page or endpoint over HTTP/HTTPS and treat an unexpected status code, a timeout or a connection failure as downtime. This is the right type for anything a browser would open. Choose create_api_monitor instead when the response body matters as well as the status code. Checks run from probes in several countries. Call list_monitors first so you do not create a duplicate of an existing url.
Watch a host with ICMP ping: it answers whether the machine is reachable at all, and reports round-trip time and packet loss. Use it for servers, routers and anything with no web service on top. It says nothing about whether a site or service on that host is working - a box can ping perfectly while its web server is down. Some hosting providers block ICMP, in which case the monitor will read as down.
Error responses lack recovery guidance. Errors return only message text (e.g., 'Error: 404') without actionable next steps for the LLM (e.g., 'Monitor not found. Call list_monitors to find the correct ID').
Parameter constraints (frequency 1-1440, timeout 1-60) are documented in descriptions but not enforced in visible Zod schema definitions. Schema shows z.number().int().min(1).max(1440) for frequency but update_monitor schema lacks these bounds.
No batch operations offered. Agents calling create_http_monitor in a loop (e.g., to monitor 10 URLs) must make 10 sequential calls instead of one batch call, wasting tokens and latency.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2025-06-18+ | v2 |
Watch a TCP port: whether a service is listening, and how long it takes to answer. Use it for databases, caches, message queues and any other service that does not speak HTTP. The check runs from several countries.
Watch an SSL certificate: when it will expire, whether the chain is complete, and whether the domain matches. Use it for any certificate you must not let lapse - a web server, mail server, or any other service. The check runs from several countries and reports the soonest expiry date it finds. Wildcard certificates are supported.
Delete a monitor and all its history. This is permanent and cannot be undone. Use toggle_monitor to pause instead if you might want to resume checking later.
List the downtime incidents for a monitor: when each started, how long it lasted, and the error message. Newest first, 30 per page. An incident is a continuous period of downtime; if a monitor goes down, comes back up, and goes down again, that is two incidents. Use this to understand what went wrong and when.
Read one monitor in full: its configuration, current status, and the type-specific detail the list view omits - expected status codes for HTTP, port and protocol for PORT, certificate or registration expiry date for SSL and DOMAIN. Use it after list_monitors when the answer depends on how the check is configured, for instance whether a timeout is too tight or which port is actually being watched.
List the notifications sent to you: when each was sent, which monitor triggered it, and whether it was a down alert or an up alert. Newest first, 30 per page. Use this to see what alerts have fired and whether they reached you.
Daily uptime statistics for a monitor: the percentage of checks that succeeded on each day, and the number of incidents that started on that day. Useful for spotting patterns and for reporting. Newest first, 30 per page.
Hourly uptime statistics for a monitor: the percentage of checks that succeeded in each hour, and the number of incidents that started in that hour. Useful for spotting patterns - for instance, whether downtime clusters around a particular time of day. Newest first, 30 per page.
List the monitors on the account, newest first, 30 per page. Each entry carries the id needed by every other tool, plus name, url, type, current status, check frequency and the uptime percentage over the last 24 hours. Start here when the request names a monitor by name rather than by id, and when asked what is broken - filtering by status "down" answers that in one call. Returns an empty list rather than an error when nothing matches.
Pause or resume a monitor: set isActive to false to stop checking, true to start again. Paused monitors do not count as down - they are simply not checked. Use this instead of delete_monitor when you expect to resume checking later.
Change a monitor's name, url, check frequency or request timeout. Only the fields you supply are changed; the rest stay as they were. Use get_monitor first if you need to know the current values.
Tools require monitor IDs but do not accept human-friendly names. Users say 'Get status of my health check', but the agent must first call list_monitors to find the ID, then call get_monitor. A name-based lookup would reduce round-trips.
Destructive operation (delete_monitor) lacks confirmation or dry-run support. Agents can permanently delete monitors without a confirmation step, risking accidental data loss.