Übersicht
Entdecken
Effekte Beispiele Copyright-Schutz Neu
Einsetzen
Batch-Manager Clipboard-Manager Kommandozeile Eigene Programme KI-Agenten (MCP) Team-Server
Referenz
Erste Schritte API-Referenz Effekte-Referenz Mathe-Bibliothek
Download

Team-Server

Ein Rechner betreibt die Engine, das ganze Team nutzt sie. Der OpticScript-MCP-Server muss nicht auf jedem Arbeitsplatz laufen. Einmal gestartet, auf einem schnellen Rechner im Netz, bekommt der Agent jedes Arbeitsplatzes (Claude Code, Claude Desktop, ein eigener) dieselbe Engine, dieselbe Version und dieselben Schriften. Bilder laufen als ID, nicht als base64 durch das Modell.

Ein OpticScript-Server für das ganze Team: Arbeitsplätze sprechen MCP über HTTP mit mlcos-mcp; Bilder und Daten laufen per ID über den Speicher mlcartifact

Zwei Dienste auf dem Server

  • mlcos-mcp — der OpticScript-MCP-Server, diesmal über HTTP statt stdio. Er führt jedes Skript in einer Sandbox aus und verlangt ein Bearer-Token.
  • mlcartifact — ein kleiner Speicher für Dateien. Ein Client legt ein Bild hinein, bekommt eine ID zurück und gibt dem Modell nur diese ID. Ergebnisse landen ebenfalls dort.

Die Arbeitsplätze brauchen nur einen MCP-Client. Für Dateien, die auf dem Arbeitsplatz liegen, gibt es artifact-cli: eine einzelne Datei, die hoch- und herunterlädt.

Warum IDs und nicht base64

Ein Modell kann einem Werkzeug ein Bild als base64 übergeben. Bei einem Icon geht das. Bei einem Foto nicht: das Modell muss jedes Zeichen selbst in den Werkzeugaufruf schreiben, und das Ergebnis kommt auf demselben Weg zurück.

Was durch das Modell geht: 1.740.108 Zeichen base64 für ein 1,3-MB-PNG, gegen zwei Artefakt-IDs mit je 27 Zeichen

Mit dem Speicher dazwischen sieht das Modell mlcartifact://1c48-78174ca3 hinein und eine andere ID heraus. Die Pixel gehen nie durch den Kontext.

So sieht es aus

Ein echter Lauf von einem Windows-Arbeitsplatz (Claude Code in WSL). Aufgabe: ein lokales PNG mit 1,3 MB in ein WebP mit 640 px Breite umwandeln. Die Anweisung ist unten gekürzt, alles andere ist so abgelaufen:

Claude Code lädt foto.png mit artifact-cli hoch, liest in der API nach, prüft und startet das Skript auf dem Team-Server und lädt das WebP mit 34.628 Bytes herunter — 21 Sekunden

Neun Runden, 21 Sekunden, und das Skript lief beim ersten Versuch: das Modell hat es mit validate_script geprüft, bevor es run_script aufrief. run_script nennt Breite und Höhe jeder Ausgabe — ein zweiter Aufruf nur zum Nachmessen war nicht nötig.

Die Umwandlung selbst ist eine Zeile OpticScript. Hier mit dem Adler aus den Beispielbildern:

Umwandeln auf dem Server: PNG 1024×1024 mit 1.056.527 Bytes wird WebP 640×640 mit 26.760 Bytes — 97 Prozent kleiner

Daten von anderswo

Der Speicher ist nicht nur für Bilder da. Ein Datenbank-Werkzeug kann sein Abfrageergebnis als CSV ablegen, und ein Skript bekommt die ID als Parameter und macht ein Diagramm daraus:

//!PARAM: DATA:string=
//!OUTPUT: CHART
const rows = Engine.parseCSV("mlcartifact://" + DATA);
// … Diagramm zeichnen …
chart.save(CHART);        // → mlcartifact://<neue id> im Ergebnis

Jeder Lader liest aus dem Speicher — Engine.loadImage, parseCSV, parseJSON, readText, loadSVG. Engine.writeArtifact(name, bildOderText) legt ein Ergebnis ab und liefert dessen ID.

Einrichten

Ein Team-Server braucht eine Enterprise-Lizenz — die 30-Tage-Testphase schaltet ihn ebenfalls frei. Auf dem Server, als das Benutzerkonto, unter dem die Dienste laufen:

mlcos-license activate <SCHLÜSSEL> --name "Vorname Nachname"
mlcos-license status        # was freigeschaltet ist, bis wann

Ohne passende Lizenz startet mlcos-mcp im Netz nicht und nennt genau dieses Kommando. Dann:

# der Speicher — Token Pflicht, auch vom selben Rechner
ARTIFACT_GRPC_TOKEN=<speicher-token> artifact-server \
    -grpc-addr 0.0.0.0:9590 -addr 127.0.0.1:9591 -require-token-localhost

# die Engine
MLCOS_MCP_TOKEN=<geheim> MLCOS_ARTIFACT_TOKEN=<speicher-token> \
  mlcos-mcp -addr 0.0.0.0:8765 \
    -artifacts http://127.0.0.1:9590 -artifact-user team

Auf jedem Arbeitsplatz:

claude mcp add --scope user --transport http opticscript \
    http://<server>:8765/mcp --header "Authorization: Bearer <geheim>"

Für artifact-cli setzen Sie ARTIFACT_GRPC_ADDR=<server>:9590, ARTIFACT_GRPC_TOKEN=<speicher-token> und ARTIFACT_USER_ID=team. Dann nennt artifact-cli create foto.png die ID, und artifact-cli download <id> ergebnis.webp holt ein Ergebnis.

Unter macOS laufen beide gut als LaunchAgents, unter Linux als systemd-Units.

Sicher voreingestellt

Wer den Server erreicht, schickt Code. Deshalb:

  • Ein Token ist Pflicht, sobald der Server nicht nur auf Loopback lauscht; ohne startet er nicht. -addr :8765 ohne Host heißt 127.0.0.1.
  • Skripte laufen in einer Sandbox: keine Dateipfade — weder vom Aufrufer noch im Skript. Nur Ein-, Ausgaben und Artefakte. Engine.env() liefert nichts, Engine.fetch bleibt aus, Werkzeug-Plugins nur mit -allow-tools.
  • Grenzen: 5 Minuten je Lauf, 64 MB je Anfrage.
  • Der Speicher verlangt ein eigenes Token und weist Browser-Anfragen fremder Herkunft ab.

Grenzen

  • Ein Bereich für alle. Alle Nutzer eines Servers teilen sich den Artefakt-Bereich (-artifact-user). Eine Trennung pro Person braucht eine Anmeldung (OAuth); die hat diese Version nicht.
  • claude.ai im Browser kann ihn noch nicht nutzen. Dessen Connectors erreichen Server aus dem Internet und erwarten OAuth; ein Server im LAN mit festem Token ist beides nicht.
  • Große Dateien gehen über den Speicher. base64 taugt für Icons, nicht für Fotos.

Siehe auch