Einen Tool-Server bauen

Ein Tool-Server (ein MCP-Server) gibt deinen Agenten und Clients neue Tools, zum Beispiel, um ein Ticketsystem zu lesen oder in ein Wiki zu schreiben. In Labtagon AI OS betreibst du ihn nicht selbst: Du beschreibst ihn, dein Assistent schreibt ihn mit dir, und AI OS baut ihn, prüft ihn, betreibt ihn im Cluster und zeichnet jeden Aufruf auf. Nichts läuft, bevor du es einschaltest.

Einen anfangen

1. Öffne in Studio Mehr erstellen neben Neuer Agent und wähle Neuer Server.
2. Beschreib unter Was er tun soll die Tools in deinen eigenen Worten.
3. Optional: einen Namen, womit du Starten willst (Python, Node, oder Der eigene MCP-Server eines Dienstes, der keinen Code braucht) und Gestalten wie (optional) einen vorhandenen.
4. Klick auf Im Chat bauen.

Der Chat kann nur bauen, wenn in seinem Profil Authoring an ist. Ist es aus, sagt die Seite Dein Chat kann noch nicht bauen: in seinem Profil ist Authoring aus. und bietet Authoring einschalten an. Wer überhaupt bauen darf, entscheidet deine Organisation (die Berechtigung Build).

MCP-Server verbinden auf derselben Seite fügt stattdessen einen Server hinzu, der schon anderswo läuft.

Aus dem eigenen Client bauen

Claude Code, Codex oder ein anderer Client tut dasselbe mit den Tools studio__* von AI OS, sobald Authoring in seinem Profil an ist. Der Skill mcp-authoring (skills__get) sagt ihm, wie. Die Schritte, die er geht:

1. Erst nachsehen, ob es schon etwas Passendes gibt (studio__servers, studio__catalog).
2. Anlegen (studio__create_server, mit einer Vorlage: python, node oder saas). Ein Name hat 2 bis 16 Kleinbuchstaben, Ziffern und Bindestriche. Bis seine erste Version angenommen ist, steht der Server als noch nicht eingerichtet in der Liste, und sein Name ist reserviert.
3. Schreiben (studio__write_file, studio__apply_patch, studio__update_config), oder die Dateien als Archiv mitbringen (studio__import).
4. Bauen (studio__build). Der Build installiert die Abhängigkeiten im Cluster und führt die Prüfungen unten aus.
5. Vorschlagen (studio__propose). Daraus wird ein Änderungspaket, das du unter seiner Adresse in der Konsole prüfst.

Die Prüfungen eines Builds

Jeder Build führt diese Schritte aus (ADR 0052):

• Eine SBOM von allem, was installiert ist (syft).
• Bekannte Schwachstellen und Schadpakete unter den Abhängigkeiten (osv-scanner, mit den Schwachstellendaten, die AI OS vorhält).
• Eine Code-Prüfung (bandit für Python, eslint-plugin-security für Node).
• Die eigenen Tests des Servers (pytest oder node --test).

Während des Builds kann der Server nur aus der npm-Registry und von PyPI laden, außer deine Organisation erlaubt mehr.

Standardmäßig (checks.mode block):

• Ein Schadpaket oder ein fehlgeschlagener Test bedeutet: Die Version lässt sich nicht annehmen.
• Eine kritische Schwachstelle, Tests, die nicht fertig wurden, oder eine Prüfung, die nicht durchlief, braucht ein Häkchen der Person, die annimmt, dass sie es gesehen hat.
• Hinweise zum Code und Lizenzwarnungen blockieren nie.
• Agenten können dieses Häkchen nicht setzen; das tut eine Person.

Prüfen und annehmen

Ein Änderungspaket zeigt die geänderten Dateien, die Prüfungen unter Sicherheitsprüfung und Was es anders tun darf: neue Hosts, die es erreicht, neue Schlüssel oder Anmeldungen, die es nutzt. Das sind Rechte, die du freigibst. Annehmen veröffentlicht die Version.

• Eine Änderung an einem neuen Server oder Skill: Du nimmst sie an.
• Eine Änderung an einem vorhandenen: Sein Besitzer und seine Betreuer nehmen sie an.

Was ein Server erreichen darf

Ein Tool-Server erreicht das Internet nur über das Egress-Gateway von AI OS, und nur die Hosts, die seine Version nennt (spec.egress). Platzhalter wie * oder eine ganze öffentliche Endung werden abgelehnt. Für jeden Host kann er außerdem API-Regeln erklären: welche Methoden, Pfade und Operationen er schickt (ADR 0054). Alles andere dort wird abgelehnt, bevor ein Schlüssel eingesetzt wird. Ein neuer oder weiterer Host wartet auf eine Freigabe.

Schlüssel und Anmeldungen

Ein Server sieht deine Schlüssel nie in seinem Code: Er arbeitet mit Platzhaltern (spec.secrets), und das Egress-Gateway setzt den echten Wert erst auf dem Weg hinaus ein, nur zu den Hosts, zu denen der Schlüssel gehört. Für Dienste mit OAuth nennt der Server eine Verbindung; ihre Client-ID und ihr Secret tragen Administratoren ein. Jede Person meldet sich dann einmal an und wählt die Anmeldung in ihrem Profil.

Rollen an einem Server

Rolle	Darf
Besitzer	Alles, auch die Rolle Betreuer vergeben und den Server löschen.
Betreuer	Ändern, umbenennen und beschreiben, Änderungspakete annehmen.
Bearbeiter	Änderungen vorschlagen; der Besitzer oder ein Betreuer nimmt sie an.
Betrachter	Code und Aufrufe sehen; nichts schreiben.

Veröffentlichen

Unter Zugriff → Wer es nutzen kann wählst du, wer den Server findet: Nur du, Gruppen oder Organisation. Ihn weiter zu öffnen heißt Freigabe beantragen: Wer freigibt, legen die Richtlinien für Freigaben deiner Organisation fest; ohne eine geben ihre Administratoren frei.

Versionen und zurücknehmen

Standardmäßig nutzen alle die neueste angenommene Version (Einstellung Everyone uses the newest version). Unter Versionen siehst du den Stand jeder Version (Alle nutzen es, Vorgeschlagen, Angenommen, Abgelehnt, Zurückgezogen) und Version, die alle nutzen. Zurück auf … geht auf eine ältere zurück; sag, warum: Die Personen, die den Server nutzen, sehen den Grund. Aus einem Client macht studio__revert eine neue Version mit den alten Dateien.

Während er läuft

• Die Seite eines Servers hat die Abschnitte Details, Skills, Tools, Versionen, Verlauf, Zugriff, Analysen und Dateien.
• studio__logs, studio__calls und studio__usage zeigen seine Logs, seine fehlgeschlagenen Aufrufe und seine Nutzung.
• Ein Server, den niemand aufruft, schläft standardmäßig nach 15 Minuten ein und wacht beim nächsten Aufruf auf.
• Einen Server zu löschen (studio__delete_server) wird angehalten, bis du es freigibst.