Ich betreibe 5 SaaS-Apps und weiß nie, welche gerade brennt. Also gab ich Claude ein Tool, um alle zu überwachen.

43 ungelesene Discord-Nachrichten. Fünf Backup-Bestätigungen, alle grün. Ein Content-Bot, der über Nacht 3 Artikel auf Shopify veröffentlicht hat. Ein Credit-Audit, das einen User mit 10 statt 600 Credits markiert. Und ein RSS-Feed, der seit 3 Stunden kaputt ist, aber niemand hat's gemerkt, weil der Alert unter 12 Erfolgsmeldungen begraben wurde.

Alles ist in Ordnung UND irgendwas brennt. Ich kann nur nicht sagen was, ohne alle 43 zu lesen, sie mental nach Schweregrad zu sortieren und dann kanalübergreifend abzugleichen.

Fünf SaaS-Produkte. Convex hier, Supabase da, n8n-Crons überall. Jedes Produkt meldet sich in seinem eigenen Discord-Kanal in seinem eigenen Format. Jeder Kanal mischt Routine-Bestätigungen mit echten Notfällen. Das Rausch-zu-Signal-Verhältnis liegt bei etwa 15 zu 1.

Das Monitoring funktioniert. Jede App meldet sich. Backups bestätigen. Credit-Audits markieren. Content-Pipelines loggen. Die Daten existieren.

Aber ich wurde zur Aggregationsschicht.

Der Typ, der 4 Kanäle, 2 Dashboards und ein n8n-Execution-Log öffnet, um mental ein Bild von "wie läuft alles" zu rekonstruieren. App 1 ist okay. App 2 hat ein kleines Problem. App 3 hat ein Problem, das vor 3 Stunden Aufmerksamkeit gebraucht hätte. Ich wusste es nur nicht, weil der Alert Benachrichtigung 37 von 43 war.

Falls du wie ich bist, hast du wahrscheinlich versucht, das zu lösen, indem du mehr Tools gebaut hast 🤓. Ein Custom-Dashboard hier. Ein Slack-Bot da. Ein wöchentliches Summary-Script. Glückwunsch, du hast jetzt 5 SaaS-Produkte UND 3 Monitoring-Tools zum Überwachen. Du hast die Fragmentierung nicht gelöst. Du hast eine Schicht hinzugefügt.

Ein einheitliches Dashboard kam mir in den Sinn. Dann wurde mir klar, dass das ein sechstes Produkt zum Warten ist. Und es erfordert immer noch, dass ich es anschaue, interpretiere, entscheide, was wichtig ist. Was ich eigentlich brauchte, war etwas, das alle 5 Quellen abfragen und eine Frage beantworten kann, nicht noch einen Bildschirm.

Also gab ich Claude ein Custom-Tool, um alle meine Apps auf einmal zu erreichen. Baute es als MCP-Server auf Next.js, deployed auf Vercel, verbunden mit Convex, Supabase, meiner Content-API und einem Discord-Adapter. Die Idee war simpel. Die Umsetzung hätte das Projekt fast getötet.

---

Vor dem Build: wann du das wirklich brauchst

Ich setze diesen Abschnitt an den Anfang, weil ich vor 6 Monaten fast etwas gebaut hätte, was ich nicht brauchte, und ich will nicht, dass du denselben Fehler machst. Ein persönlicher MCP-Server ist das richtige Tool zu einem bestimmten Zeitpunkt. Vor diesem Zeitpunkt ist es resume-driven development.

Wenn du ein Projekt auf einem Stack betreibst, reichen Discord-Benachrichtigungen und ein Health-Check-Endpoint. Vielleicht Grafana. Du siehst alles von einem Ort aus. Falls du hier bist und über MCP nachdenkst, hör auf. Bau stattdessen Features.

Zwei oder drei Projekte auf ähnlichen Stacks? Ein geteiltes Dashboard reicht. CLI-Scripts handhaben Ad-hoc-Checks. Ich behaupte immer noch, dass CLIs MCP für Single-Purpose-Agent-Tasks schlagen und nichts an diesem Projekt hat diese Meinung geändert. Wenn dein Agent eine Aktion gegen ein System ausführen muss, ist ein CLI einfacher und vorhersagbarer. Jedes Mal.

Drei bis fünf Projekte auf gemischten Stacks – da fängt es an wehzutun. Convex hier, Supabase da, Custom-REST-APIs, verschiedene Auth-Systeme, verschiedene Datenformen. Kein einzelnes Tool fragt alle ab. Deine Morgenroutine umfasst 3 Tabs und Discord-Scrollen. Du fängst an, Sachen zu übersehen. Nicht weil es dir egal ist, sondern weil das Aggregieren von 4 verschiedenen Formaten vor dem Kaffee übersteigt, was ein menschliches Gehirn um 7 Uhr morgens tun sollte.

Fünf plus, du merkst, du bist die Middleware. Jede Quelle funktioniert einzeln gut. Das Problem ist die Synthese. "Welche meiner Apps braucht Aufmerksamkeit" erfordert das Abfragen von 4 Datenbanken, Ergebnisse vergleichen, nach Schweregrad ranken. Ein Dashboard kann das nicht. Ein LLM mit Zugang zu deinen Daten kann es.

Ich war solide in dieser letzten Phase, bevor ich es zugegeben habe.

Die Schwelle, die ich vorschlagen würde: wenn du mehr als 15 Minuten täglich damit verbringst, zwischen Monitoring-Quellen zu wechseln, und die Daten über API oder Datenbank zugänglich sind, zahlt sich das in der ersten Woche aus.

Das 16-Commit-Desaster

Ich dachte, das würde 10 Minuten dauern 😬. Ein MCP-Server sind ein paar Route-Handler, ein paar Tool-Definitionen, auf Vercel deployen, fertig. Ich dachte schon darüber nach, was ich zum Abendessen kochen würde, als ich anfing.

Vier Stunden später debuggte ich immer noch OAuth. Es dauerte 4 Stunden, etwa 40 Hin-und-Her-Austausche mit Claude Code, geschätzte 8–12 Dollar in API-Tokens und 16 Commits, um einen funktionierenden Prototyp zu bekommen. Das Git-Log am nächsten Morgen anzuschauen war demütigend.

Der MCP-Server selbst ist eine einzige Next.js-App. Sechs Route-Files, ein Utility-Modul. Du deklarierst Tools, die Claude aufrufen kann, jedes Tool fragt eine Datenquelle ab, Claude entscheidet basierend auf deiner Frage, welche Tools zu verwenden sind.

app/
├── .well-known/
│   ├── oauth-authorization-server/route.ts
│   └── oauth-protected-resource/route.ts
├── authorize/route.ts
├── token/route.ts
└── mcp/route.ts
lib/
└── oauth.ts

Die Tools zu deklarieren dauerte vielleicht 30 Minuten. Jedes ist eine Funktion mit einem Namen, einer Beschreibung, einem Parameter-Schema und Logik, die Convex oder Supabase oder eine API abfragt. Das ist der einfache Teil. Das Git-Log sagt dir genau, wo die Zeit hingeflossen ist.

Erste Wand: MCP-Sessions. Ich fing mit stateful Sessions an, weil das die SDK-Beispiele zeigen. Auf Vercel deployed. Nichts funktionierte. Serverless-Funktionen behalten keinen State zwischen Aufrufen. Zwei Commits, um das rauszureißen und stateless zu werden. Hätte ich wissen müssen. Tat ich nicht.

Zweite Wand: Next.js-Routing. Drei Commits, um herauszufinden, dass die App-Router-Dynamic-Route [transport] Pfadauflösungsprobleme verursachte und ich stattdessen eine feste /mcp-Route brauchte. Dann war der basePath falsch. Dann störte irgendwie ein Favicon. Tâtonnement ist das höfliche Wort.

Dann OAuth.

Sieben Commits. Hier hätte ich das Projekt fast aufgegeben.

Claude.ai erfordert OAuth 2.1 für MCP-Verbindungen. Die Spec definiert Discovery-Endpoints, Authorization-Flows, Token-Exchange, PKCE. Auf dem Papier ist es sauber. In der Praxis sind die Constraints nicht klar genug dokumentiert, um ohne Trial-and-Error zu implementieren. Und jeder Trial erfordert ein vollständiges Vercel-Deployment, weil du den Claude.ai-OAuth-Flow nicht lokal testen kannst. Deployen, 30 Sekunden warten, in Claude auf Connect klicken, zusehen wie es fehlschlägt, den kryptischen Fehler lesen, fixen, redeployen. Wiederholen.

Was ich gelernt habe, indem ich diese 7 Commits verbrannt habe: Claude ignoriert die Endpoint-URLs, die du in deinen OAuth-Metadaten deklarierst. Du kannst authorization_endpoint den ganzen Tag auf /oauth/authorize setzen. Claude liest das Issuer-Feld und konstruiert die Pfade selbst. Deine Endpoints müssen bei /authorize und /token an der Root sitzen, Punkt. Das fand ich heraus, nachdem ich 3 Mal mit verschiedenen Pfad-Konfigurationen deployed hatte.

Eine andere Art von Fehler: meine Route-Handler gaben Response.json() zurück. Standard Web API. Funktioniert lokal. Funktioniert in Tests. Auf Vercel in Production gibt es eine leere Response ohne Fehler, ohne Log, ohne Hinweis, dass etwas schiefgelaufen ist. Nur eine leere 200 und ein kaputten OAuth-Flow. Der Fix ist NextResponse von next/server. Das fand ich in einem GitHub-Issue mit 3 Upvotes, begraben in einem Thread über etwas völlig anderes.

Und der, der mir einen Abend gekostet hat: Ich setzte mein JWT-Secret mit echo "value" | vercel env add. Der echo-Befehl hängt einen Zeilenumbruch an. Der Zeilenumbruch wird Teil des Secrets. Jede JWT-Signatur schlägt stillschweigend fehl. Jeder Token-Exchange gibt "invalid_grant" zurück. Die Logs sagen nichts Nützliches. Ich führte printf statt echo aus, redeployte, und alles funktionierte. Ich starrte danach eine Weile an die Decke 💀

Das war Commit 14 von 16. Die letzten beiden waren Cleanup.

Das Ganze wären 3 oder 4 saubere Commits gewesen, wenn die Constraints dokumentiert gewesen wären. Aber das ist immer das Spiel, wenn du mit Systemen integrierst, deren exaktes Verhalten du durch Deployen und Scheitern entdeckst. Die MCP-Spec ist noch jung. Claude.ais Implementation hat bekannte Bugs, besonders bei Token-Refresh. Behandle jede MCP-Integration als Production-Prototyp vorerst. Stabil genug für tägliche Nutzung. Nichts, was ich an zahlende Kunden ausliefern würde ohne mehr Härtung.

Für das größere Bild, wie diese Services verbunden sind, habe ich die vollständige Architektur mit Cron-Jobs, Memory und Dashboard in einem vorherigen Artikel dokumentiert. Der MCP-Server fügt sich in dasselbe Muster ein.

Wie es jetzt tatsächlich aussieht

Nach der 16-Commit-Taufe ist hier der Stand der Dinge.

Ich öffne Claude und tippe:

Braucht heute Morgen etwas meine Aufmerksamkeit?

Claude trifft den MCP-Server. Der Server fragt Convex nach User- und Credit-Daten ab, Supabase nach Backup- und Cron-Health, die Content-API nach Publishing-Status und einen Discord-Adapter nach aktuellen Alerts gefiltert nach Schweregrad. Als ich das zum ersten Mal laufen ließ, dauerte die Response 11 Sekunden und die Credit-Daten kamen als roher JSON-Blob zurück, den Claude fröhlich als "einige Finanzinformationen" beschrieb. Nicht gerade die polierte Cockpit-Erfahrung.

Nach dem Tuning der Tool-Beschreibungen und des Response-Formats gibt es etwas tatsächlich Nützliches zurück:

2 Punkte brauchen Aufmerksamkeit:

1. Credit-Anomalie bei [ClientApp]: User sa57*** zeigt 10 Credits,
   erwartet 600. Drift: -590. Vor 14 Stunden markiert, ungelöst.
2. RSS-Feed-Fehler bei ContentForge: "Stories by [author]" seit 
   3h down. Kein neuer Content seit 1:00 Uhr.
Alles andere grün:
- 3/3 Backups abgeschlossen
- Content-Pipeline: 6 gescrapt, 3 veröffentlicht, Social geplant 
  bis 27. Feb
- Keine anderen Anomalien bei 16 aktiven Usern

Was ich nicht erwartet hatte: die Tool-Beschreibungen sind wichtiger als der Code. Claude entscheidet basierend auf den Beschreibungen, die du schreibst, welche Tools aufzurufen sind. Und es interpretiert die Ergebnisse basierend darauf, was du ihm gesagt hast, was das Tool tut.

Moment, lass mich das umformulieren. Es ist nicht so, dass Beschreibungen "wichtiger sind" in irgendeinem abstrakten Sinn. Es ist so, dass ich 2 Stunden damit verbracht habe, TypeScript zu schreiben und 45 Minuten damit, Beschreibungen umzuschreiben, und die Beschreibungen haben zehnmal mehr bewegt.

Mein erster Versuch beim Credit-Monitoring-Tool:

Name: "get_credits"
Description: "Query credit data from Convex"

Claude rief es auf. Bekam rohen JSON zurück. Beschrieb es mir als "einige Finanzinformationen, die User-Balances zu enthalten scheinen." Technisch korrekt. Völlig nutzlos um 6 Uhr morgens.

Zweite Version:

Name: "check_credit_anomalies"  
Description: "Finde User, deren aktuelle Credit-Balance um mehr 
als 10% von ihrer erwarteten Balance abweicht. Gibt User-ID 
(anonymisiert), aktuelle Balance, erwartete Balance und Drift zurück. 
Markiere jede Drift über 50 Credits als dringend."

Dieselben zugrundeliegenden Daten. Dieselbe Convex-Query. Aber jetzt gibt Claude eine priorisierte Liste mit Severity-Flags zurück und sagt mir, welche sofortige Aufmerksamkeit brauchen. Die Beschreibung ist ein Prompt. Behandle sie wie einen. Schreib sie, als würdest du einen Junior-Dev briefen, der wissen muss, was wichtig ist, nicht nur was die Funktion zurückgibt.

Das gilt für jedes Tool. Ein Backup-Checker, beschrieben als "get backup status", gibt dir Timestamps und Dateigrößen. Einer, beschrieben als "prüfe, ob geplante Backups in den letzten 24 Stunden fehlgeschlagen oder überfällig sind, markiere fehlende Backups nach App-Name", gibt dir umsetzbare Antworten.

Mir wurde während dieser Phase klar, dass das TypeScript fast irrelevant ist. Jeder Dev kann eine Funktion schreiben, die Convex abfragt. Der schwere Teil ist, Beschreibungen zu schreiben, die Claude beim ersten Versuch das Richtige tun lassen. Falls du mit Prompt-Contracts gearbeitet hast, gleiches Prinzip. Du teilst nicht mehr Code. Du teilst Intent, Constraints und erwartetes Verhalten. Die Tool-Beschreibung IST der Vertrag zwischen dir und Claude.

Ich kann natürlich nachfassen. "Zeig mir das Transaction-Log dieses Users" schickt Claude mit einer gezielten Convex-Query zurück zum MCP-Server. "Wann hat der RSS-Feed zuletzt funktioniert" trifft ein anderes Tool. Die Unterhaltung fließt, aber die Daten sind darunter strukturiert.

Der Morgen-Check ging von 15 Minuten Scrollen und Context-Switching auf etwa 30 Sekunden und vielleicht eine Nachfrage.

Bei zwei Gelegenheiten in der vergangenen Woche hat es Probleme erwischt, die ich übersehen hätte, bis ein User sich beschwert hätte. Nicht weil die Alerts nicht da waren. Weil sie begraben waren.

Was sich ändert, wenn du Claude Zugang zu deinen echten Daten gibst, ist nicht die Reichweite. Die Daten waren immer da. Du hörst auf, der Router zu sein. Mein Handy summt immer noch jeden Morgen mit 43 Discord-Benachrichtigungen. Ich lese sie nur nicht mehr zuerst.

Der Stack, für die, die einen bauen wollen

Ein sicherer MCP-Server mit OAuth 2.1, deployed und laufend, kostet null Euro. Vercels Free Tier schafft das. Keine Datenbank nötig. Keine monatliche Rechnung. Was ich oben beschrieben habe, ist die Basis, aber es ist erweiterbar auf alles, was du brauchst. Jede neue Datenquelle ist eine weitere Tool-Funktion. Jede neue Frage, die du Claude stellen willst, ist eine weitere Beschreibung zum Schreiben. Die Architektur ändert sich nicht.

Das vollständige Setup sind 6 Route-Files in einer Next.js-App. Tokens sind stateless JWTs, signiert mit jose. Der Authorize-Endpoint auto-approved, weil es ein persönlicher Server ist.

Was du herausfinden musst, bevor du anfängst:

Kannst du deine Datenquellen von einer Serverless-Funktion abfragen? Falls ja, wird jede zu einem Tool. Falls deine Daten hinter einem VPN leben oder eine persistente Verbindung erfordern, funktioniert Vercel Serverless nicht und du brauchst ein anderes Deployment-Modell.

Bist du komfortabel mit OAuth 2.1? Falls du noch nie einen OAuth-Server implementiert hast, plane einen ganzen Tag nur für die Auth-Schicht. Die MCP-Tools selbst sind trivial. Der OAuth-Tanz ist, wo Projekte sterben.

Das Setup dauert etwa eine Stunde, wenn du die exakten Constraints im Voraus kennst. Da ich bereits die 4-Stunden-Steuer bezahlt und die Fallstricke oben dokumentiert habe, könntest du Glück haben.

Der Morgen danach

Kleine Insel nördlich von Panama. Ein Typ am Strand verkaufte handwerklichen Kaffee für mehr als Starbucks verlangt. Ich kaufte einen, weil ich halb schlief und er überzeugend war. Ich bevorzuge Instantkaffee. Verurteilt mich nicht.

Ich setzte mich hin, öffnete Claude auf meinem Handy, tippte "ist etwas kaputt", bekam die Antwort in 4 Sekunden und ging zurück zum Meeresstarren. Discord hatte 38 ungelesene Benachrichtigungen. Ich öffnete es nicht.

Der MCP-Server gab mir keine neuen Daten. Alles, was er weiß, war bereits in meinen Discord-Kanälen, meinen Datenbanken, meinen Cron-Logs. Er ersetzte mich nur als Sortieralgorithmus. Und ehrlich gesagt war ich ein schrecklicher Sortieralgorithmus 🤷‍♂️

Falls deine Side-Projects sich schneller vermehren als deine Aufmerksamkeit, ist die Antwort wahrscheinlich nicht ein besseres Dashboard.

Falls du Sachen baust und gelegentlich darüber lesen willst, wie sie in Production kaputtgehen, folge mit.

---

* Ja, das Cover-Bild ist AI-generiert. Meine künstlerischen Fähigkeiten gipfeln bei Box-Diagrammen in Excalidraw.

---

Wenn deine SaaS-Apps mehr Monitoring-Chaos produzieren als Wert, dann ist dieser Einblick genau das, was du brauchst. Echte Produktions-Erfahrungen, keine Tutorials.

→ Newsletter kostenlos abonnieren