Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者による説明(英語の原文)
Monitor uptime and incidents, run checks, and publish status updates from your Uptimepage org.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
必要なもの
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
ウェブ、デスクトップ、モバイルのClaudeで使えます:
https://mcp.uptimepage.dev/mcpターミナルでこれを実行します
claude mcp add --transport http uptimepage https://mcp.uptimepage.dev/mcpプロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"uptimepage": {
"url": "https://mcp.uptimepage.dev/mcp"
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"uptimepage": {
"type": "http",
"url": "https://mcp.uptimepage.dev/mcp"
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
ChatGPTがつなげるのは、インターネット上のサーバーだけです:
https://mcp.uptimepage.dev/mcpメニューの名前は、プランや時期によって少し違うことがあります。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
このサーバーのツール一覧はまだ読み取っていません。エンドポイントは順番にチェックしています。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月6日にチェック
レジストリ名はドメイン uptimepage.dev で確認済みです(レジストリがドメインの所有を確認しています)
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
まだチェックしていません。エンドポイントは順番にチェックしています
まだチェックしていません。エンドポイントは順番にチェックしています
まだチェックしていません。エンドポイントをチェックするときにツール一覧を読み取ります
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
作者のクラウドで動きます。インストール不要でインターネット経由でつながりますが、送った内容は作者のサーバーを通ります。
GitHubリポジトリの最終更新は–、最新バージョン(1.6.0)がレジストリに届いたのは9 日前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。URLでつながるので、リモートMCPサーバーに対応したアプリ(開発者モードのChatGPTなど)でも使えます。
同じカテゴリには:Spec Driven Development, Remote Desktop Commander, BankBridge
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
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.
Works in any MCP agent, including local models. Read-only bank accounts, spending, investments.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
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
冒頭だけを表示しています。続きはリポジトリで読めます