MCP-Server (KI-Integration)

Das Model Context Protocol (MCP) lässt KI-Assistenten wie Claude, Claude Code, Cursor und andere MCP-kompatible Clients deine Hoppla-Monitoring-Daten direkt abfragen. Frag „Sind alle meine Monitore gesund?" oder „Welche Vorfälle gab es diese Woche?" und erhalte Antworten auf Basis deiner Live-Daten.

Die meisten Tools sind schreibgeschützt. Zusätzlich gibt es eine kleine, ausdrücklich aufgeführte Menge an Schreibaktionen – jede benötigt einen Token-Scope mit der Endung :write, und nur über sie kann MCP etwas verändern. Nichts wird gelöscht.

Funktionsweise

Hoppla stellt einen Streamable-HTTP-MCP-Endpunkt bereit:

https://app.hoppla.dev/mcp

Es gibt zwei Wege, sich zu verbinden – welchen du nutzt, hängt von deinem Client ab:

• OAuth – für Clients mit „Connector"-Oberfläche, die dich über den Browser anmelden (claude.ai, Claude Desktop). Du fügst die URL ein, bestätigst einen Zustimmungsbildschirm, fertig. Kein Token zum Kopieren oder Speichern. Das ist der empfohlene Weg, sofern dein Client ihn unterstützt.
• API-Token – für Clients ohne Oberfläche bzw. auf der Kommandozeile (Claude Code, Cursor, mcp-remote, CI, eigene Skripte). Du erstellst einmalig ein Token und sendest es als Bearer-Header.

Beide erreichen denselben Endpunkt und verhalten sich nach dem Verbinden identisch. Was ein Client sehen und tun darf, entscheiden die Scopes, nicht die Art der Anmeldung: Ein Token bzw. eine Freigabe liest nur die Daten, die seine Scopes erlauben, und führt nur die Schreibaktionen aus, die seine :write-Scopes erlauben.

Eigene Portal-Domains

Nutzt dein Team eine eigene Portal-Domain (z. B. monitoring.deinefirma.com), verwende sie statt app.hoppla.dev für beide Verfahren:

https://monitoring.deinefirma.com/mcp

Praktisch für von Resellern verwaltete Teams, deren Nutzer app.hoppla.dev nicht kennen. Authentifizierung, Team-Isolation und die verfügbaren Tools sind auf beiden identisch. Die OAuth-Discovery ist relativ zur verbundenen Domain, sodass ein auf deinem Portal erteiltes Token an dieses Portal gebunden ist und nicht gegen app.hoppla.dev wiederverwendet werden kann – und umgekehrt.

Verbinden per OAuth (empfohlen)

Richte deinen Client auf https://app.hoppla.dev/mcp und lass ihn die Anmeldung übernehmen. Nichts zu kopieren.

claude.ai (Web und Desktop)

1. Öffne Einstellungen → Connectors und wähle Eigenen Connector hinzufügen.
2. Gib die URL ein: https://app.hoppla.dev/mcp.
3. Claude leitet dich zu Hopplas Zustimmungsbildschirm. Melde dich an, falls noch nicht geschehen (dein normaler Login, inklusive Passkey oder 2FA).
4. Auf dem Zustimmungsbildschirm wählst du:
   • Nur lesen (vorausgewählt) oder Lesen und handeln. Nur-lesen kann alles abfragen; „Lesen und handeln" erlaubt zusätzlich die Schreib-Tools (Vorfälle bestätigen/aktualisieren, Checks stummschalten und ausführen, Wartung planen, Status-Page-Updates veröffentlichen). Team-, Abrechnungs- oder Einstellungsänderungen sind nie enthalten.
   • Welche Teams der Connector erreichen darf. Einzelne Teams anhaken, oder „einschließlich jedes Teams, dem ich später hinzugefügt werde" für eine Alle-Teams-Freigabe, die neue Teams automatisch aufnimmt.
5. Bestätige. Das Fenster meldet die Verbindung und du kannst es schließen.

Claude Desktop (Connector-Oberfläche)

Aktuelles Claude Desktop hat denselben Connector-Ablauf wie claude.ai – Connector mit obiger URL hinzufügen und den Zustimmungsbildschirm bestätigen. Hat dein Claude Desktop keine Connector-Oberfläche, nutze das API-Token-Verfahren unten mit mcp-remote.

Was OAuth für dich erledigt

• Der Zugriff erneuert sich selbst. Das Access-Token gilt 8 Stunden und wird im Hintergrund still erneuert (Refresh-Fenster: 30 Tage). Im Normalbetrieb wirst du nicht erneut zur Anmeldung aufgefordert. Bleibt ein Connector länger als 30 Tage ungenutzt, verbindest du dich einmal neu.
• Geringstmögliche Rechte per Default. Der Zustimmungsbildschirm wählt Nur-lesen vor, egal was der Client angefragt hat – Handlungszugriff ist damit stets eine bewusste Entscheidung.
• Jederzeit widerrufbar. Öffne den Bereich Entwickler in deinem Dashboard: Jede verbundene App ist mit einem Trennen-Button aufgeführt. Das Trennen beendet die gesamte Freigabe sofort – das aktive Access-Token und sein Refresh-Token – sodass der Connector sofort aufhört zu funktionieren, nicht erst in 8 Stunden. Entfernst du Hoppla im Client selbst, endet die Freigabe ebenfalls, sofern der Client seine Tokens widerruft (der Endpunkt steht als revocation_endpoint in den Metadaten); prüf danach sicherheitshalber den Bereich Entwickler.

Verbinden per API-Token

Für Clients, die OAuth nicht selbst steuern. Erstelle ein Token unter Einstellungen → API-Tokens (siehe API-Tokens), gib ihm die nötigen Scopes und sende es als Bearer-Header.

TIP

Nutze pro Integration ein eigenes Token, damit du den MCP-Zugriff widerrufen kannst, ohne deine anderen API-Clients zu stören. Vergib nur die Scopes, die du brauchst – Lese-Scopes für einen schreibgeschützten Assistenten.

Claude Code

claude mcp add hoppla \
  --transport http \
  --url https://app.hoppla.dev/mcp \
  --header "Authorization: Bearer DEIN_TOKEN"

Cursor

Zur Cursor-MCP-Konfiguration hinzufügen (.cursor/mcp.json im Projekt oder global):

{
  "mcpServers": {
    "hoppla": {
      "url": "https://app.hoppla.dev/mcp",
      "headers": {
        "Authorization": "Bearer DEIN_TOKEN"
      }
    }
  }
}

Claude Desktop ohne Connector-Oberfläche (mcp-remote)

Ältere Claude-Desktop-Versionen sprechen nur den stdio-Transport und brauchen daher eine Brücke. mcp-remote (benötigt Node.js) leitet an den HTTP-Endpunkt weiter. Bearbeite die Konfigurationsdatei:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "hoppla": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://app.hoppla.dev/mcp",
        "--header",
        "Authorization: Bearer DEIN_TOKEN"
      ]
    }
  }
}

Nach dem Speichern Claude Desktop neu starten.

TIP

Startet npx langsam, installiere es einmalig (npm install -g mcp-remote) und setze "command": "mcp-remote" mit "args": ["https://app.hoppla.dev/mcp", "--header", "Authorization: Bearer DEIN_TOKEN"].

Jeder andere Client

Jeder Client, der Streamable HTTP spricht, kann sich verbinden:

Einstellung	Wert
URL	https://app.hoppla.dev/mcp
Transport	Streamable HTTP
Auth	Authorization: Bearer DEIN_TOKEN, oder OAuth, falls der Client es unterstützt

Über mehrere Teams hinweg arbeiten

Ein Token bzw. eine OAuth-Freigabe kann für ein Team oder für mehrere gleichzeitig autorisiert sein (bei OAuth wählst du das im Zustimmungsbildschirm; bei einem API-Token wird es beim Erstellen festgelegt).

Kann eine Verbindung mehr als ein Team erreichen, fächern die Listen- und Dashboard-Tools automatisch auf und liefern pro Team einen Block unter dem Feld by_tenant, sodass jede Zeile ihr Team benennt. Um in einem einzelnen Team zu arbeiten, übergib ein tenant_id-Argument (die IDs liefert list-accessible-tenants) und das Ergebnis wird auf dieses Team beschränkt.

Du erreichst immer nur die Teams, für die die Verbindung autorisiert ist – niemals ein anderes, selbst wenn ein Tool mit der Ressourcen-ID eines fremden Teams aufgerufen wird. Eine ID aus einem für dich unerreichbaren Team liefert exakt dasselbe „nicht gefunden" wie eine ID, die es nicht gibt, sodass die Tools nie verraten, ob anderswo etwas existiert.

Verfügbare Tools

43 Tools. Welche antworten, hängt von deinen Scopes ab.

Monitore

Tool	Beschreibung
list-monitors	Monitore auflisten, filterbar nach Typ, Tag oder Suchbegriff. Paginiert (max. 50 pro Aufruf); die Antwort trägt has_more
list-monitor-tags-and-groups	Die tatsächlich verwendeten Tag- und Gruppennamen – vor dem Filtern von list-monitors nach Tag aufrufen
get-monitor-details	Ein einzelner Monitor mit seinen Checks und letzten Ergebnissen
get-monitor-uptime	Uptime für die letzten 24 h, 7 T und 30 T. Sagt ausdrücklich, wenn Uptime nicht anwendbar ist (z. B. Cron-/Agent-Heartbeat-Monitor), statt bloße Nullwerte zu liefern
get-monitor-report	Uptime über einen expliziten Datumsbereich: Gesamtprozent, Anzahl Vorfälle, Aufschlüsselung pro Tag. Bereiche über 90 Tage werden auf die letzten 90 gekürzt
get-monitor-performance	Antwortzeit-Perzentile (Durchschnitt, p50, p95, p99) über 24 h, 7 T, 30 T und 90 T, aus echten Ergebnissen berechnet
get-monitor-certificate	SSL-Zertifikatsdetails und Ablauf
get-monitor-dns-history	DNS-Einträge und jüngste Änderungen
get-monitor-broken-links	Ergebnisse des Broken-Link-Scans
get-check-results	Paginierte Ergebnis-Historie eines Checks
get-check-timeseries	Antwortzeit-Zeitreihe eines Checks über einen Zeitraum – avg/min/max pro Bucket (plus p50/p95 und Timing-Phasen bei kurzen Fenstern)
get-monitor-check-detail	Letztes Ergebnis eines Check-Typs: lighthouse, geo, web_vitals, security_headers, domain_expiry, robots_txt, sitemap, redirects, mixed_content, dnsbl, ping, tcp oder application_health. Liefert check_configured, sodass „kein solcher Check" und „noch keine Daten" unterscheidbar sind

Vorfälle

Tool	Beschreibung
list-incidents	Vorfälle, filterbar nach Status, Monitor oder Archivzustand
get-incident-details	Ein einzelner Vorfall mit vollständiger Update-Chronik

Dashboards, Logs & weitere Ressourcen

Tool	Beschreibung
list-cron-monitors	Cron-Heartbeat-Monitore mit Status und Zeitplan
list-agent-monitors	Server-Agent-Monitore mit Hostname, OS und Ressourcenstatus
list-status-pages	Status-Pages mit ihren Monitoren und Sichtbarkeit
list-maintenance-windows	Wartungsfenster, filterbar nach aktiv/anstehend/vergangen
get-dashboard-stats	Aggregierte Kennzahlen: Uptime, Antwortzeit, Monitor-Zahlen, Gesamt-Checks. Verfügbarkeits-Fehler zählen als Ausfall; fehlschlagende informative Checks (z. B. Lighthouse) werden separat unter failing_informational_checks geführt, damit ein langsames Audit nicht für einen Ausfall gehalten wird
get-dashboard-events	Ereignis-Chronik der letzten 7 Tage: Vorfälle erstellt/gelöst, Wartung begonnen/beendet, SSL-Ablaufwarnungen
get-monitor-logs	Zugriffslogs eines Monitors analysieren: overview, timeseries, peak-hours, top oder errors. Erfordert Log-Versand. Besucher-IP-Adressen werden standardmäßig zurückgehalten (personenbezogene Daten deiner Besucher) und nur bei gesetztem include_client_ips geliefert

Benachrichtigungen & Eskalation

Tool	Beschreibung
list-notification-channels	Konfigurierte Kanäle (E-Mail, Slack, Webhook usw.). Secrets sind maskiert
list-notification-rules	Regeln, die Ereignisse auf Kanäle abbilden
list-escalation-policies	Mehrstufige Eskalationsrichtlinien und ihre Wartezeiten
list-on-call-schedules	Bereitschaftspläne und ihre Rotationen
get-current-on-call	Wer gerade Bereitschaft hat

Team & Audit

Tool	Beschreibung
list-accessible-tenants	Die Teams, die diese Verbindung erreichen kann
list-team-members	Mitglieder eines Teams und ihre Rollen
get-audit-log	Wer was wann geändert hat – Monitore, Vorfälle, Status-Pages, Kanäle, Teammitglieder, Tokens und mehr, inklusive der über diesen MCP-Server ausgeführten Aktionen. Benötigt settings:read. Vollständige Änderungs-Diffs nur für Admins

Schreibaktionen

Jede benötigt den passenden :write-Scope, einen Tarif mit vollem API-Zugriff und ein Team, das nicht pausiert ist. Eine schreibgeschützte Verbindung kann keine davon aufrufen.

Tool	Scope	Wirkung
acknowledge-incident	incidents:write	Bestätigt einen offenen Vorfall und stoppt die Eskalation, sodass die Bereitschaft nicht mehr gerufen wird. Abgelehnt, wenn bereits gelöst oder bestätigt
add-incident-update	incidents:write	Postet ein Update in die Vorfall-Chronik (max. 5000 Zeichen, max. 200 pro Vorfall). resolved schließt den Vorfall und sendet die Entwarnung an Abonnenten
snooze-check	checks:write	Stellt einen Check für 1–10080 Minuten (bis 7 Tage) stumm. Der Check läuft weiter, alarmiert nur nicht. Vorzeitig beenden mit unsnooze-check
unsnooze-check	checks:write	Beendet die Stummschaltung vorzeitig. Auf nicht stummgeschalteten Checks gefahrlos aufrufbar
trigger-check-run	checks:write	Führt einen Check sofort aus. Höchstens einmal pro 60 s pro Check, 10 Läufe pro Minute insgesamt
create-maintenance-window	maintenance:write	Plant ein Wartungsfenster, damit geplante Arbeiten keine Vorfälle auslösen. Titel, Start, Ende (≤ 30 Tage auseinander) und optional die abgedeckten Monitore. Erscheint auf deinen Status-Pages
post-status-page-update	status-pages:write	Veröffentlicht ein Status-Page-Update – öffentlich sichtbar und an jeden bestätigten Abonnenten gemailt. Max. 5 pro Minute, 500 pro Seite. Übersetzungen pro Sprache müssen im Dashboard veröffentlicht werden
set-check-enabled	checks:write	Schaltet einen Check an oder aus. Deaktivieren stoppt den Check (Lücke in der Uptime-Historie) – um Daten zu behalten und nur Alarme zu unterdrücken, snooze-check nutzen
set-incident-state	incidents:write	Lifecycle-Aktionen: snooze (60/240/480/1440 Min), unsnooze, archive (nur gelöste), unarchive
update-incident	incidents:write	Ändert Titel, Schweregrad oder Status ohne Eintrag in die öffentliche Chronik. resolved schließt und sendet einmalig die Entwarnung
create-incident	incidents:write	Öffnet einen Vorfall von Hand. Das benachrichtigt Personen – die incident.created-Regeln des Teams greifen. Max. 100 offen pro Team, 5 pro Minute
create-monitor	monitors:write	Erstellt einen Monitor mit den Checks seiner Vorlage. Zählt gegen das Monitor-Limit des Tarifs; das Intervall darf das Tarif-Minimum nicht unterschreiten; private und interne Adressen werden abgelehnt
update-monitor	monitors:write	Umbenennen, Ziel/Intervall ändern, pausieren oder fortsetzen. Der Typ eines Monitors kann nach der Erstellung nicht geändert werden
update-maintenance-window	maintenance:write	Verschiebt ein Fenster, ändert seine Monitore oder hebt es mit is_active: false auf

Eine Schreibaktion wird nie auf mehr als ein Team angewandt. Kann deine Verbindung mehrere Teams erreichen, übergib tenant_id an das Schreib-Tool – es lehnt ab, statt zu raten. Jede Schreibaktion und jeder abgelehnte Versuch wird im Audit-Log des Ziel-Teams festgehalten, mit dem verwendeten Tool und dem dahinterstehenden Token.

Beispiel-Gespräche

Frag in natürlicher Sprache; der Assistent wählt die richtigen Tools, verkettet mehrere bei Bedarf und fasst zusammen.

Gesundheit & Uptime – „Ist gerade ein Monitor down?" · „Wie ist die durchschnittliche Uptime aller Monitore diesen Monat?" · „Welche Monitore hatten die schlechteste Uptime der letzten 30 Tage?"

Performance & Trends – „Wie ist die p95-Antwortzeit meines API-Monitors?" · „Zeig den Antwortzeit-Trend der Checkout-Seite über 7 Tage." · „Wie stehen meine Core Web Vitals auf der Startseite?"

Zertifikate, Domains & Links – „Welche SSL-Zertifikate laufen in den nächsten 30 Tagen ab?" · „Haben sich DNS-Einträge geändert?" · „Gibt es kaputte Links auf meiner Marketing-Seite?"

Vorfälle – „Welche Vorfälle gab es in den letzten 7 Tagen?" · „Gib mir die vollständige Chronik des letzten Vorfalls am API-Monitor."

Cron & Agenten – „Hat eine geplante Aufgabe ihren letzten Lauf verpasst?" · „Wie sind CPU und Speicher auf meinen gemeldeten Servern?"

Alarmierung & Bereitschaft – „Welche Kanäle sind konfiguriert, und sind welche deaktiviert?" · „Erklär mir, wie ein unbestätigter Vorfall eskaliert." · „Wer hat gerade Bereitschaft?"

Mehrere Teams – „Welche Teams erreicht diese Verbindung?" · „Vergleiche die Uptime über alle meine Teams diesen Monat."

Ein guter Einstieg: „Gib mir eine Gesundheitsübersicht – ist etwas down, gab es Vorfälle in den letzten 24 Stunden, laufen Zertifikate bald ab?" Der Assistent fächert über die passenden Tools auf und liefert eine lesbare Zusammenfassung.

Rate-Limiting

Der MCP-Endpunkt hat eigene Limits, getrennt von der REST-API:

Bereich	Limit
Pro Token	60 Anfragen pro Minute
Pro Team	200 Anfragen pro Minute (über alle Tokens)

Schreib-Tools tragen darüber hinaus eine zweite, engere Team-Drossel. Ein überschrittenes Limit liefert 429 Too Many Requests.

Sicherheit

• Lesen per Default, Schreiben nur wo aufgeführt. Jedes Tool außerhalb „Schreibaktionen" ist schreibgeschützt, und kein Tool löscht.
• Zustimmung mit geringsten Rechten. Der OAuth-Zustimmungsbildschirm wählt Nur-lesen vor, egal was der Client anfragt; Handlungszugriff ist stets eine bewusste Wahl und umfasst nie Team-, Abrechnungs- oder Einstellungsänderungen.
• Scope-gebunden. Ein Tool funktioniert nur, wenn die Verbindung den passenden Scope hält; eine Schreibaktion braucht einen :write-Scope.
• Schreibaktionen treffen genau ein Team, werden auditiert (Erfolg wie Ablehnung) und gegen deine Rolle in diesem Team geprüft – Admin in einem Team zu sein gewährt nichts in einem anderen.
• Audience-gebundene Tokens. Ein OAuth-Token ist an die Domain gebunden, auf der es erteilt wurde, und wird anderswo abgelehnt – eine Freigabe auf einem Reseller-Portal lässt sich nicht gegen app.hoppla.dev verwenden, und umgekehrt.
• Team-Isolation. Eine Verbindung liest nur die Teams, für die sie autorisiert ist. Die Ressourcen-ID eines anderen Teams liefert dasselbe „nicht gefunden" wie eine nicht existierende.
• Credential-Maskierung. Webhook-URLs, Agent-Tokens und Kanal-Secrets werden nie offengelegt.
• Widerrufbar. Trenne eine OAuth-App unter Entwickler in deinem Dashboard, oder lösche ein API-Token unter Einstellungen → API-Tokens – beides kappt den Zugriff sofort.