Verbundene Apps (OAuth-Verbindungen)

Mit Uptimeify kannst du Drittanbieter-Apps (wie Claude Desktop / Claude.ai) per MCP-OAuth verbinden. Mit diesen beiden Endpunkten kann der angemeldete Nutzer seine eigenen Verbindungen auflisten und widerrufen. Sie stehen hinter der Seite Einstellungen → Verbundene Apps im Dashboard.

Beide Endpunkte sind session-authentifiziert (Browser-Cookie), nicht token-basiert: sie gehören nicht zur wsm_-/wsma_-API-Token-Oberfläche, und jede Operation ist strikt auf die eigenen Verbindungen des Aufrufers beschränkt.

Scopes

Eine Verbindung trägt Scopes, und jeder davon deckt genau einen Bereich deiner Monitoring-Daten ab. Insgesamt gibt es vierzehn: sieben Lese-Scopes plus deren Sammel-Alias mcp:read, und sechs Schreib-Scopes, mit denen die Verbindung Daten in diesem Bereich ändern statt nur ansehen darf.

Lese-Scopes

mcp:read ist der Scope, den ein Client anfragt, wenn er Lesezugriff ohne Bereichsangabe will. Er ist auf die drei Betriebsbereiche eingefroren, die es bei seiner Einführung gab (Monitore, Vorfälle, Prüfhistorie), und wächst mit keinem neuen Bereich mit: die vier neueren Lesebereiche -- Alarme, Statusseiten, Organisation, Abrechnung -- müssen namentlich angefragt werden, erst dann bietet die Zustimmungsseite sie an. Verbindungen aus der Zeit vor den feinen Scopes tragen ihn ebenfalls und bleiben unverändert.

Schreib-Scopes

Alle sechs stehen heute für echte Werkzeuge: mcp:monitors:write schaltet sechs Tools frei (pausieren, fortsetzen, umbenennen, Prüfintervall ändern, einen Monitor anlegen und löschen), mcp:incidents:write vier (bestätigen, lösen, ein Update posten, einen manuellen Incident löschen), mcp:maintenance:write drei (ein Wartungsfenster anlegen, ändern und löschen), mcp:statuspages:write acht (eine Statusseite anlegen, ändern und löschen, ihre Gestaltung ändern, sowie eine eigene Domain hinzufügen, verifizieren, aktivieren und löschen), mcp:alerts:write drei (einen Benachrichtigungskanal anlegen, ändern und löschen; anlegen geht nur für email- und sms-Kanäle, und keines der drei vergleicht vor dem Schreiben einen Zustand) und mcp:organization:write neunzehn -- fünf für Etiketten, drei für eigene Felder, drei für geplante Berichte, eines für ein Mitglied und sieben für Kundschaften samt ihren überwachten Domains und IP-Adressen. Die vollständige Liste mit allem, was jedes Tool tut, steht unter Authentifizierte Tools (schreibend). Drei Dinge bietet dieser Bereich bewusst nicht, was der Scope-Name auch nahelegen mag: es gibt kein Werkzeug, das ein Mitglied anlegt, und keines, das eines löscht, sondern nur eines, das ein bestehendes ändert oder deaktiviert; es gibt keine Sammel-Kundenpflege und keinen Weg, einen Bericht von Hand zu versenden; und die Stammdaten der Organisation lassen sich gar nicht ändern. Zwei weitere Punkte lohnen sich, bevor du ihn gewährst: delete_custom_field löscht kein Feld, es nimmt es aus den Formularen und der Kundentabelle, während die Definition und jeder erfasste Wert in der Datenbank bleiben, und delete_tag streicht das Etikett aus jedem Wartungsfenster, das es benutzt hat, was ein Fenster ganz ohne Umfang zurücklassen kann. update_user und update_customer sind die einzigen zwei Werkzeuge des Bereichs, die vor dem Schreiben den Zustand eines Datensatzes vergleichen, und auch das nur, wenn die Verbindung zusätzlich mcp:organization:read hält. Die Zustimmungsseite bietet alle sechs Schreibbereiche als eigene Häkchen an, getrennt von den Lesebereichen gruppiert, damit ein Haken dort eine bewusste, eigene Entscheidung ist.

Ob ein Schreib-Scope überhaupt etwas bewirkt, hängt zusätzlich von der Bereitstellung ab, unabhängig davon, welche Scopes es gibt. Schreib-Werkzeuge werden nur registriert, wenn die Bereitstellung sie eingeschaltet hat; ist das nicht der Fall, kann eine Verbindung, die jeden Scope aus dieser Tabelle hält, trotzdem nichts anlegen, ändern oder löschen. Frag die Person, die deine Uptimeify-Instanz betreibt, statt es allein aus dem Scope-Katalog zu schließen.

Bewusst fehlt mcp:billing:write und jeder Scope für Zugangsdaten -- nichts hier kündigt ein Abo, ändert ein Paket oder prägt ein eigenes API-Token.

Ein Häkchen bei einem Schreib-Scope auf der Zustimmungsseite hakt automatisch auch seinen gleichnamigen Lese-Zwilling mit an (mcp:monitors:write hakt mcp:monitors:read mit an, mcp:incidents:write entsprechend mcp:incidents:read): Die Schreib-Werkzeuge vergleichen den aktuellen Zustand eines Datensatzes, bevor sie schreiben, um einen Schreibvorgang nicht zu wiederholen, den ein Modell schon gemacht hat, und dieser Vergleich braucht Lesezugriff auf dieselben Daten. mcp:maintenance:write ist der einzige Schreib-Scope ohne Zwilling, und das ist Absicht -- Wartungsfenster werden unter mcp:statuspages:read gelesen und bleiben dort.

Alle 14 Scopes -- die sieben Lesebereiche, der mcp:read-Alias und die sechs Schreibbereiche -- stehen in den OAuth-Discovery-Dokumenten (/.well-known/oauth-authorization-server und /.well-known/oauth-protected-resource). Ein Client muss sie also nicht kennen, er findet sie. Fragt ein Client gar keinen MCP-Scope an, weisen wir ihn nicht ab: mcp:read kommt zur Anfrage dazu, damit die Zustimmungsseite weiterhin die drei Betriebsbereiche anbietet, die dieser Alias deckt, und jeder davon abwählbar bleibt. Eine Anfrage, die bereits einen MCP-Scope nennt, bleibt unangetastet und wird nie aufgeweitet.

Ein Token sieht nur die Werkzeuge, deren Scope ihm gewährt wurde. Eine Verbindung mit ausschließlich mcp:incidents:read listet in tools/list genau list_incidents und kein weiteres kontogebundenes Werkzeug: der Rest ist nicht bloß versteckt, sondern gar nicht vorhanden, und ein Aufruf trotzdem wird abgewiesen. Ein Token ganz ohne MCP-Scope sieht keine kontogebundenen Werkzeuge. Bis zum 1. Dezember 2026 gilt eine Ausnahme: Verbindungen aus der Zeit vor der Veröffentlichung der Scopes tragen nur Identitäts-Scopes. Bis zu diesem Datum wird ein solches Token behandelt, als trüge es mcp:read, damit es weiterarbeitet. Die Ausnahme greift ausschließlich bei einem Token ganz ohne MCP-Scope, nie bei einem mit einem einzelnen Bereich, und sie endet zu diesem Datum ohne weitere Ankündigung: danach sieht ein reines Identitäts-Token keine kontogebundenen Werkzeuge mehr. Eine Verbindung neu zu autorisieren ersetzt sie jederzeit durch einen echten, verengbaren Scope. Die anonymen Prüfwerkzeuge auf /mcp (DNS, TLS, WHOIS und die übrigen) brauchen kein Token und stehen außerhalb dieses Systems.

Bei einem Werkzeug hängt nicht nur die Sichtbarkeit, sondern die Antwort selbst an einem zweiten Scope: billing_summary nennt die Kunden seiner Verbrauchsaufschlüsselung nur dann beim Namen, wenn neben mcp:billing:read auch mcp:organization:read freigegeben wurde. Mit der Abrechnung allein trägt die Aufschlüsselung öffentliche Kennungen und Verbrauchswerte und keine Namen -- die Kundenliste gehört zum Organisationsbereich und kommt nicht über den Verbrauch zurück.

Zustimmung

Jede Autorisierung führt über eine Zustimmungsseite. Sie nennt die anfragende Anwendung, nennt das Konto, mit dem sie verknüpft wird, und bietet jeden Lese- und Schreibbereich als eigenes Häkchen an, wobei die Schreibbereiche getrennt von den Lesebereichen gruppiert sind, damit das Gewähren eines Schreib-Scopes eine bewusste, eigene Entscheidung ist. Ein abgewähltes Häkchen entfernt den Scope, bevor der Autorisierungscode entsteht: das ausgegebene Token ist dann enger als das, was der Client angefragt hat.

prompt wird bei uns auf consent gezwungen. Eine Autorisierungsanfrage kann die Seite also weder durch Weglassen des Parameters noch durch einen anderen Wert überspringen. Die einzige Anfrage, die wir nicht umschreiben, ist prompt=none: sie bedeutet „zeige keine Oberfläche", und da wir ohne Zustimmung nichts mehr ausgeben, ist die Antwort der Fehler-Redirect, den OpenID Connect dafür vorsieht, statt einer Seite. Ohne Sitzung lautet der Code login_required, mit Sitzung consent_required.

Die Seite schickt ihre Auswahl an einen session-gebundenen Endpunkt. Der prüft, ob die offene Autorisierung zum angemeldeten Konto gehört, und verengt den gespeicherten Scope auf das Angehakte. Dieser Endpunkt gehört nicht zur öffentlichen API-Oberfläche; seine Fehlercodes stehen unter Fehlercodes.

Verbindungen auflisten

GET /api/oauth/connections

Liefert die eigenen, aktiven OAuth-Verbindungen des Aufrufers, einen Eintrag pro verbundenem Client. „Aktiv" bedeutet, dass die Berechtigung noch ein offenes Refresh-Fenster hat. Ohne Verbindungen liefert der Endpunkt ein leeres Array.

Beispiel (cURL)

curl -X GET "$BASE_URL/api/oauth/connections" \
  -H "Cookie: $SESSION_COOKIE" \
  -H "Accept: application/json"

Antwort

[
  {
    "client_id": "claude-desktop",
    "client_name": "Claude",
    "connected_at": "2026-06-01T09:12:00.000Z",
    "last_active": "2026-07-20T14:03:00.000Z",
    "scope": "read-only"
  }
]

Eine Verbindung widerrufen

DELETE /api/oauth/connections/:clientId

Widerruft deine eigene Berechtigung für den angegebenen Client: löscht sofort dessen Access-/Refresh-Token und den Consent-Eintrag. Die App verliert den Zugriff sofort; für eine erneute Verbindung muss der Nutzer den OAuth-Zustimmungsprozess erneut durchlaufen.

Beispiel (cURL)

curl -X DELETE "$BASE_URL/api/oauth/connections/claude-desktop" \
  -H "Cookie: $SESSION_COOKIE"

Antwort

{ "revoked": true, "client_id": "claude-desktop" }

Häufige Fehler