UptyBots MCP Server

by uptybots Your server? Claim it

answering

UptyBots is answering right now. Last checked 12 min ago. 35 installs a week from npm. It exposes 15 tools.

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

Installs per day peak 22 · avg 8 · -21% w/w

a month agotoday

Uptime history 60 days of history · worst day 93%

60 days agonow

100.0%

Uptime 24h

92 of 92 checks

Tools

read from the server

433 ms

Response time

average over 24h

Installs / week

npm and PyPI

What changed 37

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 20 August 2026. No other catalogue keeps this.

21 Aug 4 tools changed the parameters they ask for get_incidents, get_notifications, get_stats_daily and 1 more

21 Aug a tool changed version3 times that day

20 Aug 15 tool descriptions were rewritten create_api_monitor, create_domain_monitor, create_http_monitor and 12 more

20 Aug 15 tools changed the parameters they ask for create_api_monitor, create_domain_monitor, create_http_monitor and 12 more

and 2 more, back to 20 August 2026

Nothing serious here today

Today is the operative word: we check UptyBots every 15 minutes and re-read its code on every release. Watch it and you find out the day that stops being true.

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 12 min ago.

Claude Code Claude Desktop Codex Cursor VS Code

run in your terminal

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

~/Library/Application Support/Claude/claude_desktop_config.json

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

~/.codex/config.toml

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

.cursor/mcp.json

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

.vscode/mcp.json

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

This one needs environment variables set before it will start: UPTYBOTS_API_KEY (API key from Account -> API Keys on uptybots.com. Starts with upty_.), UPTYBOTS_API_URL (Base URL of the API. Defaults to https://uptybots.com; only needed for self-checks against another environment.). The author declared them in the registry entry; get the values from the project itself.

Available tools 15

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

monitor

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.

get_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.

stats

get_stats_daily

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.

get_stats_hourly

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.

api

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.

domain

create_domain_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.

http

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.

incidents

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.

monitors

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.

notifications

get_notifications

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.

pause

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.

ping

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.

port

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.

resume

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.

ssl

create_ssl_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.

Endpoints

URL	Transport	State	Latency	Checked
https://mcp.uptybots.com/mcp	streamable-http	answering	457 ms	12 min ago

Alternatives to UptyBots

same job, measured the same way

Upcheck

by upcheck

Monitor website uptime, SSL certificates, DNS, domain expiry and page changes, and manage alerts.

answering

SolidPing

by fclairamb

Self-hostable uptime monitoring: create checks, read incidents, manage status pages.

answering

Agent Health

by autonet

Free owned-agent uptime monitoring, DNS domain proof, signed alerts and opt-in endpoint checks.

44 tools answering

Exit1 Uptime Monitoring

by exit1

Set up uptime monitoring from your editor: create checks, alerts, and query uptime. Can sign you up.

335 installs/wk answering

Sentinel

by rootstuff

Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.

answering

HostTracker

by hosttracker

Website uptime monitoring: run checks from 300+ locations, manage monitors, alerts and incidents

65 tools answering

Tá Rodando

by com-tarodando

Uptime monitoring and public status page: HTTP monitors, down/up alerts and incidents.

answering

SutramX

by sutramx

SutramX uptime monitoring: monitors, check results, incidents, status pages and uptime/SLO reports.

643 installs/wk local only

UptyBots — questions

Answers built from our own checks of this server.

What can UptyBots do?

It exposes 15 tools, read directly from the server on our last check. Among them: create_api_monitor, create_domain_monitor, create_http_monitor, create_ping_monitor, create_port_monitor, create_ssl_monitor and 9 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →

What is UptyBots mostly used for?

Its tools cluster around monitor and stats. That is what this server is built to work with — the grouping comes from the actual tool names, not from a category we assigned.

Is UptyBots working right now?

We send a real MCP handshake every 15 minutes. Over the last 24 hours 92 of 92 checks got a reply (100.0%), average response time 433 ms. The bar chart above shows every period we have measured.

How do I connect UptyBots?

Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.

Does UptyBots need an API key?

No. UptyBots completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 15 of them are readable on this page. This is what we observed, not what the docs claim.

How fast is UptyBots?

It answers our handshake in 433 ms on average, which is faster than 28% of all working MCP servers we measure. The comparison comes from our own checks across the whole registry, every 15 minutes.

How many people use UptyBots?

The npm package uptybots-mcp-server was installed 35 times in the last week. Week over week that is -21%. We show installs rather than GitHub stars on purpose: a star is a bookmark, an install is someone actually running it.