Uptime monitoring: create and manage HTTP, API, SSL, ping, port and domain checks
Inferred from the transports this listing declares (streamable-http). A client not listed here hasn’t been ruled out — it just isn’t something Forge can confirm.
Verification confirms publisher identity (repo ownership), not code safety. The security scan covers known CVEs and suspicious install scripts.
Read from a real MCP initialize → tools/list handshake against the declared endpoint. No tool was ever invoked — tools/list is the read-only introspection call the protocol defines for this. It reflects what the server advertised at that moment; a hosted endpoint is not pinned to any version and can change without notice.
https://mcp.uptybots.com/mcp15 tools · 664mslist_monitorsList 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…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…
| Parameter | Type | Description |
|---|---|---|
| type | string | Return only monitors of this type. Omit for all types. |
| status | string | Return only monitors in this state. "pending" means created but not yet checked; "paused" means checking is switched off, so it is neither up nor down. |
| page | integer | Page number, 1-based. Defaults to 1. |
get_monitorRead 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…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…
| Parameter | Type | Description |
|---|---|---|
| id* | integer | Monitor id, as returned by list_monitors. |
create_http_monitorWatch 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 pro…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 pro…
url: Links to undeclared domain: example.com| Parameter | Type | Description |
|---|---|---|
| name* | string | Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname. |
| url* | string | Full URL including scheme, for example https://example.com/health. A bare hostname is not accepted here - use create_ping_monitor for that. |
| frequency | integer | Check frequency in minutes (1-1440, default 5) |
| requestTimeout | integer | Request timeout in seconds (1-60, default 30) |
| isActive | boolean | Start monitoring immediately (default true) |
create_api_monitorWatch 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 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.
url: Links to undeclared domain: api.example.com| Parameter | Type | Description |
|---|---|---|
| name* | string | Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname. |
| url* | string | Full endpoint URL including scheme, for example https://api.example.com/v1/status. |
| frequency | integer | Check frequency in minutes (1-1440, default 5) |
| requestTimeout | integer | Request timeout in seconds (1-60, default 30) |
| isActive | boolean | Start monitoring immediately (default true) |
create_ping_monitorWatch 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…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…
| Parameter | Type | Description |
|---|---|---|
| name* | string | Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname. |
| url* | string | Hostname or IP address, with no scheme and no port, for example example.com or 1.2.3.4. |
| frequency | integer | Check frequency in minutes (1-1440, default 5) |
| isActive | boolean | Start monitoring immediately (default true) |
create_port_monitorWatch one TCP or UDP port on a host and report it up only when the service behind it actually answers. This is the type for game servers, databases, mail and anything else that speaks its own protocol rather than HTTP - Minecraft, Rust, CS2, FiveM, Postgres, Redis, SMTP. The port must be given as p…Watch one TCP or UDP port on a host and report it up only when the service behind it actually answers. This is the type for game servers, databases, mail and anything else that speaks its own protocol rather than HTTP - Minecraft, Rust, CS2, FiveM, Postgres, Redis, SMTP. The port must be given as p…
| Parameter | Type | Description |
|---|---|---|
| name* | string | Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname. |
| url* | string | Host and port separated by a colon, for example example.com:443 or 1.2.3.4:25565. The port is required; without it the monitor cannot be created. |
| protocol | string | TCP is the default and fits most services. Use UDP for game servers and anything else that does not answer on TCP; on UDP the port counts as up only when the s… |
| frequency | integer | Check frequency in minutes (1-1440, default 5) |
| isActive | boolean | Start monitoring immediately (default true) |
create_ssl_monitorWatch a TLS certificate: whether it is valid, who issued it, and how many days remain before it expires. This is about the certificate, not about the site being reachable - pair it with create_http_monitor when you want both. Note that such a monitor carries two independent states, one for reachabi…Watch a TLS certificate: whether it is valid, who issued it, and how many days remain before it expires. This is about the certificate, not about the site being reachable - pair it with create_http_monitor when you want both. Note that such a monitor carries two independent states, one for reachabi…
| Parameter | Type | Description |
|---|---|---|
| name* | string | Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname. |
| url* | string | Domain whose certificate to inspect, for example example.com. No scheme, no path. |
| isActive | boolean | Start monitoring immediately (default true) |
create_domain_monitorWatch a domain registration and report how long is left before it lapses, read from WHOIS. This catches the failure no uptime check can see: everything works perfectly right up to the day the domain expires. Distinct from create_ssl_monitor, which watches the certificate rather than the registratio…Watch a domain registration and report how long is left before it lapses, read from WHOIS. This catches the failure no uptime check can see: everything works perfectly right up to the day the domain expires. Distinct from create_ssl_monitor, which watches the certificate rather than the registratio…
| Parameter | Type | Description |
|---|---|---|
| name* | string | Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname. |
| url* | string | Registrable domain, for example example.com. Use the registered domain rather than a subdomain: a subdomain has no registration date of its own. |
| isActive | boolean | Start monitoring immediately (default true) |
pause_monitorStop checking a monitor without deleting it. History and configuration survive, and resume_monitor puts it back to work. Use this around planned maintenance so the downtime does not land in the uptime figures or fire alerts. A paused monitor reports neither up nor down, so it is easy to forget one…Stop checking a monitor without deleting it. History and configuration survive, and resume_monitor puts it back to work. Use this around planned maintenance so the downtime does not land in the uptime figures or fire alerts. A paused monitor reports neither up nor down, so it is easy to forget one…
| Parameter | Type | Description |
|---|---|---|
| id* | integer | Monitor id to pause, as returned by list_monitors. |
resume_monitorStart checking a paused monitor again, with the configuration it had before. The first check runs immediately rather than after the usual interval, so the current state is known within moments. Safe to call on a monitor that is already running.Start checking a paused monitor again, with the configuration it had before. The first check runs immediately rather than after the usual interval, so the current state is known within moments. Safe to call on a monitor that is already running.
| Parameter | Type | Description |
|---|---|---|
| id* | integer | Monitor id to resume, as returned by list_monitors. |
delete_monitorprivilegedPermanently delete a monitor together with its entire check history, incidents and statistics. This cannot be undone and there is no trash to restore from. Confirm with the user before calling it, and prefer pause_monitor whenever the intent is only to stop the checking for a while.Permanently delete a monitor together with its entire check history, incidents and statistics. This cannot be undone and there is no trash to restore from. Confirm with the user before calling it, and prefer pause_monitor whenever the intent is only to stop the checking for a while.
| Parameter | Type | Description |
|---|---|---|
| id* | integer | Monitor id to delete, as returned by list_monitors. Deletion is irreversible. |
get_incidentsRead the downtime history of one monitor: when each outage began, when it ended, how long it lasted and what the failure actually was - HTTP status, error text, and which probe saw it. This is the tool for "what happened" and "how often does this break". For the shape of response times around an ou…Read the downtime history of one monitor: when each outage began, when it ended, how long it lasted and what the failure actually was - HTTP status, error text, and which probe saw it. This is the tool for "what happened" and "how often does this break". For the shape of response times around an ou…
| Parameter | Type | Description |
|---|---|---|
| monitorId* | integer | Monitor id, as returned by list_monitors. |
| page | integer | Page number, 1-based. Defaults to 1. |
get_stats_hourlyResponse time and uptime for one monitor broken down by hour, with min, max, average and p95 per bucket. Use it to see the shape of a problem: whether a service degrades before it fails, whether outages cluster at a particular time of day, or how long a single incident really lasted. Best over hour…Response time and uptime for one monitor broken down by hour, with min, max, average and p95 per bucket. Use it to see the shape of a problem: whether a service degrades before it fails, whether outages cluster at a particular time of day, or how long a single incident really lasted. Best over hour…
| Parameter | Type | Description |
|---|---|---|
| monitorId* | integer | Monitor id, as returned by list_monitors. |
| dateFrom | string | First day to include, as YYYY-MM-DD. Defaults to the start of available history. |
| dateTo | string | Last day to include, as YYYY-MM-DD. Defaults to today. |
| page | integer | Page number, 1-based. Defaults to 1. |
get_stats_dailyResponse time and uptime for one monitor aggregated per day, with min, max, average and p95. This is the tool for reports and trends over weeks or months, and for comparing one monitor against another over the same window. When a single day looks wrong, zoom into it with get_stats_hourly.Response time and uptime for one monitor aggregated per day, with min, max, average and p95. This is the tool for reports and trends over weeks or months, and for comparing one monitor against another over the same window. When a single day looks wrong, zoom into it with get_stats_hourly.
| Parameter | Type | Description |
|---|---|---|
| monitorId* | integer | Monitor id, as returned by list_monitors. |
| dateFrom | string | First day to include, as YYYY-MM-DD. Defaults to the start of available history. |
| dateTo | string | Last day to include, as YYYY-MM-DD. Defaults to today. |
| page | integer | Page number, 1-based. Defaults to 1. |
get_notificationsRead the alerts this account has sent, across email, Telegram, webhook and the web interface, with the delivery outcome of each. Use it to answer "was I actually told about this outage" and to find a channel that is silently failing - a monitor can be detecting downtime correctly while its webhook…Read the alerts this account has sent, across email, Telegram, webhook and the web interface, with the delivery outcome of each. Use it to answer "was I actually told about this outage" and to find a channel that is silently failing - a monitor can be detecting downtime correctly while its webhook…
| Parameter | Type | Description |
|---|---|---|
| channel | string | Return only alerts sent through this channel. Omit for all channels. |
| status | string | Return only alerts with this delivery status. |
| page | integer | Page number, 1-based. Defaults to 1. |
15 of 15 tools published a description.
Tool names and descriptions are written by the publisher and shown verbatim as inert text. They are the strings an MCP client passes to a model, so Forge scans them for prompt-injection patterns — any finding appears with the security scan above. “Privileged” is a keyword match on the tool name, not an audit of what the tool does: a benign-sounding name can still do anything.
Uptime monitoring: create and manage HTTP, API, SSL, ping, port and domain checks
Linked names open Forge’s index of every entry observed exposing that tool. Browse all indexed tools.
This entry publishes no npm package, so Forge has no dependency tree for it. That is a gap in coverage — not a statement that it has no dependencies.