protogrid

Search / com.uptybots/monitoring

UptyBots

R0· no sign-in

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

v1.4.1 · active · website · descriptor JSON · versions

An agent can connect right now, no human step.Remote endpoint, no authentication, reachable on the last probe.
Quality87good
Trust79of 100
Uptime, 30 days94%
Latency p50235 ms

Connect

8 clients · secrets stay placeholders
{
  "mcpServers": {
    "monitoring": {
      "type": "http",
      "url": "https://mcp.uptybots.com/mcp"
    }
  }
}
claude mcp add --transport http monitoring https://mcp.uptybots.com/mcp
[mcp_servers.monitoring]
url = "https://mcp.uptybots.com/mcp"
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "monitoring": {
      "type": "remote",
      "url": "https://mcp.uptybots.com/mcp",
      "enabled": true
    }
  }
}
{
  "mcpServers": {
    "monitoring": {
      "type": "http",
      "url": "https://mcp.uptybots.com/mcp"
    }
  },
  "deeplink": "cursor://anysphere.cursor-deeplink/mcp/install?name=monitoring&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vbWNwLnVwdHlib3RzLmNvbS9tY3AifQ%3D%3D"
}
{
  "servers": {
    "monitoring": {
      "type": "http",
      "url": "https://mcp.uptybots.com/mcp"
    }
  }
}
{
  "mcpServers": {
    "monitoring": {
      "httpUrl": "https://mcp.uptybots.com/mcp"
    }
  }
}
extensions:
  "monitoring":
    enabled: true
    name: "monitoring"
    type: streamable_http
    uri: "https://mcp.uptybots.com/mcp"
    timeout: 300

Quality 87 / 100good

protocol75 · weight 25
  • warn
    protocol.modernnewest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
  • n/a
    protocol.statelessonly applies to 2026-07-28 servers
  • pass
    protocol.transportstreamable HTTP
  • n/a
    protocol.list_ttlonly applies to 2026-07-28 servers
authorizationn/a · weight 15
  • n/a
    auth.prm, auth.as_metadata, auth.cimdno remote uses OAuth
  • n/a
    auth.secret_in_urlno templated URL
tool hygiene100 · weight 30
  • pass
    tools.descriptionsevery tool has a description
  • pass
    tools.description_lengthdescriptions are concise
  • pass
    tools.schemasevery tool has an object input schema
  • pass
    tools.annotations15 of 15 tools declare readOnlyHint or destructiveHint
  • pass
    tools.directory_hintsevery tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHint
  • pass
    tools.token_costabout 3,473 tokens to load every tool
  • pass
    tools.api_dumptools are not a one-to-one API dump
stability100 · weight 15
  • pass
    stability.changesno tool changes in 30 days
  • pass
    stability.rug_pullno tool changed its meaning under the same name
dependencies67 · weight 15
  • pass
    deps.known_vulnsno known advisory in 98 resolved packages
  • fail
    deps.mcp_sdk_version@modelcontextprotocol/sdk 1.30.1 has 1 known advisory (GHSA-6qxp-vccf-f47h); update @modelcontextprotocol/sdk to 1.31.0 or later
  • pass
    deps.resolvable[email protected] resolved: 98 packages

15 tools, about 3,473 tokens to load them all · tool set 0ad04690dc07 · checked 2026-10-19 16:53 UTC

Tool changes

No tool definition changes recorded. A server's first observation is its baseline; later probes record what changes.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.

Trust 79 / 100

no-repository
provenance55
liveness97
freshness85
hygiene80

+dns-namespace +website +reachable +uptime-94% ~updated-59d-ago -no-repository

Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. How it is computed.

Dependencies

[email protected] npm97 dependencies, resolved · MCP SDK @modelcontextprotocol/sdk 1.30.1 · advisories checked 2026-10-19

advisoryseveritypackagefixed in
GHSA-6qxp-vccf-f47hMCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP serverhigh@modelcontextprotocol/[email protected]MCP SDK, directfixed in 1.31.0

Dependency graphs from deps.dev; advisories from OSV.dev, including the GitHub Advisory Database and the PyPI Advisory Database; all CC BY 4.0. The graph is what a clean install of this version resolves today; nothing was installed or run. How it is checked.

Endpoints

remoteauthreachableuptime 30dp50protocollast ok
https://mcp.uptybots.com/mcp streamable-httpnoneyes94%235 ms2025-11-252026-10-19
packageregistryversionruntimesecrets
uptybots-mcp-servernpm1.3.1–UPTYBOTS_API_KEY

Tools (15)

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.
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 registration; the two expire on different dates and both are worth watching.
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 probes in several countries. Call list_monitors first so you do not create a duplicate of an existing url.
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 its web server is down. Some hosting providers block ICMP, in which case the monitor will read as down.
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 part of the url. Set protocol to UDP for game servers; most of them do not answer on TCP at all.
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 reachability and one for expiry, so a certificate can be days from expiring while the check still reads up.
delete_monitordestructivePermanently 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_incidentsread-onlyRead 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.
get_monitorread-onlyRead 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.
get_notificationsread-onlyRead 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.
get_stats_dailyread-onlyResponse 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_hourlyread-onlyResponse 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.
list_monitorsread-onlyList 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_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 is off.
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.

Schemas: list_tools.

Similar MCP servers

Official server.json
{
  "name": "com.uptybots/monitoring",
  "title": "UptyBots",
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "remotes": [
    {
      "url": "https://mcp.uptybots.com/mcp",
      "type": "streamable-http"
    }
  ],
  "version": "1.4.1",
  "packages": [
    {
      "version": "1.3.1",
      "transport": {
        "type": "stdio"
      },
      "identifier": "uptybots-mcp-server",
      "registryType": "npm",
      "registryBaseUrl": "https://registry.npmjs.org",
      "environmentVariables": [
        {
          "name": "UPTYBOTS_API_KEY",
          "isSecret": true,
          "isRequired": true,
          "description": "API key from Account -> API Keys on uptybots.com. Starts with upty_."
        },
        {
          "name": "UPTYBOTS_API_URL",
          "description": "Base URL of the API. Defaults to https://uptybots.com; only needed for self-checks against another environment."
        }
      ]
    }
  ],
  "websiteUrl": "https://uptybots.com/docs/mcp",
  "description": "Uptime monitoring: create and manage HTTP, API, SSL, ping, port and domain checks"
}