# UptyBots (remote · mcp.uptybots.com)

Uptime monitoring: create and manage HTTP, API, SSL, ping, port and domain checks

- Trust score: 83/100 (high trust)
- Change this week: +2
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-22

> **Recent critical change**: Authorization (2026-08-20). See the changelog below before you install this server.

## Components

- remote · `mcp.uptybots.com`: 83/100 (this document), [markdown](https://verifymcp.io/servers/com-uptybots-monitoring/mcp.md), [page](https://verifymcp.io/servers/com-uptybots-monitoring/mcp)
- npm · `uptybots-mcp-server`: 78/100, [markdown](https://verifymcp.io/servers/com-uptybots-monitoring/uptybots-mcp-server.md), [page](https://verifymcp.io/servers/com-uptybots-monitoring/uptybots-mcp-server)

## Channel facts

- Endpoint: `https://mcp.uptybots.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.4.1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-22.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (delete_monitor).
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 85/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2255 tokens (~150/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 100/100
  - No destabilizing schema changes in the last 30 days.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 15 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the UptyBots MCP server?

UptyBots is a hosted endpoint at https://mcp.uptybots.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http com-uptybots-monitoring 'https://mcp.uptybots.com/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "com-uptybots-monitoring": {
      "url": "https://mcp.uptybots.com/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-uptybots-monitoring": {
      "type": "http",
      "url": "https://mcp.uptybots.com/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.com-uptybots-monitoring]
url = "https://mcp.uptybots.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-uptybots-monitoring": {
      "type": "remote",
      "url": "https://mcp.uptybots.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-uptybots-monitoring --url 'https://mcp.uptybots.com/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-uptybots-monitoring:
    url: "https://mcp.uptybots.com/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "com-uptybots-monitoring": {
      "Transport": "http",
      "Url": "https://mcp.uptybots.com/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-uptybots-monitoring -t streamable-http -u 'https://mcp.uptybots.com/mcp'
```

### Other

```json
{
  "mcpServers": {
    "com-uptybots-monitoring": {
      "type": "http",
      "url": "https://mcp.uptybots.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-19 (score 83, +1)

- [security] Stability: 0.97 → pass

### 2026-09-17 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-15 (score 81, +1)

No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-13 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 77 to 80. That category is still filling its 30-day observation window: 23 days of observed history at the previous scan, 24 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-11 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-09 (score 78, +1)

No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-07 (score 77, +1)

No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-04 (score 76, +1)

No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (15)

### `list_monitors` (~181 tokens)

List monitors

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.

Input parameters:

- `page` (integer): Page number, 1-based. Defaults to 1.
- `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.
- `type` (string): Return only monitors of this type. Omit for all types.

Output parameters:

- `items` (array): The rows on this page.
- `totalItems` (integer|null): Total across all pages, not just this one.

### `get_monitor` (~102 tokens)

Get one monitor

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.

Input parameters:

- `id` (integer, required): Monitor id, as returned by list_monitors.

Output parameters:

- `frequency` (integer): Check interval in minutes.
- `id` (integer): Monitor id, used by every other tool.
- `isActive` (boolean): False while the monitor is paused.
- `name` (string)
- `statusSummary` (string): Current state, for example GOOD or ERROR.
- `type` (string)
- `url` (string)

### `create_http_monitor` (~209 tokens)

Create HTTP monitor

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.

Input parameters:

- `frequency` (integer): Check frequency in minutes (1-1440, default 5)
- `isActive` (boolean): Start monitoring immediately (default true)
- `name` (string, required): Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname.
- `requestTimeout` (integer): Request timeout in seconds (1-60, default 30)
- `url` (string, required): Full URL including scheme, for example https://example.com/health. A bare hostname is not accepted here - use create_ping_monitor for that.

Output parameters:

- `frequency` (integer): Check interval in minutes.
- `id` (integer): Monitor id, used by every other tool.
- `isActive` (boolean): False while the monitor is paused.
- `name` (string)
- `statusSummary` (string): Current state, for example GOOD or ERROR.
- `type` (string)
- `url` (string)

### `create_api_monitor` (~172 tokens)

Create API monitor

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.

Input parameters:

- `frequency` (integer): Check frequency in minutes (1-1440, default 5)
- `isActive` (boolean): Start monitoring immediately (default true)
- `name` (string, required): Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname.
- `requestTimeout` (integer): Request timeout in seconds (1-60, default 30)
- `url` (string, required): Full endpoint URL including scheme, for example https://api.example.com/v1/status.

Output parameters:

- `frequency` (integer): Check interval in minutes.
- `id` (integer): Monitor id, used by every other tool.
- `isActive` (boolean): False while the monitor is paused.
- `name` (string)
- `statusSummary` (string): Current state, for example GOOD or ERROR.
- `type` (string)
- `url` (string)

### `create_ping_monitor` (~193 tokens)

Create ping monitor

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.

Input parameters:

- `frequency` (integer): Check frequency in minutes (1-1440, default 5)
- `isActive` (boolean): Start monitoring immediately (default true)
- `name` (string, required): Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname.
- `url` (string, required): Hostname or IP address, with no scheme and no port, for example example.com or 1.2.3.4.

Output parameters:

- `frequency` (integer): Check interval in minutes.
- `id` (integer): Monitor id, used by every other tool.
- `isActive` (boolean): False while the monitor is paused.
- `name` (string)
- `statusSummary` (string): Current state, for example GOOD or ERROR.
- `type` (string)
- `url` (string)

### `create_port_monitor` (~256 tokens)

Create port monitor

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 part of the url. Set protocol to UDP for game servers; most of them do not answer on TCP at all.

Input parameters:

- `frequency` (integer): Check frequency in minutes (1-1440, default 5)
- `isActive` (boolean): Start monitoring immediately (default true)
- `name` (string, required): Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname.
- `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 server actually replies.
- `url` (string, required): 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.

Output parameters:

- `frequency` (integer): Check interval in minutes.
- `id` (integer): Monitor id, used by every other tool.
- `isActive` (boolean): False while the monitor is paused.
- `name` (string)
- `statusSummary` (string): Current state, for example GOOD or ERROR.
- `type` (string)
- `url` (string)

### `create_ssl_monitor` (~159 tokens)

Create SSL certificate monitor

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 reachability and one for expiry, so a certificate can be days from expiring while the check still reads up.

Input parameters:

- `isActive` (boolean): Start monitoring immediately (default true)
- `name` (string, required): Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname.
- `url` (string, required): Domain whose certificate to inspect, for example example.com. No scheme, no path.

Output parameters:

- `frequency` (integer): Check interval in minutes.
- `id` (integer): Monitor id, used by every other tool.
- `isActive` (boolean): False while the monitor is paused.
- `name` (string)
- `statusSummary` (string): Current state, for example GOOD or ERROR.
- `type` (string)
- `url` (string)

### `create_domain_monitor` (~160 tokens)

Create domain expiry monitor

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 registration; the two expire on different dates and both are worth watching.

Input parameters:

- `isActive` (boolean): Start monitoring immediately (default true)
- `name` (string, required): Label shown in the dashboard and in alerts, up to 50 characters. Something recognisable months later beats the bare hostname.
- `url` (string, required): Registrable domain, for example example.com. Use the registered domain rather than a subdomain: a subdomain has no registration date of its own.

Output parameters:

- `frequency` (integer): Check interval in minutes.
- `id` (integer): Monitor id, used by every other tool.
- `isActive` (boolean): False while the monitor is paused.
- `name` (string)
- `statusSummary` (string): Current state, for example GOOD or ERROR.
- `type` (string)
- `url` (string)

### `pause_monitor` (~86 tokens)

Pause monitor

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 is off.

Input parameters:

- `id` (integer, required): Monitor id to pause, as returned by list_monitors.

Output parameters:

- `frequency` (integer): Check interval in minutes.
- `id` (integer): Monitor id, used by every other tool.
- `isActive` (boolean): False while the monitor is paused.
- `name` (string)
- `statusSummary` (string): Current state, for example GOOD or ERROR.
- `type` (string)
- `url` (string)

### `resume_monitor` (~72 tokens)

Resume monitor

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.

Input parameters:

- `id` (integer, required): Monitor id to resume, as returned by list_monitors.

Output parameters:

- `frequency` (integer): Check interval in minutes.
- `id` (integer): Monitor id, used by every other tool.
- `isActive` (boolean): False while the monitor is paused.
- `name` (string)
- `statusSummary` (string): Current state, for example GOOD or ERROR.
- `type` (string)
- `url` (string)

### `delete_monitor` (~85 tokens)

Delete monitor

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.

Input parameters:

- `id` (integer, required): Monitor id to delete, as returned by list_monitors. Deletion is irreversible.

Output parameters:

- `message` (string)
- `success` (boolean)

### `get_incidents` (~119 tokens)

Get incidents

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 outage, follow up with get_stats_hourly.

Input parameters:

- `monitorId` (integer, required): Monitor id, as returned by list_monitors.
- `page` (integer): Page number, 1-based. Defaults to 1.

Output parameters:

- `items` (array): The rows on this page.
- `totalItems` (integer|null): Total across all pages, not just this one.

### `get_stats_hourly` (~175 tokens)

Get hourly statistics

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 hours or days; for weeks and months use get_stats_daily instead, which returns far fewer rows.

Input parameters:

- `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.
- `monitorId` (integer, required): Monitor id, as returned by list_monitors.
- `page` (integer): Page number, 1-based. Defaults to 1.

Output parameters:

- `items` (array): The rows on this page.
- `totalItems` (integer|null): Total across all pages, not just this one.

### `get_stats_daily` (~152 tokens)

Get daily statistics

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.

Input parameters:

- `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.
- `monitorId` (integer, required): Monitor id, as returned by list_monitors.
- `page` (integer): Page number, 1-based. Defaults to 1.

Output parameters:

- `items` (array): The rows on this page.
- `totalItems` (integer|null): Total across all pages, not just this one.

### `get_notifications` (~134 tokens)

Get notification history

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 has been rejecting every delivery. Covers the whole account, not one monitor.

Input parameters:

- `channel` (string): Return only alerts sent through this channel. Omit for all channels.
- `page` (integer): Page number, 1-based. Defaults to 1.
- `status` (string): Return only alerts with this delivery status.

Output parameters:

- `items` (array): The rows on this page.
- `totalItems` (integer|null): Total across all pages, not just this one.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-uptybots-monitoring/mcp#diagnostics

## Score history

- 2026-09-22: 83
- 2026-09-21: 83
- 2026-09-20: 83
- 2026-09-19: 83
- 2026-09-18: 82
- 2026-09-17: 82
- 2026-09-16: 81
- 2026-09-15: 81
- 2026-09-14: 80
- 2026-09-13: 80
- 2026-09-12: 79
- 2026-09-11: 79
- 2026-09-10: 78
- 2026-09-09: 78
- 2026-09-08: 77
- 2026-09-07: 77
- 2026-09-06: 76
- 2026-09-05: 76
- 2026-09-04: 76
- 2026-09-03: 75
- 2026-09-02: 75
- 2026-09-01: 74
- 2026-08-31: 74
- 2026-08-30: 73
- 2026-08-29: 73
- 2026-08-28: 72
- 2026-08-27: 72
- 2026-08-26: 71
- 2026-08-25: 70
- 2026-08-24: 69

## Common questions

### What is the UptyBots MCP server?

UptyBots is an MCP server listed in the public MCP registry as com.uptybots/monitoring. Uptime monitoring: create and manage HTTP, API, SSL, ping, port and domain checks. This page covers its hosted endpoint (https://mcp.uptybots.com/mcp).

### Is the UptyBots MCP server safe to use?

UptyBots scores 83 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the UptyBots MCP server expose?

UptyBots exposes 15 tools: list_monitors, get_monitor, create_http_monitor, create_api_monitor, create_ping_monitor, and 10 more. Their descriptions and schemas cost roughly 2,255 tokens of context every time the server is loaded.

### Does the UptyBots MCP server require authentication?

No. We connected to UptyBots without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the UptyBots MCP server still maintained?

UptyBots is still listed as active in the MCP registry. We last reached this channel on 22 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://mcp.uptybots.com/mcp
- Website: https://uptybots.com/docs/mcp
- Changelog RSS feed: https://verifymcp.io/servers/com-uptybots-monitoring/mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-uptybots-monitoring/mcp.json
- HTML version of this page: https://verifymcp.io/servers/com-uptybots-monitoring/mcp