MCP-Server in Claude einbinden: 20 Netzwerk-Checks ohne Account

Update, 8. September 2026: Der MCP-Server von Uptimeify hat inzwischen eine Reihe von Schreib-Werkzeugen bekommen, zusätzlich zu allem, was unten beschrieben ist: einen Monitor pausieren, einen Incident quittieren und Ähnliches. Jedes davon hängt an einem eigenen Zustimmungs-Scope, den du getrennt vom Lesezugriff und je Bereich erteilst und der standardmäßig aus bleibt, solange du ihn nicht selbst ankreuzt -- die 33 Tools aus diesem Beitrag bleiben deshalb genau so read-only wie unten beschrieben. Die aktuelle Werkzeugliste und die Scopes stehen auf der MCP-Server-Seite.

Du fügst eine Zeile Konfiguration ein, und dein KI-Assistent kann ab sofort DNS, SSL, SPF, DMARC, HTTP-Header und die Erreichbarkeit jeder Domain prüfen. Ohne Account, ohne Token, ohne Installation. Der Uptimeify MCP-Server stellt 20 read-only Check-Tools anonym bereit, 13 weitere lesen mit einem API-Token deine eigenen Monitore, Alarme, Statusseiten und dein Konto. Diese Anleitung zeigt die Konfiguration, die Tool-Liste, fünf Prompts zum Direktstart und die Rate Limits.

Was du am Ende hast

Am Ende tippst du "Prüfe SSL, DNS und SPF für diese Kundendomain" in dein Chatfenster und bekommst drei echte Netzwerk-Prüfungen zurück: Zertifikatsaussteller und Restlaufzeit, die aufgelösten Records, den ausgewerteten SPF-Eintrag. Kein Copy-and-paste zwischen drei Web-Tools, kein Tab-Wechsel, keine Zwischenablage.

Der Assistent ruft dafür einzelne Tools auf dem Server auf, statt zu raten. Das ist der Unterschied zwischen einer Antwort aus dem Modellgedächtnis und einer Antwort aus einem Tool Call gegen die echte Domain: Die zweite ist überprüfbar und aktuell.

Was ein MCP-Server in diesem Kontext ist

Ein MCP-Server ist ein Dienst, der einem KI-Assistenten Werkzeuge zur Verfügung stellt, die dieser selbstständig aufrufen kann. Das Model Context Protocol standardisiert dabei, wie Tools beschrieben, aufgerufen und beantwortet werden. Der Assistent bleibt der Assistent, der Server liefert die Fakten.

Konkret heißt das hier: Uptimeify veröffentlicht seine öffentlichen Check-Tools über dieses Protokoll, damit dein Assistent sie direkt benutzen kann. Mehr zur Transportschicht steht im Glossar unter Streamable HTTP.

Der Endpunkt

POST https://uptimeify.io/mcp, Transport ist Streamable HTTP, der Server ist stateless. Keine Session, kein Handshake über mehrere Requests, jeder Aufruf steht für sich.

Zwei Discovery-Dateien liegen bereit, wenn dein Client oder eine Registry den Server automatisch finden soll:

Jedes Tool deklariert ein outputSchema und liefert bei Erfolg structuredContent neben dem Textblock. Zwei Eigenschaften dieser Schemata sind Absicht: Kein Feld ist als erforderlich markiert, und zusätzliche Felder sind erlaubt. Ein Endpunkt, der einen Wert weglässt, macht daraus also keinen fehlgeschlagenen Tool Call, und ein später ergänztes Feld fällt in strengen Clients nicht durch die Validierung.

Auch die Tool-Namen folgen einer bewussten Regel: nur Buchstaben, Ziffern und Unterstriche. Die großen Function-Calling-APIs validieren Tool-Namen gegen ein Muster, das Punkte ausschließt. Ein Name wie dns.check würde von jedem Client abgelehnt, der die Tools an ein Modell durchreicht.

Einbinden in Claude: die konkrete Konfiguration

Der schnellste Weg in Claude Desktop und claude.ai: Füge https://uptimeify.io/mcp als Remote-MCP-Server hinzu. Für die 20 anonymen Tools brauchst du nichts weiter. Willst du zusätzlich deine eigenen Monitore lesen, wähle Connect: Claude registriert sich per Dynamic Client Registration selbst und öffnet die Zustimmungsseite, auf der du dich bei Uptimeify anmeldest und lesenden Zugriff freigibst.

Clients, die Remote-Server mit eigenen Headern unterstützen, konfigurierst du direkt:

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

Den headers-Block lässt du komplett weg, wenn dir die anonymen Check-Tools reichen.

Clients, die nur stdio sprechen, brückst du mit mcp-remote auf den HTTP-Endpunkt:

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

Ob die Verbindung steht, prüfst du ohne Client mit einem einzigen Aufruf:

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"}'

Die Antwort listet alle verfügbaren Tools mit ihren Schemata. Das ist gleichzeitig die verlässlichste Quelle, wenn du wissen willst, was der Server heute kann.

Die 20 Tools ohne Account

Alle 20 sind read-only und führen echte Prüfungen gegen die angefragte Domain aus. Sie spiegeln die öffentlichen Web-Tools, nur eben aufrufbar aus dem Chat.

Wer dieselben Prüfungen lieber im Browser fährt oder einem Kunden einen Link schicken will: Es gibt sie auch als Web-Tools, etwa den SSL-Zertifikat-Checker, die DNS-Abfrage und den SPF-Prüfer.

Fünf Prompts, die sofort funktionieren

Formuliere die Aufgabe, nicht den Tool-Namen. Der Assistent wählt selbst aus, was er aufruft.

1. "Prüfe SSL, DNS und SPF für diese Kundendomain und sag mir, was auffällt."
2. "Läuft das Zertifikat dieser Domain in den nächsten 30 Tagen ab? Wer ist der Aussteller?"
3. "Wir haben gerade den A-Record umgestellt. Ist die Änderung schon überall propagiert?"
4. "Warum landen Mails von dieser Domain im Spam? Sieh dir SPF, DKIM mit Selector default und DMARC an."
5. "Folge allen Redirects von der http-Variante dieser Domain bis zum Ziel und zeig mir die Security-Header der Endseite."

Der fünfte Prompt ist der, den Agenturen am häufigsten brauchen: eine Umzugskontrolle nach dem Livegang, in einem Satz statt in vier Tabs.

Mit API-Token: die 13 zusätzlichen Tools

Dreizehn weitere Tools lesen deine eigenen Monitoring- und Kontodaten. Dafür brauchst du entweder einen API-Token als Authorization: Bearer-Header oder die OAuth-Verbindung aus Claude:

• list_monitors listet deine Website-Monitore, ohne Argumente.
• monitor_status liefert zu einer monitor_id den aktuellen Up- oder Down-Status.
• list_incidents zeigt die letzten Vorfälle, optional mit limit.
• check_history gibt die letzten Checks zu einer monitor_id, optional eingegrenzt mit from und to.
• uptime_summary fasst Verfügbarkeit und mittlere Antwortzeit für Tag, Monat und Jahr zusammen.
• list_alert_channels listet die Benachrichtigungskanäle, über die du alarmiert werden kannst, mit website_id auf einen Monitor eingegrenzt.
• alert_history zeigt zu einer monitor_id, welche Alarme rausgingen, über welchen Kanal und ob die Zustellung klappte.
• list_status_pages listet deine Statusseiten mit Slug, Sichtbarkeit und eigener Domain, ohne Argumente.
• list_maintenance_windows listet deine geplanten Wartungsfenster, auf Wunsch nur die aktiven.
• get_organization liefert deine eigene Organisation mit Name, öffentlicher Kennung und Kontozustand, ohne Argumente.
• list_users listet die Mitglieder deiner Organisation mit Rolle und Beitrittsdatum, ohne Argumente. Es trägt überhaupt keine Mitgliedskennung, ein Mitglied lässt sich also benennen, aber nicht referenzieren.
• list_customers listet deine Kunden mit Name, Zustand und Monitor-Zahlen, ohne Argumente.
• billing_summary liefert den SMS-Verbrauch des laufenden Monats, je Kunde und in Summe, ohne Argumente.

Die letzten vier geben eine feste Feldliste heraus und sonst nichts: keine Kontakt-E-Mail, keine Anschrift, keine Umsatzsteuer-Identifikationsnummer, keine Telefonnummer, keine freien Zusatzfelder, keinen Tarifnamen, keine Rechnungs-E-Mail, kein Zahlungsmittel. Über OAuth liegen sie außerdem in einem eigenen Zustimmungsbereich, eine Verbindung kann die Monitoring-Werkzeuge also nehmen und die Konto-Werkzeuge weglassen.

Der Token entscheidet über den Umfang: Ein kundenbezogener Token sieht nur die Monitore dieses einen Kunden, ein Organisations-Token alle Kunden der Organisation. Du erstellst ihn unter Einstellungen, API-Tokens; er wird genau einmal angezeigt.

Nimmst du stattdessen OAuth, gilt dieselbe Grenze automatisch: Die Verbindung erbt exakt die Sichtbarkeit deines Accounts und ist ausdrücklich auf Lesen beschränkt. Die Zugriffstoken laufen nach einer Stunde ab und werden im Hintergrund erneuert, die Freigabe selbst nach sieben Tagen ohne Nutzung. Widerrufen kannst du sie jederzeit unter Einstellungen, Verbundene Apps; das wirkt sofort.

Rate Limits und was bei HTTP 429 passiert

Die anonymen Tools führen echte Netzwerk-Prüfungen in deinem Auftrag aus, deshalb sind sie pro Client-IP gedeckelt. Zwei Ebenen greifen gleichzeitig:

120 Aufrufe pro Minute verteilt über verschiedene Tools sind in Ordnung. 120 Aufrufe whois pro Minute sind es nicht: whois und domain_expiry liegen mit 15 am unteren Rand.

Überschreitest du ein Limit, antwortet der Server mit HTTP 429 und einem retryAfter-Wert in Sekunden. Die Fenster sind fest, nicht gleitend: Wer retryAfter abwartet, startet danach mit vollem Kontingent. Und die Limits hängen an der IP, nicht am Token. Ein API-Token hebt die Decke nicht an, und mehrere Agenten hinter derselben NAT-Adresse teilen sich ein Kontingent. Wenn dein Anwendungsfall mehr braucht, sprich uns an, statt es zu umgehen.