MCP server

UptyBots Official

com.uptybots/monitoring

Checked 26 Oct 2026, 08:29 UTC · Connected to it and listed its tools

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

Website

At a glance

Type

MCP server

Publisher

uptybots.com (verified by the MCP Registry)

Status

Working at last check

Tools

15

Token cost

About 3,784 tokens per request

Sets up in

Claude Code, Claude Desktop, Codex, Gemini CLI, Cursor, VS Code, Antigravity, ChatGPT, OpenAI API, Grok

Last checked

26 Oct 2026, 08:29 UTC

Connect it to your agent

Add to CursorAdd to VS CodeVS Code Insiders

Opens the app, which shows the server and asks you to confirm. For other apps, copy the setup below.

Claude Code

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

Claude Desktop

Settings → Connectors → Add custom connector, and paste the URL.

Codex (config.toml)

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

Gemini CLI

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

Cursor

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

VS Code

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

Antigravity

agy mcp add monitoring https://mcp.uptybots.com/mcp

ChatGPT

Settings → Apps & Connectors → Advanced settings: turn on Developer mode, then Create a connector and paste the URL. Which plans can do this varies.

OpenAI API (Responses tools)

{"type":"mcp","server_label":"monitoring","server_url":"https://mcp.uptybots.com/mcp","require_approval":"always"}

Grok (xAI API tools)

{"type":"mcp","server_label":"monitoring","server_url":"https://mcp.uptybots.com/mcp"}

Tools

• create_api_monitor ~303 tokens
  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.
• create_domain_monitor ~278 tokens
  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
• create_http_monitor ~357 tokens
  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 prob
• create_ping_monitor ~307 tokens
  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
• create_port_monitor ~392 tokens
  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 pa
• create_ssl_monitor ~269 tokens
  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 reachabil
• delete_monitor Deletes data · ~158 tokens
  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_incidents ~194 tokens
  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 out
• get_monitor ~180 tokens
  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
• get_notifications ~240 tokens
  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 h
• get_stats_daily ~243 tokens
  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 ~272 tokens
  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
• list_monitors ~296 tokens
  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 a
• pause_monitor ~156 tokens
  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 i
• resume_monitor ~139 tokens
  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.

Browse

• Rust tools
• Website monitoring
• Domains and DNS
• Email
• Telegram

Related MCP servers

• Zovo Website Status Checker
  Is it down, or just you?
• TLS Radar
  SSL/TLS scanning, free Let's Encrypt issuance, and certificate-expiry monitoring.
• Merlonix Monitoring
  Monitoring for agencies — uptime, SSL, DNS, blocklists, AI visibility, MCP health. 8 no-auth tools.
• updown.io MCP by usefulapi
  Check updown.io uptime checks, downtimes, response metrics and status pages, and create checks.
• Uptimepage
  Monitor uptime and incidents, run checks, and publish status updates from your Uptimepage org.
• StatusCake MCP by usefulapi
  Review uptime, SSL, pagespeed and heartbeat checks, alerts and maintenance windows; create checks.
• Starwell: World Data & Statistics
  Statistics from 28 agencies: FRED, Eurostat, ECB, World Bank, OECD. Cited values, computed answers.
• Better Stack MCP by usefulapi
  Read monitors, incidents, heartbeats, on-call and status pages; acknowledge or resolve incidents.

Badge for your README

[![AptLynx](https://aptlynx.net/badge/com.uptybots/monitoring.svg)](https://aptlynx.net/servers/com.uptybots/monitoring)

Listing text is written by the maker; AptLynx lists tools and does not vouch for them. Find another tool · Browse by topic · For agents