MCP-Server

Uptimeify stellt einen zustandslosen Model-Context-Protocol-Server bereit, damit KI-Agenten unsere kostenlosen Checks direkt ausführen können.

Einen Überblick darüber, was der Server kann und mit welchen Clients er funktioniert, findest du auf der MCP-Server-Seite auf uptimeify.io. Diese Seite hier ist die technische Referenz.

Endpunkt

POST https://uptimeify.io/mcp: Streamable-HTTP-Transport, zustandslos. Die anonymen Check-Tools brauchen keine Authentifizierung; die authentifizierten Tools benötigen einen Bearer-API-Token (siehe unten).

Den Server programmatisch über die MCP Server Card entdecken:

GET https://uptimeify.io/.well-known/mcp/server-card.json

MCP-Client verbinden

Richte einen beliebigen MCP-Client mit Streamable-HTTP-Transport auf den Endpunkt oben aus.

• Anonyme Tools funktionieren allein mit der URL: kein Token nötig.
• Authentifizierte Tools benötigen deinen Uptimeify-API-Token als Authorization: Bearer <token>-Header. Erstelle einen unter Einstellungen → API-Tokens: lass das Kunden-Feld leer für einen organisationsweiten Token (sieht alle deine Monitore) oder wähle einen Kunden, um den Token auf diesen Kunden zu beschränken. Der Token wird nur einmal bei der Erstellung angezeigt: kopiere ihn sofort.

Clients, die HTTP-MCP-Server mit eigenen Headern unterstützen, zeigen direkt auf die URL:

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

Für Clients, die nur stdio sprechen, überbrückst du zum HTTP-Endpunkt mit mcp-remote:

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

Lass den Authorization-Header weg, wenn du nur die anonymen Check-Tools brauchst.

Rate-Limits

Die anonymen Tools führen echte Netzwerk-Checks in deinem Auftrag aus und sind deshalb pro Client-IP gedeckelt. Für diese Limits brauchst du keinen Account, und um darunter zu bleiben ebenfalls nicht:

Beide Ebenen gelten gleichzeitig: 120 Aufrufe pro Minute verteilt über verschiedene Tools sind in Ordnung, 120 Aufrufe whois pro Minute nicht. Wird ein Limit überschritten, antwortet der Server mit HTTP 429 und einem retryAfter-Wert in Sekunden, der angibt, wann das aktuelle Fenster endet. Die Fenster sind fest, nicht gleitend, wer retryAfter abwartet, bekommt sofort das volle Kontingent.

Gezählt wird pro IP, nicht pro Token: Ein API-Token hebt die Grenze nicht an, und mehrere Agenten hinter derselben NAT-Adresse teilen sie sich. Wenn du einen Anwendungsfall hast, der wirklich mehr braucht, melde dich, statt es zu umgehen.

Verfügbare Tools

Alle Tools sind anonym und nur lesend. Sie entsprechen unseren öffentlichen Web-Tools:

• check_ssl: TLS/SSL-Zertifikatsprüfung (host, optional port)
• check_dns, dns_propagation, mx_lookup: DNS-Auflösung und -Propagation (domain)
• spf_check, dkim_check (domain, selector), dmarc_check: E-Mail-Authentifizierung (domain)
• dnsbl_check (ip), whois (domain), domain_expiry (domain)
• http_headers (url), hsts_check (domain), redirect_check (url)
• port_check (host, port), ping_test (host, optional port)
• website_status (url), response_time (url)
• ip_geolocation (query), asn_lookup (query), reverse_dns (ip)

Authentifizierte Tools (nur lesend)

Diese Tools lesen deine eigenen Monitoring-Daten. Sende deinen Uptimeify-API-Token als Authorization: Bearer <token>-Header mit der MCP-Anfrage. Ein kundengebundener Token sieht nur die Monitore seines Kunden; ein Organisations-Token sieht alle Kunden der Organisation. Alle sind nur lesend.

• list_monitors: deine Website-Monitore auflisten (keine Argumente)
• monitor_status (monitor_id): ein einzelner Monitor mit aktuellem Up/Down-Status
• list_incidents (optional limit): aktuelle Incidents über deine Monitore
• check_history (monitor_id, optional from, to): jüngste Checks, optional in einem ISO-Datumsbereich
• uptime_summary (monitor_id): Verfügbarkeit und mittlere Antwortzeit für Tag / Monat / Jahr

Rufst du eines dieser Tools ohne Token auf, gibt es einen Fehler zurück und bittet um den Authorization: Bearer-Header. Einen Token erstellst du unter Einstellungen → API-Tokens.

Strukturierte Ausgabe

Jedes Tool deklariert ein outputSchema, und jeder erfolgreiche Aufruf liefert neben dem Textblock ein structuredContent. Damit kannst du eine Antwort gegen das veröffentlichte Schema typprüfen, statt unser JSON von Hand zu parsen. Der Textblock bleibt unverändert und trägt weiterhin die vollständige Antwort, ein Client, der strukturierte Ausgabe ignoriert, sieht genau das, was er vorher gesehen hat.

Zwei Eigenschaften dieser Schemas sind bewusst so gewählt:

• Kein Feld ist Pflicht. Das Schema typisiert die Felder, die es kennt; es behauptet nie, dass eines vorhanden ist. Ein Endpunkt, der einen Wert weglässt oder auf null setzt, macht aus einem Check keinen fehlgeschlagenen Tool-Aufruf.
• Zusätzliche Felder sind erlaubt. Die Schemas sind offen: Ein später ergänztes Feld reist in structuredContent einfach mit, statt in einem strikten Client an der Validierung zu scheitern.

structuredContent muss ein JSON-Objekt sein, und list_incidents antwortet mit einem nackten Array: In der strukturierten Form steckt dieses Array unter dem Schlüssel incidents. Der Textblock behält das Array unverändert.

Fehler tragen kein structuredContent. Sie kommen wie bisher als isError: true mit einer schlichten Meldung zurück.

Tool-Namen bestehen nur aus Buchstaben, Ziffern und Unterstrichen. Das ist keine Kosmetik: Die großen Function-Calling-APIs prüfen Tool-Namen gegen ^[a-zA-Z0-9_-]{1,64}$ (OpenAI) beziehungsweise ^[a-zA-Z0-9_-]{1,128}$ (Anthropic), ein Name mit Punkten würde von jedem Client abgelehnt, der unsere Tools an ein Modell durchreicht.

Verbindung per OAuth (Claude Desktop / Claude.ai)

Der /mcp-Endpunkt von Uptimeify unterstützt außerdem Standard-MCP-OAuth (OAuth 2.1 + PKCE + Dynamic Client Registration): so authentifiziert sich der Remote-MCP-Connector von Claude, ohne dass du manuell ein API-Token anlegen musst.

1. Füge in Claude https://uptimeify.io/mcp als Remote-MCP-Server hinzu und wähle Verbinden.
2. Claude registriert sich automatisch (Dynamic Client Registration) und öffnet ein Browserfenster, in dem du dich bei Uptimeify anmeldest und den Zugriff bestätigst.
3. Der Zustimmungsbildschirm weist immer auf reinen Lesezugriff auf deine Monitore, Vorfälle und Status-Seiten hin: die OAuth-Verbindung kann niemals etwas erstellen, bearbeiten oder löschen und erhält genau die Sichtbarkeit deines eigenen Kontos: Ein kundenbeschränkter Nutzer sieht in Claude nur diesen Kunden, ein Organisations-Administrator sieht die gesamte Organisation.
4. Nach der Bestätigung kann Claude dieselben 5 Lese-Tools nutzen wie wsm_-API-Token: list_monitors, monitor_status, list_incidents, check_history, uptime_summary.

OAuth-Access-Token sind kurzlebig (1 Stunde) und erneuern sich automatisch im Hintergrund, solange Claude die Verbindung nutzt; die zugrundeliegende Berechtigung läuft nach 7 Tagen Inaktivität automatisch ab. Verbundene Apps kannst du jederzeit unter Einstellungen → Verbundene Apps einsehen und widerrufen (siehe Verbundene Apps): der Widerruf wirkt sofort, für eine erneute Verbindung ist wieder eine OAuth-Zustimmung nötig.

OAuth und statische wsm_-API-Token funktionieren gleichzeitig auf /mcp: eine OAuth-Verbindung erfordert nicht, eine bestehende API-Token-Integration zu entfernen.

Beispiel (tools/list)

curl -X POST https://uptimeify.io/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Beispiel (authentifizierter Tool-Aufruf)

Eigene Monitore auflisten: mit Authorization-Header:

curl -X POST https://uptimeify.io/mcp \
  -H 'Authorization: Bearer wsm_dein_token_hier' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"list_monitors","arguments":{}}}'