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

> Eine Zeile Konfiguration, und dein KI-Assistent prüft DNS, SSL, SPF und Erreichbarkeit jeder Domain direkt im Chat.

Source: https://uptimeify.io/de/blog/mcp-server-claude-einbinden

**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](/de/mcp-server).

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.

- Endpunkt: `POST https://uptimeify.io/mcp`, Streamable HTTP, stateless.
- 20 Check-Tools laufen ohne Account und ohne Token, 13 weitere lesen mit API-Token oder OAuth deine eigenen Monitore, Alarme, Statusseiten und dein Konto.
- In Claude trägst du die URL als Remote-MCP-Server ein, andere Clients nutzen einen JSON-Block oder `mcp-remote`.
- Limits: 120 Requests pro Minute und IP am Endpunkt, 15 bis 30 je anonymem Tool, 60 je authentifiziertem Tool. Darüber kommt HTTP 429 mit `retryAfter`.
- Alle 33 Tools aus dieser Anleitung sind read-only. Eine getrennte Reihe von Schreib-Werkzeugen gibt es inzwischen, aber nur, wenn du deren Zustimmungs-Scope selbst erteilst.

## 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:

| Datei | Zweck |
| --- | --- |
| `/.well-known/mcp/server-card.json` | Server-Card mit Fähigkeiten und Tool-Metadaten |
| `/.well-known/mcp/server.json` | Registry-Manifest für MCP-Verzeichnisse |

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:

```json
{
  "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:

```json
{
  "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:

```bash
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.

| Gruppe | Tools | Argumente |
| --- | --- | --- |
| DNS und Domain | `check_dns`, `dns_propagation`, `whois`, `domain_expiry` | `domain` |
| Mail | `mx_lookup`, `spf_check`, `dmarc_check`, `dkim_check`, `dnsbl_check` | `domain`, bei `dkim_check` zusätzlich `selector`, bei `dnsbl_check` eine `ip` |
| TLS | `check_ssl`, `hsts_check` | `host` und optional `port`, bzw. `domain` |
| HTTP | `http_headers`, `redirect_check`, `website_status`, `response_time` | `url` |
| Netzwerk | `port_check`, `ping_test`, `ip_geolocation`, `asn_lookup`, `reverse_dns` | `host` und `port`, `query` bzw. `ip` |

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](/de/werkzeuge/ssl-zertifikat-pruefer), die [DNS-Abfrage](/de/werkzeuge/dns-abfrage) und den [SPF-Prüfer](/de/werkzeuge/spf-pruefer).

Die vollständige Übersicht mit allen Tools, Argumenten und unterstützten Clients steht auf der MCP-Server-Seite.

## 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.

Ein Prompt gegen eine echte Domain schlägt jede Antwort aus dem Modellgedächtnis, weil er überprüfbar ist.

## 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.

Alle Argumente, Antwortschemata und Fehlerfälle stehen in der technischen Referenz der Dokumentation.

## 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:

| Bereich | Limit |
| --- | --- |
| `POST /mcp` insgesamt | 120 Requests pro Minute und IP |
| Je anonymes Check-Tool | 15 bis 30 Aufrufe pro Minute und IP, je nach Aufwand der Prüfung |
| Je authentifiziertes Tool | 60 Aufrufe pro Minute und IP |

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.