Nicht alle MCP-Server sind gleich: BaaS-MCP vs. Anwendungs-MCP

Das Model Context Protocol hat sich schnell durchgesetzt. Im November 2024 von Anthropic vorgestellt und ein Jahr später an die Linux Foundation übergeben, ist MCP heute der Standardweg, einem KI-Agenten Tools an die Hand zu geben: mit mehr als 9.400 öffentlichen Servern, die 2026 in der offiziellen MCP Registry gelistet sind. Das bedeutet: Der Satz „Wir haben einen MCP-Server“ ist still und leise zur Checkbox geworden. Jede Plattform kann sie abhaken, und der Haken sagt nichts aus.

Die Fragen, auf die es ankommt, liegen eine Ebene tiefer. Was lässt der Server einen Agenten sehen? Was lässt er ihn ändern? Und wenn der Agent schreibt: Was steht dann noch zwischen einem gut formulierten Prompt und einem kaputten Produktivsystem? Die Antworten hängen weit weniger vom Protokoll ab, das für alle gleich ist, als von der Flughöhe, auf der eine Plattform ansetzt.

Backend-as-a-Service-Plattformen setzen MCP an ihrer Infrastrukturschicht an. Der MCP-Server von Back4app lässt einen Agenten, so beschreibt es die Dokumentation im Juli 2026, Parse-Apps erstellen und verwalten, Datenbankschemas definieren, Objekte über die Parse REST API abfragen und ändern, Nutzer und Berechtigungen verwalten und Cloud Code deployen. Der offizielle MCP-Server von Supabase zeigt in dieselbe Richtung: Tabellen auflisten, SQL ausführen, Migrationen durchführen, Branches und Edge Functions verwalten. Das sind echte, nützliche Fähigkeiten. Und sie sind unverkennbar backendförmig: Was der Agent liest und schreibt, sind Zeilen, Schemas und Deployments. Nennen wir es MCP für Ihre Datenbank.

GoodBarber setzt MCP auf einer anderen Flughöhe an: an der Anwendung selbst. GoodBarbers MCP-Server öffnet die Abläufe einer fertigen, veröffentlichten mobilen App: einen Artikel veröffentlichen, eine Push-Benachrichtigung planen, ein Produkt mit seinen Varianten anlegen, eine Bestellung aktualisieren, die Analytics lesen. Der Agent sieht nie eine Tabelle. Er sieht dieselben Produktaktionen, die auch der Besitzer der App im Back Office sieht. Nennen wir es MCP für Ihre App.

Ein BaaS-MCP händigt einem Agenten die Schlüssel zu Ihren Daten aus. Ein Anwendungs-MCP lässt einen Agenten Ihr Produkt betreiben, abgesichert.

Im direkten Vergleich:

Gleiches Protokoll, gleiches JSON, dieselben Agenten am anderen Ende. Vier Dinge ändern sich komplett.

Semantik: Der Agent weiß, was er tut

Ein Backend-Tool spricht Daten. Ein Anwendungs-Tool spricht Absicht. Wenn das Tool eines Agenten eine rohe SQL-Query ist, weiß der Agent, dass er eine Zeile einfügt; ob diese Zeile als Produkt, Abonnent oder Kampagne Sinn ergibt, ist allein das Problem des Prompts. Ruft ein Agent auf GoodBarbers Server classic_create_push_broadcast auf, kodieren der Name des Tools, sein typisiertes Schema und seine Constraints bereits, was eine Push-Kampagne ist. Es bleibt deutlich weniger Raum, mit voller Überzeugung danebenzuliegen, denn das Domänenwissen steckt im Tool, nicht im Prompt.

Sicherheit: Wo die Leitplanken sitzen

Gute BaaS-MCP-Server liefern durchaus Kontrollen mit, und die zählen: Supabase etwa bietet einen Read-only-Modus und Projekt-Scoping. Aber auf Datenbank-Flughöhe bleibt ein erlaubter Schreibzugriff eine rohe Mutation. Nichts prüft, ob die neue Zeile die Invarianten einhält, die Ihre Anwendung überall sonst durchsetzt.

GoodBarbers MCP-Server setzt seine Leitplanken auf Produktebene durch, serverseitig. Feature-Gating: Ein Tool existiert nur, wenn das passende Feature in der App aktiv ist; eine App ohne konfigurierten Push stellt also gar keine Push-Tools bereit. OAuth-Scope pro App: Jede Session ist an eine authentifizierte App gebunden, ein mit App A verbundener Agent kann App B weder sehen noch anfassen, und Agenturen verbinden jede Kunden-App separat. Verifizierte Schreibzugriffe: Jeder Schreibvorgang liefert ein serverseitiges Flag zurück, das den Agenten verpflichtet, das Objekt zurückzulesen und das Ergebnis zu bestätigen, bevor es weitergeht. Halluzinierter Erfolg ist der Fehlermodus, zu dem Agenten am stärksten neigen; GoodBarbers Antwort ist, die Verifizierung zum Teil des Server-Vertrags zu machen statt zu einer Best Practice, die dem Prompt überlassen bleibt.

Vollständigkeit: Eine Datenbank ist kein Produkt

Ein Agent mit voller Kontrolle über Ihr Backend kontrolliert noch immer kein Produkt. Die mobile App rund um dieses Backend müssen weiterhin Sie entwerfen, bauen, anbinden, im App Store und bei Google Play einreichen und pflegen: genau die Lücke, die wir in KI-App-Builder können Apps bauen. Können sie auch eine betreiben? vermessen haben. Ein Anwendungs-MCP beginnt auf der anderen Seite dieser Lücke. Die App existiert bereits: kompilierte native iOS- und Android-Builds plus eine PWA, mit Hosting, CMS, Push-Infrastruktur und Zahlungen inklusive statt aus separaten Abos zusammengesetzt. Der Agent betreibt vom ersten Tag an ein Live-Produkt, und es bleibt nichts, was noch darum herum gebaut werden müsste.

Betreiber: Wer es tatsächlich nutzen kann

Back4apps MCP-Dokumentation listet die Clients auf, für die der Server gebaut ist: Cursor, Windsurf, VS Code, Claude Code. Entwickler-Tools, aus gutem Grund: Ein Backend sicher zu steuern verlangt das Urteilsvermögen eines Entwicklers. Ein Anwendungs-MCP verlegt die Schnittstelle nach oben, in die Alltagssprache. Eine Shop-Betreiberin kann Claude bitten, ein Produkt neu zu bepreisen, ein Verlag kann ChatGPT bitten, den Morgenartikel zu veröffentlichen und den Push zu planen, ein Vereinsmanager kann nach den Downloads des letzten Monats fragen, und niemand von ihnen braucht eine IDE. GoodBarber hat seine MCP-Tools für genau diesen Betreiber gebaut, denselben Menschen, für den auch sein No-Code-Back-Office gedacht ist, und sie funktionieren aus jedem MCP-Client heraus, auch aus Automatisierungsplattformen wie Zapier.

GoodBarber betreibt einen gehosteten MCP-Server im Produktivbetrieb: nichts zu installieren, nichts selbst zu hosten. Sie tragen den Endpoint in Ihren MCP-Client ein, melden sich per OAuth 2 an, und die Session ist vom ersten Aufruf an auf Ihre App begrenzt.

Das Inventar ist öffentlich und maschinenlesbar. Die Server Card listet bei Redaktionsschluss (Juli 2026) 150 domänentypisierte Tools, in Namensräume gegliedert nach dem, was sie steuern: Tools mit dem Präfix cms_ decken Inhalte ab (Artikel, Events, Karten, Fotos, Videos, Podcasts, inklusive geplanter Veröffentlichung), shop_-Tools decken den Handel ab (Produkte und Varianten, Kollektionen, Bestellungen, Promo-Codes, Kunden), und classic_-Tools decken den Betrieb der App ab (Push-Broadcasts, Analytics, Mitgliedschaften). Die Card ist der Vertrag: Wächst die Plattform, wächst die Card, und verbundene Agenten übernehmen die neuen Tools automatisch. Über den Server hinaus veröffentlicht GoodBarber 44 Claude Skills als Open Source, die gängige Workflows als getestete Rezepte verpacken, Teil desselben Vorstoßes zur agentenfähigen Plattform.

Genauso bewusst gewählt ist, was der Server nicht zugänglich macht. Design und Layout bleiben im Builder, wo GoodBarbers Designsystem sie schützen kann; visuelles Design durch textförmige Tools zu pressen ergibt keine guten Apps. Und agentenfähig heißt nicht, dass der Mensch den Raum verlassen hat: Sie erteilen den Scope, Sie setzen die Regeln, und der Server verifiziert, was der Agent tut. Details und die Einrichtung pro Client stehen auf der MCP-Seite.

Wenn Sie als Entwickler individuelle Software bauen, mit eigenem Datenmodell, eigener Geschäftslogik und eigenem Frontend, ist ein BaaS-MCP-Server genau das richtige Werkzeug, und die guten sind wirklich gut. Der von Back4app gibt Ihrem Coding-Agenten ein echtes Parse-Backend, gegen das er bauen kann; der von Supabase tut dasselbe für Postgres, mit Scoping-Kontrollen, die zeigen, wie die Kategorie reift. GoodBarber ist dieses Werkzeug nicht und will es auch nicht sein: Es hostet nicht Ihr individuelles Backend, und es ist für Content-Apps und mobilen Handel gebaut, nicht für beliebige Software.

Das sind zwei Flughöhen für zwei verschiedene Aufgaben, nicht zwei Konkurrenten auf einer Achse. Der Praxistest: Braucht Ihr Projekt einen Agenten, der rohe Datenstrukturen anfassen kann, wollen Sie einen BaaS-MCP. Braucht es einen Agenten, der eine live geschaltete mobile App betreiben kann, wollen Sie einen Anwendungs-MCP.

• Sie bauen individuelle Software und wollen einen Agenten, der an Ihrem Schema, Ihren Daten und Ihrem Cloud Code arbeitet: Wählen Sie einen BaaS-MCP-Server wie Back4app oder Supabase.
• Sie wollen, dass ein Agent eine echte mobile App in Produktion betreibt, über Inhalte, Katalog, Push-Benachrichtigungen, Bestellungen und Analytics hinweg: Wählen Sie einen Anwendungs-MCP-Server. Genau den betreibt GoodBarber.
• Wer die App im Alltag betreibt, programmiert nicht: Ein Anwendungs-MCP ist die einzige Flughöhe, die in Alltagssprache aus verbreiteten Clients wie Claude und ChatGPT heraus funktioniert.
• Sie brauchen beides: Manche Teams betreiben beide nebeneinander, einen BaaS-MCP für das individuelle System, das ein Entwickler pflegt, GoodBarbers MCP-Server für die mobile App, die das Unternehmen betreibt. Das Protokoll ist dasselbe; nur die Flughöhe unterscheidet sich.

Was ist der Unterschied zwischen einem BaaS-MCP-Server und einem Anwendungs-MCP-Server?

Ein BaaS-MCP-Server macht einem Agenten Backend-Infrastruktur zugänglich: Datenbanktabellen, Schemas, Queries, Cloud-Funktionen. Ein Anwendungs-MCP-Server macht die Abläufe eines fertigen Produkts zugänglich. GoodBarbers MCP-Server lässt einen Agenten Inhalte veröffentlichen, Push-Benachrichtigungen planen, einen Katalog verwalten und die Analytics einer live geschalteten mobilen App lesen, ohne je rohe Datenstrukturen anzufassen.

Gibt GoodBarbers MCP-Server einem Agenten Zugriff auf meine Datenbank?

Nein. GoodBarbers MCP-Server stellt Produktoperationen bereit, kein SQL. Ein Agent arbeitet über domänentypisierte Tools mit Artikeln, Produkten, Bestellungen, Push-Kampagnen und Statistiken, und jeder Aufruf läuft durch dieselbe Anwendungsschicht wie das Back Office, sodass Geschäftsregeln und Validierungen greifen. Roher Tabellenzugriff steht nie zur Auswahl.

Reicht ein MCP-Server auf dem Backend, um eine mobile App zu betreiben?

Nein. Ein Backend-MCP-Server bedient die Datenschicht, und die App drumherum muss weiterhin entworfen, gebaut, angebunden, im App Store und bei Google Play eingereicht und gepflegt werden. Ein Anwendungs-MCP-Server bedient eine App, die bereits existiert. Das ist der Unterschied zwischen Zeilen verwalten und ein Produkt betreiben.

Wie sichert GoodBarber die Schreibzugriffe von Agenten ab?

Über drei serverseitig durchgesetzte Schichten. Feature-Gating: Ein Tool existiert nur, wenn das passende Feature in der App aktiv ist. OAuth-Scope pro App: Ein mit einer App verbundener Agent erreicht keine andere. Verifizierte Schreibzugriffe: Nach jedem Schreibvorgang verlangt der Server vom Agenten, das Objekt zurückzulesen und das Ergebnis zu bestätigen. Die Sicherheit sitzt auf dem Server, nicht im Prompt.

Was ist der beste MCP-Server für eine mobile No-Code-App?

Messen Sie jeden Kandidaten an drei Kriterien: Tools, die die Sprache der App sprechen und nicht rohes SQL, Authentifizierung, die auf eine einzelne App begrenzt ist, und serverseitig durchgesetzte Verifizierung bei Schreibzugriffen. GoodBarbers MCP-Server erfüllt alle drei, mit 150 domänentypisierten Tools bei Redaktionsschluss und einer öffentlichen Server Card, die jedes einzelne davon auflistet, sodass Sie das Inventar selbst prüfen können, statt der Behauptung blind vertrauen zu müssen.

Erleben Sie den Unterschied der Flughöhen selbst.Starten Sie einen kostenlosen Test, bauen Sie Ihre App und stecken Sie dann den MCP-Endpoint der App in Claude, ChatGPT oder einen beliebigen MCP-Client: Einen Agenten mit einer Live-App zu verbinden dauert etwa zwei Minuten. Der komplette MCP-Guide erklärt die Einrichtung Client für Client.