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.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 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天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。
同一分类中有:Spec Driven Development, Remote Desktop Commander, HotCodePush
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况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.
Manage over-the-air (OTA) updates for React Native, Expo, Capacitor and Cordova apps.
按原文从作者的仓库复制。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
只显示了开头部分;其余内容请在仓库中阅读