Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Monitor uptime and incidents, run checks, and publish status updates from your Uptimepage org.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Du brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Funktioniert in Claude im Web, auf dem Desktop und auf dem Handy:
https://mcp.uptimepage.dev/mcpFühre das in deinem Terminal aus
claude mcp add --transport http uptimepage https://mcp.uptimepage.dev/mcpIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"uptimepage": {
"url": "https://mcp.uptimepage.dev/mcp"
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"uptimepage": {
"type": "http",
"url": "https://mcp.uptimepage.dev/mcp"
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
ChatGPT verbindet sich nur mit Servern im Internet:
https://mcp.uptimepage.dev/mcpMenünamen können sich je nach Tarif und mit der Zeit leicht unterscheiden.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Die Tool-Liste dieses Servers haben wir noch nicht gelesen; wir prüfen die Endpunkte reihum.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 6. Nov. 2026
Der Registry-Name wurde über die Domain uptimepage.dev bestätigt (die Registry prüft, wem die Domain gehört)
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Noch nicht geprüft; wir prüfen die Endpunkte reihum
Noch nicht geprüft; wir prüfen die Endpunkte reihum
Noch nicht geprüft; wir lesen die Tool-Liste, wenn wir den Endpunkt prüfen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft in der Cloud des Entwicklers. Du verbindest dich übers Internet, ohne etwas zu installieren, aber was du sendest, läuft über die Server des Entwicklers.
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (1.6.0) kam vor 9 Tagen in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Er verbindet sich per URL, also funktionieren auch Apps, die Remote-MCP-Server akzeptieren, zum Beispiel ChatGPT im Entwicklermodus.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, debuff
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Let coding agents play, test and tune your 2D web game: live state, explained errors, replays, fuzz.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
Uptime monitoring, status pages and on-call. Open source, free to start. Live in 5 minutes.
Monitor HTTP, TCP, ICMP ping, cron-job heartbeats, DNS, TLS-certificate and domain expiry, plus scripted browser login flows, from multiple regions — then turn green and red into a polished public status page your customers can subscribe to, and page whoever is on call through rotations and escalation policies. Drive it by click, REST API, or Terraform. Self-host the single binary or use the hosted service.
Try it free → · Docs · Self-host · Terraform · MCP
Hosted, no install:
Prefer code? Drive the same account by REST API, Terraform, or MCP. Want to run it yourself? Go to Self-host.
Monitoring with a built-in status page isn't new — the bet here is doing it free, self-hostable, and fully as code:
docker compose up and you're live, not a Kubernetes platform to operate.uptimepage monitors itself. These badges are served by the running app from a public status page — no third-party service, no cron job updating a JSON file.
| Surface | HTTP | DNS | TLS cert | Domain |
|---|---|---|---|---|
| uptimepage.dev (website) | ||||
| app.uptimepage.dev (dashboard) | ||||
| mcp.uptimepage.dev (MCP) |
Embed your own with the snippet in Settings → Pages → your page → Badge.
| Checks | HTTP, TCP, ICMP ping, heartbeat (inbound dead-man's-switch), DNS, TLS-cert expiry, domain expiry, browser login flow with per-step timings, manual (state set by an operator); a circuit breaker per monitor, designed for ~50k concurrent in-flight |
| Public status page | HTML + JSON + RSS, per-component opt-in, incident narration, maintenance windows, email + webhook subscribers |
| Alerting | Slack, PagerDuty, Discord, Microsoft Teams, Google Chat, Mattermost, Telegram, WhatsApp, SMS, email, webhook, ntfy, Gotify, Pushover — per-org channels, sealed secrets, fire-once + recovery, repeat until acknowledged |
| Incidents | Internal incident state ⊥ public phase, acknowledge to silence paging, per-monitor reminder cadence |
| On-call | Layered rotations (daily, weekly, custom) with weekly hours, calendar overrides, your shifts as an iCalendar feed, escalation policies that page channels and schedules level by level |
| Multi-region | Regional probe agents, per-region views, run your own agent anywhere |
| Automation | REST API, scoped API tokens, Terraform provider, MCP server for LLM clients |
| Built on | Rust 1.95 / Tokio / Axum, Postgres + ClickHouse, one ~23 MB self-contained binary |
Live service: [https://uptimepage.dev](https://uptimepage.dev) — hosted, free, sign in with GitHub, Google or your email address. Full docs: [https://uptimepage.dev/docs](https://uptimepage.dev/docs)
Monitors — grouped by environment, filterable by type, tag, or owner
| Type | Purpose | Default interval | Floor |
|---|---|---|---|
http | request a URL, match status / body / latency | 60 s | max(plan_min, 10 s) |
tcp | open a TCP socket within a timeout | 60 s | max(plan_min, 10 s) |
ping | ICMP echo request, fail on a missing reply | 60 s | max(plan_min, 10 s) |
heartbeat | your job pings a URL; a missing ping past period + grace opens an incident | 60 s | max(plan_min, 60 s) |
dns | resolve a record, optionally match a value | 60 s | max(plan_min, 10 s) |
tls_cert | open TLS, parse leaf cert, alert before notAfter | 86 400 s (daily) | max(plan_min, 3600 s) |
domain_expiry | query RDAP, alert before the domain's expiration event | 86 400 s (daily) | max(plan_min, 43 200 s) |
flow | drive a headless browser through login / transaction steps, assert the result | 300 s | max(plan_min, 300 s) |
manual | no probe; an operator sets up, degraded or down and it restates that state | 60 s | exactly 60 s |
tls_cert and domain_expiry use warn_days / critical_days thresholds and surface days_remaining plus registrar / cert subject in the result payload. Their floors are 1 hour for tls_cert and 12 hours for domain_expiry, regardless of plan — these probes track values that change on a scale of days, not minutes, and RDAP rate-limits by source address. flow runs a real browser, so it only executes where a browser engine is available (its regions clamp to the flow-capable set) and the number of flow monitors is capped per plan; put credentials in an org secret and reference them as {{name}}. Every flow run is kept with each step's outcome and duration, and the monitor page charts each step on its own scale, so a wait drifting from 200 ms to four seconds shows up long before the journey fails. A self-hosted install starts with that cap at 0; docs/monitor-types.md covers turning it on. See docs/api.md for the full payload shapes.
A customer-facing /status page (HTML + JSON + RSS 2.0) is built into the binary. Per-target opt-in via public_status; the page's routes carry no auth extractor, so it is public wherever the binary runs, with a per-IP rate limit at the edge, caches for 10 s in-process, and degrades gracefully if ClickHouse is unreachable. Operators narrate incidents (PATCH /api/v1/incidents/{id}, POST /api/v1/incidents/{id}/updates) and schedule maintenance windows (POST /api/v1/maintenance). Visitors subscribe for email or webhook updates. See docs/public-status.md.
Public status page — 90 days of history per component
Notification channels are per-org resources (Slack incoming webhook, generic HTTP webhook, Telegram bot, SMS gateway, …) created via /api/v1/notification-channels. Transport secrets are sealed at rest and never echoed back.
Alerting — Slack, PagerDuty, SMS, webhook, and six more
A target opts in by binding one or more channels in its alerts array:
"alerts": [
{ "channel_id": "0192…", "after_failures": 3 }, { "channel_id": "0193…", "after_failures": 6, "notify_recovery": false } ]
Fire-once + recovery semantics. Channels are tenant-isolated — a target can only bind a channel its own org owns. See docs/api.md for the full contract.
Adding a channel — pick a transport, paste one credential
Run probe agents in the regions your users live in; the control plane assigns checks per region and the dashboard and status page can be viewed per-region. Bring your own agent anywhere — a single binary with an org-scoped token. See docs/multi-region.md.
Monitor detail — latency broken down by region
Manage targets and notification channels as code with the official provider uptimepage/uptimepage (source):
terraform {
required_providers { uptimepage = { source = "uptimepage/uptimepage" } } }
provider "uptimepage" { token = var.uptimepage_token # or set UPTIMEPAGE_TOKEN org = "your-org-slug" # required for managed resources; or UPTIMEPAGE_ORG
}
resource "uptimepage_target" "api" { name = "api prod" interval = 60 ch
Nur der Anfang wird gezeigt; den Rest findest du im Repo