MCP Server for Monitoring. Your Agent Runs the Check.

No. The anonymous check tools work with the URL https://uptimeify.io/mcp alone, no token and no signup. You only need an account once your agent should read your own monitors, because that is what the API token is for. So you can try whether the tools help in daily work first and decide afterwards.

You add the endpoint to your client configuration, with an Authorization header if you need one. Clients that speak remote HTTP servers point at the URL directly. Clients that only speak stdio bridge to it with mcp-remote, which forwards the call to the HTTP endpoint. If you only need the anonymous tools, leave the header out entirely.

Direct:

{
  "mcpServers": {
    "uptimeify": {
      "url": "https://uptimeify.io/mcp",
      "headers": { "Authorization": "Bearer wsm_your_token_here" }
    }
  }
}

Through the stdio bridge:

{
  "mcpServers": {
    "uptimeify": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://uptimeify.io/mcp", "--header", "Authorization: Bearer wsm_your_token_here"]
    }
  }
}

No. Your client can log in over OAuth instead: it sends you to the browser, you approve with the account you already have, and from then on it holds a session rather than a secret you pasted. That keeps a long-lived key out of a file that gets synced, shared or committed by accident. An OAuth session is always read-only and shows exactly what that user may see in Uptimeify, checked fresh rather than frozen at login. Static API tokens still work where you want one, for a script or a shared runner.

No. Every tool is read-only, both the anonymous checks and the authenticated queries against your monitoring data. Your agent can read and interpret state, but it cannot create, edit or delete monitors and cannot acknowledge incidents. That takes the edge off internal approval: a badly worded prompt cannot reconfigure your monitoring.

Only that one customer's monitors. An organization token, by contrast, sees every customer in your organization. So you can hand a client project or a single team member access that shows exactly the right slice instead of opening up your whole portfolio.

Yes. The anonymous tools check any publicly reachable domain, including deinkunde.com, with nothing to install on that side. They read what is already answered publicly: certificate, DNS records, mail records, HTTP response. Availability history and incidents are different: those need a configured monitor and a token.

Yes, and they are worth knowing before you build against them. The endpoint accepts 120 requests per minute per IP, and each individual check tool has its own cap on top: 15 to 30 calls per minute for the anonymous ones depending on how expensive the check is, 60 for the authenticated ones. So a spread of different checks is fine, hammering one tool is not. Over the limit you get HTTP 429 with a retryAfter value telling you when the window resets. Counting is per IP, not per token, so a token does not buy you more. If you have a case that genuinely needs a higher ceiling, talk to us.