Kommandozeile und MCP in App-Buildern: was sich ändert, wenn das Projekt den Browser verlässt

Hier kommen zwei Bausteine ins Spiel, die den Alltag deutlich verändern und die Plattformen heute unterscheiden: eine echte Kommandozeile und ein MCP-Server.

Was eine Kommandozeile löst und der Browser nicht

Drei konkrete Dinge.

Das ganze Projekt auf einmal sehen. Auf dem Bildschirm ist die Definition der App auf Tabs verteilt: Entitäten hier, Automatisierungen dort, die Konfiguration jeder Seite woanders. Auf der Festplatte ist sie ein Ordner. Sie öffnen fab.schema.json und lesen alle Entitäten und Felder auf einem Bildschirm, und die Suche Ihres Editors arbeitet darauf.

Starten, bevor veröffentlicht wird. Ein Befehl, der die App auf Ihrem Rechner hochfährt, auf derselben Vorlage, mit der die Plattform veröffentlicht, gibt die kurze Schleife, die fehlt, wenn jede Prüfung an einem Deploy hängt.

Automatisieren. Sobald die Definition eine Datei ist, kommt sie in die Versionsverwaltung, in die Prüfung per Pull Request und in eine CI-Strecke. Das interessiert nicht jeden, und wer Apps an Kunden liefert, den interessiert es sehr.

Was ein MCP-Server löst

MCP ist das Protokoll, über das ein Assistent ohne menschlichen Zwischenschritt mit einem Werkzeug spricht. In der Praxis ist es der Unterschied zwischen diesen beiden Dialogen:

„Fügen Sie hier das Schema Ihres Projekts ein, damit ich die Automatisierung vorschlagen kann.“

„Ich lese das Schema und schreibe die Automatisierung.“

Das Zweite passiert, wenn ein MCP-Server mit Ihrer Berechtigung läuft. Der Assistent ruft die Leseoperation auf, bekommt die echten Entitäten, die echten Felder und die echten IDs, und schreibt darauf auf.

Und genau das wird meist unterschätzt: ohne Schema zur Hand erfindet ein Modell. Eine falsche Modell-ID antwortet 404, ein nicht vorhandenes Feld antwortet 422, und der Assistent verbraucht drei Anläufe mit dem Korrigieren von Argumenten, obwohl das Problem war, vor dem Schreiben nichts gelesen zu haben.

Das Detail, das über die Sicherheit entscheidet: wie der Schlüssel entsteht

Fast jede Plattform mit Terminal-Zugang löst die Authentifizierung gleich: ein Bildschirm mit einem Knopf „Schlüssel erzeugen“, ein einmal angezeigter Wert und der Hinweis, ihn sicher aufzubewahren.

Das Problem ist nicht der Schlüssel, es ist sein Weg. Zwischen diesem Bildschirm und Ihrem Terminal läuft er über die Zwischenablage, fast immer über die Shell-Historie, manchmal über einen Chat-Kanal, wenn jemand den Rechner einer anderen Person einrichten muss, und häufig über eine Konfigurationsdatei, die in einem Repository landet.

Die Alternative ist der Geräte-Ablauf, dasselbe Muster, mit dem Sie schon eine Anwendung auf einem Fernseher autorisiert haben. Das Terminal fordert eine Autorisierung an, zeigt einen kurzen Code und öffnet eine Seite, auf der Sie prüfen, dass der Code übereinstimmt, und bestätigen. Der Schlüssel entsteht in dem Rechner, der ihn nutzen wird, und wird nirgends angezeigt.

Drei Folgen lohnen sich:

• Nichts zum Kopieren heißt nichts zum Auslaufen. Der Schlüssel existiert zu keinem Zeitpunkt in anzeigbarer Form.
• Die Berechtigung wird im Moment erfragt. Ein Rechner, der nur nachsehen muss, fragt nach Lesen, und seine Berechtigung sieht die Schreiboperationen gar nicht. Ein Assistent, der ein Werkzeug nicht sieht, versucht es nicht und verbrennt keine Runden damit, eine 403 als Argumentfehler zu lesen.
• Der Widerruf sitzt auf der richtigen Seite. Eine Abmeldung auf dem Rechner vergisst die Berechtigung dort. Ein Widerruf im Panel kippt diesen Rechner auf dem Server, und das brauchen Sie, wenn das Notebook weg ist.

Wo die Berechtigung danach liegt

Im Schlüsselbund des Betriebssystems, wenn es einen gibt. Wenn nicht, in einer Datei mit eingeschränkten Rechten, und es lohnt sich zu verlangen, dass das Werkzeug sagt, dass es dort gelandet ist. Ein Werkzeug, das den schlechteren Ort schweigend wählt, bringt dem Nutzer bei anzunehmen, es sei immer der bessere.

Was absichtlich außerhalb des Terminals bleibt

Zwei Dinge, und die Teilung ist gewollt:

Integrations-Zugangsdaten. Die Dateien, die beschreiben, was das Projekt verbunden hat, sollten nur lesbar sein: sie sagen, dass eine Integration existiert und welche Operationen aufzurufen sind, damit ein Assistent arbeiten kann, und nie das Geheimnis selbst. Verbinden und Erneuern passiert auf der Plattform.

Löschen. Eine Datei, die aus Ihrem Ordner verschwunden ist, sollte nicht aus der App verschwinden. Ihre lokale Kopie kann veraltet sein, die KI kann das Projekt inzwischen auf der Plattform bearbeitet haben, und dort wegen einer Abwesenheit hier zu löschen zerstört Arbeit. Richtig ist, den Unterschied zu melden und Ihnen die Entscheidung zu lassen.

Wie man das bei einer Plattform bewertet

Wenn Sie Werkzeuge vergleichen und diese Art Zugang zählt, trennen fünf Fragen schnell:

1. Wird der Schlüssel kopiert oder entsteht er über einen Geräte-Ablauf?
2. Kann man nur Lesen anfragen?
3. Gilt der Widerruf serverweit, oder vergisst er den Schlüssel nur auf dem Rechner?
4. Bietet der MCP-Server das Lesen des Schemas an oder nur Schreiboperationen?
5. Was macht der Veröffentlichungsbefehl mit einer verschwundenen Datei?

Die Antworten sagen mehr über die Reife des Werkzeugs als die Liste der Befehle.

Bei Fabapp

Die Kommandozeile macht login über den Geräte-Ablauf, legt die Berechtigung in den Schlüsselbund, akzeptiert --scopes "read" für einen Rechner, der nur nachsieht, und holt die Projektdefinition mit pull. dev startet die App lokal auf derselben Vorlage wie die Veröffentlichung, und deploy veröffentlicht. Der MCP-Server nutzt die vom Login abgelegte Berechtigung und respektiert deren Rechte: ein Lese-Token listet die Schreibwerkzeuge nicht.

Die verbundenen Rechner stehen unter Profil, bei Schlüssel und CLI, mit der Berechtigung jedes einzelnen und der letzten Nutzung. Der Widerruf wirkt sofort und gilt serverweit.