# Agentur-Workflows mit MCP und n8n: Kundenstatus abfragen, ohne Dashboard-Login

> Dein Assistent liest Monitore, Vorfälle und Uptime-Werte selbst und beantwortet die Statusfrage deines Kunden in Sekunden.

Source: https://uptimeify.io/de/blog/agentur-workflows-mcp-n8n

Ein KI-Assistent kann den Status deiner Kundenseiten selbst abrufen, ohne dass jemand aus deinem Team das Dashboard öffnet. Möglich macht das ein MCP-Server: eine standardisierte Schnittstelle, über die ein Assistent Monitore, Vorfälle und Uptime-Werte liest. Der Kunde fragt im Slack-Kanal, ob seine Seite läuft, und bekommt zwanzig Sekunden später die Uptime der letzten 30 Tage und den letzten Vorfall. Nicht, weil jemand schneller klickt. Sondern weil der Assistent die Daten selbst holt.

- Der MCP-Server von Uptimeify liefert 20 Check-Tools ohne Konto und 13 Lese-Tools für deine eigenen Daten: `list_monitors`, `monitor_status`, `list_incidents`, `check_history`, `uptime_summary`, `list_alert_channels`, `alert_history`, `list_status_pages`, `list_maintenance_windows`, `get_organization`, `list_users`, `list_customers`, `billing_summary`.
- Agent-Tokens sind read-only. Jeder Schreibversuch endet mit 403 und `data.code = agentTokenReadOnly`.
- Der `api.read`-Scope reicht auf `GET /api/websites*`, `GET /api/incidents*` und `GET /api/health`, gebunden an die Organisation des freigebenden Users.
- Drei Workflows tragen sich sofort: Statusabfrage im Chat, Uptime-Zusammenfassung als Textbaustein für den Monatsreport, Incident-Kontext beim Anlegen eines Tickets.

## Der Workflow, bevor es ihn gab: warum Statusfragen teuer sind

Statusfragen kosten dich nicht Minuten, sondern Kontextwechsel. Die Frage kommt im Slack-Kanal des Kunden an, beantwortet wird sie in einem anderen Werkzeug: Dashboard öffnen, einloggen, Kunde suchen, Monitor öffnen, Zeitraum umstellen, Zahl ablesen, zurück in den Kanal, Antwort formulieren. Acht Schritte für einen Satz.

Rechne das gegen dein Portfolio. Bei 40 betreuten Seiten und zwei bis drei Statusfragen pro Woche sind das mehrere Stunden im Monat, verteilt in Zwei-Minuten-Häppchen quer durch den Tag. Jede einzelne ist zu klein, um sie zu notieren, und keine davon steht auf einer Rechnung.

Der eigentliche Schaden liegt woanders. Die Antwort kommt spät, sie kommt knapp, und sie kommt ohne Beleg. "Läuft alles" ist keine Serviceleistung, sondern eine Beruhigung. Damit verschenkst du genau den Moment, in dem der Kunde von sich aus nach dem Wert deines Retainers fragt.

Eine Statusfrage ist keine technische Aufgabe. Sie ist der günstigste Anlass, den Wert deines Retainers zu belegen, und der teuerste, wenn du ihn verstreichen lässt.

## Was sich ändert, wenn der Assistent die Monitore lesen darf

Das Model Context Protocol ist ein offener Standard, über den ein KI-Assistent Werkzeuge einer fremden Anwendung direkt aufruft, statt deren Oberfläche zu bedienen. Der Assistent bekommt eine Liste verfügbarer Tools, wählt das passende, ruft es auf und arbeitet mit dem Ergebnis weiter.

Uptimeify betreibt dafür einen zustandslosen MCP-Server unter `POST https://uptimeify.io/mcp` über Streamable HTTP. 20 Check-Tools laufen ohne Konto und ohne Token, darunter `check_ssl`, `check_dns`, `whois` und `website_status`. 13 weitere Tools lesen deine eigenen Daten, sobald ein Token vorliegt:

| Tool | Was es liefert | Zugriff |
| --- | --- | --- |
| `list_monitors` | alle Monitore in deiner Organisation | api.read |
| `monitor_status` | aktueller Zustand eines einzelnen Monitors | api.read |
| `uptime_summary` | Uptime und mittlere Antwortzeit für Tag, Monat, Jahr | api.read |
| `list_incidents` | Vorfälle über dein Portfolio hinweg | api.read |
| `check_history` | die letzten Prüfungen eines Monitors | api.read |
| `list_alert_channels` | die Benachrichtigungskanäle, über die du alarmiert wirst | api.read |
| `alert_history` | welche Alarme für einen Monitor rausgingen und ob sie ankamen | api.read |
| `list_status_pages` | deine Statusseiten mit Slug, Sichtbarkeit und eigener Domain | api.read |
| `list_maintenance_windows` | deine geplanten Wartungsfenster | api.read |
| `get_organization` | deine eigene Organisation: Name, öffentliche Kennung, Kontozustand | api.read |
| `list_users` | die Mitglieder deiner Organisation, mit Rolle und Beitrittsdatum | api.read |
| `list_customers` | deine Kunden, mit Zustand und Monitor-Zahlen | api.read |
| `billing_summary` | SMS-Verbrauch des laufenden Monats, je Kunde und in Summe | api.read |
| `website_status`, `check_ssl`, `check_dns` und 17 weitere | öffentliche Prüfungen für beliebige Domains | ohne Konto |

Der Unterschied im Alltag ist nicht die Datenmenge, sondern der Ort. Die Frage wird dort beantwortet, wo sie gestellt wurde. Niemand wechselt das Werkzeug, niemand loggt sich ein, und die Antwort trägt eine Zahl statt einer Beruhigung.

## Drei konkrete Agentur-Workflows

### Statusabfrage im Chat, statt Dashboard-Login

Der Kunde fragt, ob seine Seite läuft. Dein Team stellt die Frage an den Assistenten weiter, wörtlich: "Wie war die Uptime dieser Kundendomain in den letzten 30 Tagen, und wann war der letzte Vorfall?"

Der Assistent zieht sich die Antwort in drei Schritten: `list_monitors`, um den Monitor zu finden, `uptime_summary` für den Zeitraum, `list_incidents` für den letzten Vorfall. Zurück kommt ein Satz mit Prozentwert, Datum und Dauer. Der Account-Manager liest ihn, prüft ihn kurz und schickt ihn in den Kundenkanal. Zwanzig Sekunden statt acht Schritten.

Wichtig für die Qualität der Antwort: Die Zahlen kommen aus deinem Konto, nicht aus dem Sprachmodell. Der Assistent formuliert, er schätzt nicht.

### Report-Vorarbeit: die Uptime-Zusammenfassung als Textbaustein

Der Monatsreport ist Pflicht, aber der Kommentar davor ist Handarbeit. Genau die lässt sich vorbereiten: `uptime_summary` für den Monat, `list_incidents` für die Vorfälle im selben Zeitraum, daraus zwei bis drei Sätze in der Sprache, die dein Kunde versteht.

Der fertige Report kommt weiterhin white-labeled aus der Plattform. Der Assistent liefert die Einordnung, nicht die Daten und nicht das PDF. Wie du den Report selbst aufbaust, steht im Leitfaden zum [SLA-Report für Kunden](/de/blog/sla-report-fuer-kunden-erstellen).

### Incident-Kontext im Ticket: die letzten Vorfälle beim Anlegen

Ein Support-Ticket zu einer Kundenseite geht ein. Bevor jemand es übernimmt, holt der Assistent über `list_incidents` und `check_history` die letzten Vorfälle zu genau diesem Monitor und hängt sie an das Ticket.

Der Bearbeiter sieht auf den ersten Blick, ob er es mit einem Einzelfall oder mit dem vierten Aussetzer in zwei Wochen zu tun hat. Das verändert die Priorität, die Antwort an den Kunden und die Frage, ob hier ein Hosting-Gespräch fällig ist.

Alle drei Workflows setzen auf derselben Datenbasis auf wie deine bestehenden Automatisierungen. Wie Onboarding, Reporting und Alarmierung über die API zusammenspielen, zeigt die Übersicht zu den Integrationen.

## n8n und MCP: der Server als Node in bestehenden Automatisierungen

Wenn deine Automatisierung schon in n8n liegt, brauchst du keinen zweiten Ort dafür. n8n kennt zwei Richtungen: Die MCP Client Tool Node hängt sich als Werkzeug an einen AI Agent und ruft einen externen MCP-Server auf. Die MCP Server Trigger Node macht den umgekehrten Weg und stellt deine eigenen Workflows als Tools bereit.

Für Uptimeify ist die erste Richtung relevant. Ein typischer Ablauf aus der Agenturpraxis:

1. **Trigger:** Eine Nachricht im Kundenkanal enthält ein Stichwort wie "Status" oder "erreichbar".
2. **AI Agent:** Ein Agent-Node mit klarer Systemanweisung, welcher Kunde zu welchem Kanal gehört.
3. **MCP Client Tool:** Verbindung auf den Uptimeify-MCP-Server, Authentifizierung per Bearer-Token.
4. **Antwort:** Der Agent formuliert die Antwort und postet sie zurück in den Thread, oder legt sie als Entwurf ab, wenn ein Mensch gegenlesen soll.

Zwei Details, die im Aufbau Zeit sparen. Erstens: Der Access-Token läuft nach 3600 Sekunden ab. Eine Automatisierung, die dauerhaft läuft, muss ihn also turnusmäßig neu ausstellen statt ihn einmalig zu hinterlegen. Zweitens: Prüfe in deiner n8n-Version, welchen Transport die MCP Client Tool Node anbietet. Die Node hat mit SSE begonnen, Streamable HTTP kam später dazu, und der Uptimeify-Endpunkt spricht Streamable HTTP.

Die Rate Limits sind für diesen Einsatz großzügig gesetzt: 120 Anfragen pro Minute und IP auf dem Endpunkt, 60 pro Minute je authentifiziertem Tool. Eine Agentur mit ein paar Dutzend Kunden bewegt sich weit darunter. Wer darüber liegt, bekommt eine 429 und weiß, dass er die Schleife falsch gebaut hat.

## Was der Assistent nicht darf, und warum das ein Verkaufsargument ist

Agent-Tokens bei Uptimeify sind read-only. Jeder Schreibversuch endet mit 403 und `data.code = agentTokenReadOnly`. Das gilt unabhängig davon, was im Prompt steht: Ein Agent kann keinen Monitor anlegen, keinen pausieren, kein Wartungsfenster setzen und keinen Vorfall quittieren.

Der Zugriff ist zusätzlich zweifach eingegrenzt. Der `api.read`-Scope reicht auf `GET /api/websites*`, `GET /api/incidents*` und `GET /api/health`, gebunden an die Organisation des Users, der die Freigabe erteilt hat, oder an einen einzelnen Kunden darin. Und die Freigabe selbst erteilt ein eingeloggter Mensch über eine Bestätigung, nicht der Agent für sich selbst.

Das ist der Teil, den du im Kundengespräch brauchst. Wenn ein Endkunde fragt, ob "jetzt eine KI an unseren Systemen hängt", ist die Antwort keine Beteuerung, sondern eine Aufzählung: Lesezugriff, drei Endpunkte, Token nach einer Stunde abgelaufen, Freigabe durch einen Menschen, jederzeit widerrufbar. Dazu die Infrastruktur, auf der das läuft: europäischer Stack, Frankfurt, ohne US-Sub-Prozessoren. Diese Punkte nimmst du in dein Sicherheitskapitel auf, so wie du es beim Zugriff auf das CMS auch tust.

Ein Agent, der nichts verändern kann, ist kein Risiko, das du erklären musst. Er ist ein Absatz, den du in dein Angebot schreibst.

## Grenzen: was heute noch nicht geht

**Schreiben bleibt außen vor.** Onboarding, Konfigurationsänderungen und alles, was Zustand verändert, laufen weiter über das Dashboard oder ein reguläres API-Token, das ein Mensch ausstellt. Wie das per API aussieht, zeigt der Beitrag zum [Kunden-Onboarding per API](/de/blog/kunden-onboarding-per-api).

**Die Stunde ist die Einheit.** Der Access-Token läuft nach 3600 Sekunden ab. Für einen Chat ist das unsichtbar, für eine dauerhaft laufende Automatisierung ist es ein Baustein, den du einplanen musst.

**Der Assistent liest, er urteilt nicht.** 99,2 Prozent Uptime können ein geplantes Wartungsfenster sein oder ein Hosting-Problem. Diese Einordnung kommt von dir, und genau dafür zahlt dein Kunde den Retainer.

**MCP ersetzt keine Alarmierung.** Ein Assistent antwortet, wenn er gefragt wird. Ein Vorfall um drei Uhr nachts fragt niemanden. Die Alarmierung läuft weiter über Eskalationsketten und Kanäle, MCP liegt daneben und beantwortet Fragen am Tag.

Endpunkt, Tool-Liste und Freigabe-Ablauf stehen vollständig auf der MCP-Seite. Wer heute schon einen Assistenten im Team nutzt, hängt ihn in wenigen Minuten dran.

Der Unterschied zwischen einer Agentur, die Monitoring betreibt, und einer, die es verkauft, war nie das Werkzeug. Es war immer die Frage, wie schnell und wie belegt der Kunde eine Antwort bekommt. MCP verkürzt diesen Weg auf einen Satz im Chat. Was du daraus machst, bleibt deine Arbeit.