Mit einem Agenten deployen

Ein Agent, der mit dem MCP-Server verbunden ist, kann für dich deployen: den Code auf deinem Staging-Server holen, dein Deploy-Skript ausführen, prüfen, ob der Dienst läuft. Er tut das auf den SSH-Verbindungen, die in deinem Vault gespeichert sind, und nichts läuft, bevor du Approve drückst. Der Agent sieht nie ein Passwort, einen Schlüssel oder auch nur die Adresse des Servers, nur den Namen, den du der Verbindung gegeben hast.

Die vier Schranken

Alle vier müssen offen sein, bevor auch nur ein Befehl laufen kann:

Außerdem muss dein Vault entsperrt sein, denn dort liegt das Login.

Allow all öffnet Schranke 1, aber nie Schranke 2, und für Server gibt es kein „allow all": Eine Verbindung, die du nicht angehakt hast, existiert für den MCP-Server nicht. Ist Schranke 1 oder 2 zu, sieht der Agent die Tools, die Befehle ausführen oder Dateien schreiben, gar nicht erst.

Die Server auswählen

1. Speicher den Server im Vault als SFTP connection mit dem Protokoll SFTP. Nur deine persönlichen Einträge lassen sich nutzen, keine aus dem Team.
2. Hak ihn unter Settings → MCP server → Terminal — which servers an. Jede Zeile zeigt den Namen und user@host:port.
3. Um einen zurückzunehmen, entfern das Häkchen. Ein Eintrag, den du aus dem Vault gelöscht hast, zeigt „No longer in your Vault." mit Remove.

Solange der Vault gesperrt ist, kannst du die Häkchen nicht ändern, aber die gesetzten gelten weiter.

Was der Agent sieht

terminal_list_connections liefert genau die angehakten Server, mit Namen, und sonst nichts.

Einen Befehl freigeben

1. Der Agent schlägt einen Befehl vor. Apiboo kommt nach vorn, das System zeigt „A command is waiting for your approval.", und die Karte Run this command on your server? öffnet sich.
2. Lies das Ziel (Name und user@host:port) und den Command. Er steht vollständig da, nie gekürzt.

3. Entscheide:

   • Approve führt ihn aus. Der Button ist beim Öffnen der Karte kurz gesperrt, damit ein versehentlicher Tastendruck nichts freigibt.
   • Refuse, Esc oder der Schließen-Button lehnt ihn ab. Refuse hat den Fokus, also lehnt auch Enter ab.
   • Ohne Antwort innerhalb von 120 Sekunden („Refused automatically in") wird er abgelehnt.

Es wartet immer nur ein Befehl. Eine Ablehnung ist endgültig: Der Agent soll ihn nicht erneut oder abgewandelt versuchen, sondern dich fragen.

Run it in a terminal tab I can watch (standardmäßig an) führt den Befehl im Terminal-Tab von Apiboo für diesen Server aus, vor deinen Augen. Schalt es aus, um ihn unsichtbar laufen zu lassen. Die Karte merkt sich deine letzte Wahl.

Was nach Approve passiert

• Der Befehl läuft per SSH auf dem Server, mit einem Timeout von 30 Sekunden, wenn der Agent nicht mehr verlangt, höchstens 300 Sekunden.
• Der Agent holt das Ergebnis ab: den Exit-Code und die Ausgabe, 16 KB pro Stream. Bei längerer Ausgabe bleiben Anfang und Ende, und die Mitte wird als ausgelassen markiert; die volle Ausgabe steht im Tab von Apiboo. In einem beobachteten Tab kommen Fehler zusammen mit der normalen Ausgabe.
• Alles, was wie ein Passwort oder Schlüssel aussieht, wird aus der Ausgabe entfernt, bevor sie zum Agenten geht. Das ist Best Effort; gib also nur Befehle frei, deren Ausgabe du weitergeben willst.
• Das Ergebnis lässt sich 10 Minuten nach Ende des Befehls abholen.

Eine Datei senden

Der Agent kann mit terminal_put_file auch eine Datei auf einen angehakten Server schreiben, etwa eine Konfigurationsdatei oder ein kleines Skript:

• bis 256 KB, Text oder binär;
• an einen absoluten Pfad, dessen Ordner schon existieren muss;
• per SFTP, und was an dem Pfad liegt, wird ersetzt.

Er fragt nach deiner Freigabe wie bei einem Befehl. Die Karte zeigt File to write, den Pfad, die Größe und den sha256 des Inhalts, und die ersten 20 Zeilen („The first lines only. Approving writes all … bytes to that path and replaces whatever is there now."). Eine Datei zu schreiben braucht dieselben vier Schranken.

Für Größeres, etwa ein Build-Artefakt, schlägt der Agent stattdessen einen Befehl vor, der es auf dem Server holt: git pull, curl oder dein Deploy-Skript.

Ohne Nachfrage weitermachen

Für eine Reihe von Befehlen auf einem Server hakst du vor dem Freigeben Keep going on … without asking me auf der Karte an:

• es gilt nur für diesen Server und nur für Befehle, nie für Dateien;
• es endet nach 25 Befehlen oder 30 Minuten, je nachdem, was zuerst eintritt;
• jeder durchgelassene Befehl läuft im Terminal-Tab, den du beobachten kannst, und steht im Log;
• es gilt nur für diesen Lauf von Apiboo: Apiboo beenden, den MCP-Server stoppen oder dich abmelden beendet es. Solange der Vault gesperrt ist, läuft gar nichts.

Solange es an ist, zeigt eine Pille Running without asking on … mit den verbleibenden Befehlen und Minuten. Stop beendet es für diesen Server; laufen mehrere Server ohne Nachfrage, beendet Stop all alle. Die Checkbox ist auf jeder Karte anfangs leer.

Das Befehls-Log

Unter den angehakten Servern listet Settings jeden Befehl, den MCP auf deinen Servern vorgeschlagen hat, den neuesten zuerst, freigegeben, abgelehnt oder abgelaufen:

Jeder Eintrag hat den vollständigen Befehl, den Server, wo er lief (in a visible terminal tab, in the background oder file write (SFTP)), den Exit-Code und die Dauer. Die Ausgabe wird nie aufgezeichnet. Das Log bleibt auf diesem Gerät, übersteht einen Neustart und wird beim Abmelden gelöscht.

Recent requests (siehe Recent requests) zeigt getrennt davon die letzten 20 MCP-Aufrufe jeder Art.

Lokale Terminals

Über MCP lassen sich nur gespeicherte SSH-Verbindungen steuern. Deine lokalen Terminal-Panes (PowerShell, bash, WSL und so weiter) nicht: Dafür gibt es kein Tool. Auch der eigene Terminal-Tab des Agenten nimmt keine Eingaben an; tipp in deinem eigenen Tab.

Beispiel: die Bookshop API auf Staging deployen

Einmalig eingerichtet: die vier Schranken oben, mit angehaktem „Bookshop staging", und Documents — read sowie Boards — read und write an.

1. Du fragst: „Deploy the Bookshop API to staging."
2. Der Agent liest dein Dokument „Deploy" im Projekt Bookshop, um zu erfahren, wie du deployst, und listet die Verbindungen, die er nutzen darf: „Bookshop staging".
3. Er schlägt cd /srv/bookshop-api && git pull --ff-only && ./deploy.sh vor. Die Karte zeigt den Befehl und deploy@staging.bookshop.test:22. Du liest ihn und klickst auf Approve, mit Run it in a terminal tab I can watch an.
4. Der Terminal-Tab für Bookshop staging öffnet sich, und du siehst dem Deploy zu. Der Agent holt Exit-Code und Ausgabe ab.
5. Er schlägt einen Health-Check vor, zum Beispiel curl -fsS http://localhost:8080/health, und du gibst auch den frei. Scheitert danach ein Request aus deiner Collection, hilft request_diagnose ihm, den gespeicherten Request zu prüfen (siehe Beispiele).
6. Er kommentiert den Release-Task auf dem Bookshop-Board: deployt, mit Commit und Ergebnis des Health-Checks.

Scheitert Schritt 3, sieht der Agent den Exit-Code und das Ende der Ausgabe, sagt dir, was schiefging, und schlägt den nächsten Befehl vor. Auch den gibst du frei.