Reference · API + embed integrations

MCP server uptime API

Read your MCP server's live uptime status, latency history, and schema-drift events as JSON. Drop a badge on your README, build a status dashboard, route alerts into your own incident-management system. Free read access for public servers; authenticated access on the Author tier.

TL;DR

Three integration paths for your MCP server's status data: (1) the embed widget — one <script> tag that renders a live badge anywhere, ~3KB gzipped, free; (2) the JSON read endpoint at /api/embed-status/<slug> — public, no auth, returns current state and 24h trend; (3) the authenticated API on the Author tier ($9/mo) — full 90-day history, alert webhooks, and your private servers. Join the waitlist to claim your slug.

The free embed badge

The simplest integration. One script tag, configured by data-* attributes on a mount element. No build step, zero dependencies, async-loaded so it never blocks your page render. Two display modes: a CTA card (default) or an inline compact badge.

<div id="alivemcp-embed" data-server="your-server-slug" data-style="badge"></div>
<script async src="https://alivemcp.com/embed.js"></script>

The widget fetches the JSON endpoint on mount, renders a status pill (Live / Degraded / Down / Unknown), and links back to your full status page on AliveMCP. See the live preview for all four mount variants and theme modes.

The public JSON endpoint

If you'd rather build your own UI — a custom dashboard, a Slack-bot status command, a CI guardrail — read the same data the badge consumes:

GET https://alivemcp.com/api/embed-status/<slug>

Returns:

{
  "slug": "your-server-slug",
  "status": "live" | "degraded" | "down" | "unknown",
  "last_probe_at": "2026-04-25T12:34:56Z",
  "uptime_24h_pct": 99.83,
  "p95_latency_ms_24h": 412,
  "schema_drift_in_last_24h": false,
  "status_page_url": "https://alivemcp.com/status/your-server-slug"
}

No auth required for public servers. Cache-Control set to 60 seconds so a viral README doesn't surprise the upstream. CORS-open for browser fetch.

The authenticated API (Author + Team)

Full history. GET /api/v1/servers/<slug>/probes?since=<iso> — every probe with response time, status, and tool-list hash. 90-day retention.
Schema-drift events. GET /api/v1/servers/<slug>/drift — every detected drift event with old-hash, new-hash, and a structural diff (added tools, removed tools, schema-shape changes per tool).
Alert webhooks. Configure outbound POSTs on state changes. Payload includes the same fields as the public endpoint plus a signed timestamp for verification.
Bulk reads. GET /api/v1/servers with query filters — useful if you operate multiple servers and want a single dashboard.

The Team tier ($49/mo) adds the same APIs against your private endpoints and a status-page subdomain. See full pricing.

Why this exists at the API layer

A status feed that's only viewable on someone else's web page is barely a feed. Three concrete jobs the API enables:

README badges. The embed widget is the simplest path. The JSON endpoint lets you render a custom-styled badge using shields.io or your own SVG generator.
Internal dashboards. A team running multiple MCPs can mix AliveMCP probe data with their own application metrics in one Grafana view, using the bulk-read endpoint as a JSON data source.
CI guardrails. A pre-deploy check that confirms your production MCP is currently green before letting the new release ship — a one-line curl in your release pipeline.

The contract is intentionally small and stable: status enum, single-window summary, link back to the status page. We resist adding fields users don't ask for.

Auth, rate limits, and stability

Auth (paid tiers). Bearer token on the Authorization header. Rotate from the dashboard at any time.
Public endpoint rate limit. 60 requests per minute per IP. The widget caches in sessionStorage to stay well under this even on highly-trafficked READMEs.
Authenticated rate limit. 600 requests per minute per key, with burst of 60 — enough for a polled dashboard or a CI loop.
Stability commitment. v1 endpoints are versioned; breaking changes require a v2 and a deprecation notice on the dashboard plus a header flag for at least 90 days.