MCP Server for Monitoring. Your Agent Runs the Check.

Streamable HTTP, stateless. No session, no handshake state for you to maintain.

The server card describes the server in machine-readable form.

One tools/list call over JSON-RPC against the endpoint, with the header Accept: application/json, text/event-stream. If the server returns the tool list, the connection is live.

check_ssl takes host and an optional port. port_check takes host plus port, ping_test takes host and an optional port.

The DNS and mail tools take domain, with dkim_check also taking selector.

dnsbl_check and reverse_dns take ip. http_headers, redirect_check, website_status and response_time take a full url. ip_geolocation and asn_lookup take query, meaning an IP or a domain.

The authenticated tools accept a long-lived API token on the MCP request.

Or your client logs in over OAuth 2.0 with PKCE and never holds a stored secret. It finds the flow through the server card, registers itself at the registration endpoint and runs the authorization-code grant. A bearer the server cannot resolve comes back as a 401 carrying a WWW-Authenticate header that points at the protected-resource metadata, so the client restarts the login on its own.

An OAuth session carries what that user may see in Uptimeify right now, and never more than they may do themselves. The binding is re-resolved when the session mints its short-lived inner token, not frozen at login, so access you revoke in the dashboard stops working instead of living on in a stale grant.

On top of the read tools, a growing set of write tools can change state, pause or resume a monitor, rename it, change its check interval, create or delete one, acknowledge, resolve, update or delete an incident, create, update or delete a maintenance window, create, update or delete a status page or its custom domain, create, update or delete a notification channel for email or SMS, and, in the organization itself, create, update or delete a tag, a custom field or a scheduled report, put a tag on a monitor or take it off, change or deactivate an existing member, and create, update or delete a customer together with the domains and IP addresses watched for it. Each sits behind its own consent scope, checked apart from the matching read scope. Creating or deleting a member is deliberately not among them, and neither is changing your organization's own master data. Only the tools that delete something require an explicit confirmation on the call itself naming the exact change, the others do not. Grant no write scope, and none of this is reachable.

You create tokens under Settings, API tokens. The token is shown exactly once, at creation.

{ "list_monitors, monitor_status and check_history all take an optional kind, covering all eight monitor families (website, dns, icmp, tcp, ftp, smtp, ssh, imap_pop); omit it and list_monitors returns every family while monitor_status and check_history default to website": { " check_history also takes monitor_id plus optional from and to as ISO dates": { " list_incidents takes an optional limit, 100 by default and 500 at most": { " list_alert_channels takes an optional website_id and otherwise answers with your organization-level channels": { " alert_history takes monitor_id plus optional kind, from, to, status (sent or failed), page and limit, 25 per page by default and 100 at most": { " list_status_pages takes no arguments": { " list_maintenance_windows takes an optional active_only and has no date filter, so bound it by time yourself": { " get_organization, list_users, list_customers and billing_summary take no arguments at all, the account follows from the token": { " billing_summary is the one whose answer depends on a second consent area": "it names the customers of its usage breakdown only if the connection also carries the organization area, otherwise the breakdown stays with public ids." } } } } } } } } }

{ "The account-bound tools drop what a language model has no business seeing": { " Channel configuration stays out of both alert tools, so no recipient addresses, no phone numbers, no webhook targets": { " Status pages arrive without their design config and without the DNS verification token of a custom domain, and a subscriber list is never returned at all": { " Maintenance windows arrive without the monitor row embedded behind them": { " The four account tools work the other way round": "instead of removing named fields they emit a fixed list and nothing else, so contact and notification e-mail, postal address, VAT id, phone number, custom fields, tariff name, billing e-mail and payment method never leave, and a column added to the endpoint later does not travel out either. list_users carries no member identifier at all, so a member can be named but not referenced." } } } } }

No header at all stays fully anonymous. The anonymous tools answer as usual and an authenticated tool returns an error naming the header it needs, rather than an empty result. There is no forced 401 on every request.