Remote MCP-Server in Aktion: ein neuer Einstiegspunkt für SaaS-Produkte im KI-Zeitalter
Lerne, wie du einen Remote MCP-Server für dein SaaS-Produkt baust. Wir teilen unsere Erfahrungen mit MCP vs. Agent Skills, OAuth-Integration und der Gestaltung von MCP-Tools.
YijunDeveloper
Verschwenden Sie keine Wochen mit Benutzerauthentifizierung
Bringen Sie sichere Apps schneller mit Logto auf den Markt. Integrieren Sie Benutzerauthentifizierung in Minuten und konzentrieren Sie sich auf Ihr Kernprodukt.
SaaS-Produkte haben ein langwieriges Problem: Der Time-to-Value ist zu langsam. Viele Nutzer springen ab, bevor sie den "Aha"-Moment erreichen.
Wir haben das Onboarding von Logto schon oft überarbeitet. Es hat geholfen, aber der Engpass verschwand nicht. Am Ende liest du doch Dokumentationen, überfliegst Tutorials, installierst SDKs, verbindest Konfigurationen, schreibst Code und musst dann noch die letzten 10 % debuggen, bevor etwas funktioniert.
Also haben wir einen anderen Ansatz versucht: einen Remote-MCP-Server als Logtos IDE-natives Control Plane. Statt sich durch ein Admin-Interface zu klicken, konfigurierst du Logto und generierst Integrationscode im Gespräch – direkt dort, wo du die App entwickelst.
Ein Prompt kann dich von Null zu einer funktionierenden Integration bringen. Der Agent generiert nicht nur Code, sondern erstellt und konfiguriert auch die Logto-Anwendung in deinem Tenant. Alles direkt aus deiner IDE heraus. (Probiere den Logto MCP Server aus)
In diesem Artikel teile ich unsere Erfahrungen und Überlegungen beim Aufbau des Logto MCP Servers, darunter:
MCP vs. Agent Skills: warum wir MCP gewählt haben
Probleme, denen wir beim Versand eines MCP-Servers begegnet sind – und wie wir sie gelöst haben
Wie wir MCP-Tools gestalten – und wie du deine gestalten solltest
Unsere Erwartungen an die Zukunft von MCP
MCP vs. Agent Skills: warum wir MCP gewählt haben#
Bevor wir entschieden, wie KI auf Logto zugreifen sollte, haben wir zwei Optionen evaluiert: MCP-Server und Agent Skills.
MCP-Server gibt es in zwei Formen: lokal und remote.
Ein lokaler MCP-Server läuft auf dem Rechner des Nutzers. Er erfordert eine Service-Installation, Umgebungseinrichtung, Zugangsdaten oder spezielle Anmeldeflows. In Nutzung und Auslieferung ist das sehr ähnlich zu Skills.
Ein Remote-MCP-Server läuft serverseitig. Nutzer verbinden sich per URL und authentifizieren sich via OAuth. Das Modell ähnelt der Erweiterung von SaaS-Services.
Strukturell ist ein Agent Skill eine Kombination aus "Business-Logik + zugrunde liegende Fähigkeiten". Diese Fähigkeiten können Tools, CLIs oder API-Calls sein. MCP-Tools tragen diese Ebene auf einheitliche Weise.
Die Schlüsselfrage ist also weniger, wie Fähigkeiten implementiert sind, sondern wie sie an Nutzer ausgeliefert werden.
Agent Skills liefern: eine volle lokale Toolchain (Skill-Paket + lokale Laufzeit + API-Keys oder Plattform-Credentials + CLI-Tools + Installation, Konfiguration, Upgrade und Wartung).
Im Grunde gibst du Nutzern die Fähigkeit, dies selbst auszuführen.
Remote-MCP-Server liefern: einen Remote-Service-Eintritt (URL + OAuth-Login).
Im Grunde stellst du die Fähigkeit als Service bereit.
Im Folgenden vergleichen wir sie im Hinblick auf Nutzererfahrung, Reichweite des Ökosystems sowie Auslieferungs- und Wartungskosten.
Agent Skills hängen meistens von Plattform-APIs oder CLIs ab. Nutzer müssen zuerst API-Keys erstellen oder CLIs installieren und sich einloggen. Diese Schritte sind nicht kompliziert, heben aber die Einstiegshürde.
MCP-Server unterstützen OAuth. Nutzer loggen sich mit ihrem SaaS-Account ein. Die Erfahrung ist wie „Mit Google anmelden“.
Für Nutzer ist ein MCP-Server ganz einfach: URL eingeben, einloggen, verbinden. Genau diese Erfahrung möchten wir bieten.
Auf der MCP-Website gibt es bereits 104 KI-Apps, die MCP unterstützen, darunter Tools wie VS Code, Cursor und Windsurf.
Agent Skills sind immer noch plattformspezifisch. Selbst wenn viele Plattformen sie unterstützen, können Nutzer einen MCP-Server sofort verwenden – einen Skill kann nur wer auf dieser Plattform nutzen.
MCP wird außerdem von der Agentic AI Foundation (AAIF) unterstützt. Es ist ein Standard auf Protokollebene. Das Ökosystem wächst weiter. Für uns lohnt sich die langfristige Investition in MCP.
Agent Skills hängen von Plattform-APIs oder CLIs ab, was schnell zu Problemen führt:
Was, wenn sich das API ändert?
Was, wenn die CLI inkompatibel wird?
Wie wird der Skill aktualisiert und verteilt?
Man muss auch CLIs verteilen, verstreute Zugangsdaten verwalten, für mehrere Plattformen anpassen und Nutzer zum Upgraden anleiten. Das ROI ist niedrig.
MCP-Server sind viel einfacher. Nutzer verbinden sich mit einer URL. Diese verweist immer auf die neueste Version. Wenn wir den MCP-Server updaten, bekommen Nutzer beim nächsten Verbinden das Update automatisch – kein Upgrade nötig. Ändern sich APIs, passen wir sie nur im MCP-Server an.
Die meisten SaaS-Produkte besitzen bereits eine starke Infrastruktur: solide APIs und ausgereifte Auth-Systeme. Ein MCP-Server passt natürlich als "KI-Interface" zur API – so wie ein Admin-Interface eine weitere Schnittstelle darüber bildet.
Für Logto ist der MCP-Server die passende Architektur und spielt unsere Stärken aus.
Außerdem laufen alle Anfragen zentral über einen Einstiegspunkt. Logs und Audits werden leichter. Die Berechtigungen sind klar: Die KI kann nur, was der Nutzer autorisiert. Dieses Modell ist strukturell sauberer für Enterprise- und Compliance-Szenarien.
Probleme, denen wir beim Versand eines MCP-Servers begegnet sind – und wie wir sie gelöst haben#
MCP ist nicht perfekt. Die meisten Probleme liegen am Reifegrad des Ökosystems – das wird sich mit der Zeit verbessern. Bis dahin nutzen wir Workarounds für die realen Anforderungen.
Bei Agent Skills sind Business-Logik und Kontext im Paket. Das LLM weiß, wie es benutzt werden kann. MCP stellt nur Tools bereit. Nach Verbindung weiß das LLM nicht:
Die Nutzungsszenarien
Die Aufrufreihenfolge
Die geschäftlichen Einschränkungen
MCP kennt den Begriff Instructions, aber nicht jeder Client unterstützt sie. Zudem wird damit zum Verbindungszeitpunkt der gesamte Inhalt in den Kontext geschoben – das kostet Tokens.
Eine Idee ist, die Anleitungen in Tool-Beschreibungen unterzubringen. Das führt jedoch zu zwei Problemen:
Die Beschreibungen werden komplex. Multi-Tool-Workflows ergeben verschachtelte Logik und sind schwer wartbar.
Mit wachsender Tool-Anzahl fressen die Beschreibungen große Teile des Kontextfensters.
Unser Workaround: Biete ein getInstructions-Tool
Die Idee ist schlicht: Wenn Instructions nicht gut unterstützt werden, machen wir daraus Tools.
Das LLM kann getInstructions nach Bedarf aufrufen.
Für Aufgabe A ruft es getTaskAInstructions auf. Der MCP-Server liefert ein Prompt, das erklärt, wie Aufgabe A erledigt wird und wie andere Tools kombiniert werden können.
Komplexe Business-Logik bleibt hinter den Instruction-Tools. Die übrigen Tools sind einfach. Tool-Beschreibungen konzentrieren sich auf ihre Funktion.
Das ähnelt Agent Skills: Prompts werden nach Bedarf geladen. Es ist auch effizienter als globale Instructions, weil nicht alles in den Kontext geworfen wird.
Für viele SaaS-Produkte müssen manche Geheimnisse niemals offengelegt werden (z. B. Client-Secrets, API-Keys oder Webhook-Signing-Keys). Wenn diese kompromittiert werden, können andere dich imitieren oder direkt auf Ressourcen zugreifen.
Das Risiko bei LLMs ist, dass Chats kein sicherer Kanal sind. Konversationen können geloggt, kopiert, weitergeleitet oder in Debug-Protokollen landen. Man darf nicht annehmen, „nur Modell und ich sehen das“. Ein LLM ein langlebiges Secret geben oder dieses darin ausgeben zu lassen, wäre sehr riskant.
Das ist auch bei klassischen Web-App-Integrationen üblich: Entwickler brauchen oft ein Secret, setzen es in Server-Umgebungsvariablen oder Konfigurationsdateien und schließen so Schritte wie SDK-Initialisierung ab.
Um das Onboarding einfach zu halten, aber die Secrets sicher zu halten, machen wir Folgendes:
Temporäre Secrets während der Integration nutzen
Während der Chat-basierten Einrichtung gibt der MCP-Server nur kurzlebige temporäre Secrets aus (z. B. 1 Stunde gültig). Sie reichen, um die Integration zu testen, und sind meist abgelaufen, bevor du live gehst. Vor dem Go-live erstellen die Entwickler langlebige Secrets außerhalb des Chats und ersetzen sie.
Die Sicherheitsgrenze explizit machen
Wir warnen klar: Erstelle, kopiere oder speichere keine produktiven Secrets im Chat. Wir erinnern Entwickler auch daran, dass sogar Umgebungsvariablen oder Konfigurationsdateien durchsickern könnten, falls ein Agent/LLM sie indirekt ausliest. Produktiv-Secrets nur in Umgebungen speichern, in denen keine KI-Integration läuft.
Nie produktive Secrets im Chat, leite zur Konsole an
Langlebige Secrets werden nicht im Chat erzeugt oder verteilt, sondern in der Konsolen-Credentials-Seite angelegt und verwaltet. Im Chat gibt es nur einen direkten Link dorthin, damit Nutzer die Produktionseinrichtung abschließen können.
Logto hat eine vollständige Management-API. Unsere Ursprungsidee: Jeden API-Endpoint als MCP-Tool verfügbar machen.
Das scheiterte schnell.
Erstens: Kontext-Explosion. Logto hat viele APIs. 1:1-Mapping sprengt das Kontextfenster, jede Tool-Beschreibung kostet Tokens.
Zweitens: Sinnverlust. APIs sind atomare Bausteine für Entwickler. Die Nutzer des Logto MCP Servers bauen aber kein System – sie wollen Aufgaben fertigstellen. Sie ist die Zahl der APIs egal.
Beispiel: Logto hat ein sign-in-experience-API für Branding, An- und Abmeldemethoden, sowie Sicherheitsrichtlinien.
Anfangs überlegten wir, wie wir alle Parameter für das LLM zugänglich machen. Wie ihm beibringen, Calls zu kombinieren?
Aber das ist der falsche Denkansatz. Nutzer rufen keine APIs auf, sie wollen Branding ändern oder Login-Methoden konfigurieren.
Die Tools sollten also updateBranding, updateSignInMethod, updateSignUpMethod heißen. Der MCP-Server übernimmt die API-Komposition im Hintergrund.
Der Logto MCP Server sollte wie ein Produkt behandelt werden, nicht als API-Wrapper. Er ist "eine weitere Admin-Konsole".
Wenn deine Nutzer deinen Service direkt nutzen (wie eine Konsole), sollten deine Tools geschäftsorientiert sein.
Wenn du Basiskomponenten bereitstellst, auf die andere aufbauen, sollten deine Tools atomar und simpel bleiben. Beispiel: ein Filesystem-MCP-Server mit read_file, write_file, sodass Code-Agents kombinieren können.
Weitere Prinzipien:
Halte Logik und Tool-Beschreibungen einfach, um Kontext zu sparen.
Für komplexe Abläufe nutze getInstructions-Tools, um Anleitungen on-Demand zu laden, und halte auch deren Beschreibung simpel.
Manchmal müssen MCP-Server nicht nur Tools bereitstellen, sondern auch Anleitungen, wie sie – wie in Agent Skills – zu Aufgaben kombiniert werden.
Das ist bei SaaS üblich. Beispiel: GitHub MCP Server, Logto MCP Server oder Analytics-Plattformen. Die Nutzer wollen Workflows – keine einzelnen Aufrufe.
Das getInstructions-Tool ist ein Workaround. Protokollebene Unterstützung wäre wünschenswert.
Clients verbinden sich oft zu vielen MCP-Servern, aber nicht jede Sitzung braucht sie alle. Aktivieren/Deaktivieren pro Session könnte Kontextverschwendung einschränken.
Das sind unsere Erfahrungen mit dem Aufbau eines Remote-MCP-Servers.
Wenn du in diese Richtung gehen willst, probiere den Logto MCP Server aus oder tritt unserem Discord bei, um mit der Community über echte Implementierungserfahrungen zu sprechen.
Wir werden auch Architektur-Details und OAuth-Flows in kommenden Artikeln teilen.
