LXI SDKs & Codebeispiele | Python, JavaScript, OpenAPI

Offizielles Python SDK

Python 3.10+

from lxi_sdk import LXI
client = LXI()  # liest LXI_API_TOKEN
print(client.domains())
print(client.domain_check("example.de"))

Offizielles JavaScript SDK

Node.js 18+ und moderne Runtimes

import { LXI } from "./index.js";
const client = new LXI({ token: process.env.LXI_API_TOKEN });
console.log(await client.usage());

Typisierte Clients

OpenAPI Generator

openapi-generator-cli generate \
  -i https://lxi.be/openapi.json \
  -g typescript-fetch -o ./lxi-client

Die Spezifikation definiert Operation-IDs, Eingabeschemas, Pfadparameter, Security Scheme und strukturierte Fehler. Generierte Clients sollten das Token über ihren Bearer-Auth-Hook erhalten.

Tool Discovery

Für KI-Agenten auffindbar und begrenzbar

llms.txt, llms-full.txt und OpenAPI beschreiben die öffentlichen Fähigkeiten. Gib Agenten eigene Tokens mit minimalen Scopes und verlange für Käufe oder Löschungen weiterhin eine explizite Bestätigung in deinem Agent-Workflow.

Externe Werkzeuge

Eigene Dienste mit dem Maker verbinden

Der Maker kann als MCP-Client freigegebene Werkzeuge eines verbundenen Dienstes nutzen. Öffne im Projekt unter Quellen den Bereich MCP, trage die HTTPS-Adresse des Dienstes ein und speichere bei Bedarf dessen Bearer-Token. Aktualisiere anschließend die Werkzeugliste.

Verwende für jede Verbindung ein eigenes, möglichst eng berechtigtes Token. Zugangsdaten gehören nicht in die URL, in Chat-Nachrichten oder in Projektdateien. Die Verbindung gilt nur für dieses Projekt und dessen Eigentümer.

Dies ist eine ausgehende Integration: Die Verbindung macht den Maker nicht selbst zu einem MCP-Server. Die Einrichtung erfolgt derzeit im Maker-Browser, nicht über einen zusätzlichen CLI-Befehl.

Nachvollziehbare Ausführung

Mit Unterbrechungen und unklaren Ergebnissen umgehen

Aufrufe bleiben an den Nutzerauftrag und den geprüften Projektstand gebunden. Ein Retry wiederholt eine bereits abgeschlossene oder möglicherweise ausgeführte Aktion nicht automatisch. Beim erneuten Übernehmen eines noch nicht versandten Aufrufs kann eine neue Einzelbestätigung nötig sein.

Steht der Status auf „Ergebnis ungeklärt“, prüfe zuerst den verbundenen Dienst. Dokumentiere danach im Werkzeugdialog, ob die Aktion ausgeführt wurde. Diese Angabe wird als deine Rückmeldung gespeichert, nicht als unabhängig verifiziertes Ergebnis. Auch die Angabe „nicht ausgeführt“ startet die ursprüngliche Aktion nicht erneut.

Stoppen verhindert keine bereits erfolgte externe Änderung und macht sie nicht rückgängig. Bei erschöpften Credits wird kein weiterer Agentenaufruf gestartet. Die erfolgreiche Werkzeugphase ersetzt außerdem nicht die anschließende Prüfung der erzeugten Anwendung.

Integrationsprofil

Was der MCP-Client unterstützt

Unterstützt werden öffentlich erreichbare HTTPS-Endpunkte auf Port 443, Werkzeuglisten und Werkzeugaufrufe über Streamable HTTP. Verfügbar sind das zustandslose Protokollprofil 2026-07-28 und das ausdrücklich auswählbare ältere Profil 2025-11-25. Antworten können JSON oder ein begrenzter SSE-Datenstrom sein.

Werkzeugeingaben werden gegen ihr JSON-Schema geprüft. Lokale Schema-Verweise sind möglich; externe Schema-Dateien werden nicht nachgeladen. Weiterleitungen, lokale Netzadressen und Zugangsdaten in URLs sind nicht zulässig.

Bis zu 16 Verbindungen pro Projekt und 64 Werkzeuge je Verbindung.
Bis zu 128 KB pro Anfrage und 1 MB pro Antwort; Aufrufe haben ein Zeitbudget von 120 Sekunden.
Eine Werkzeugphase hat standardmäßig 32 Schritte. Pro Nutzerauftrag sind höchstens 32 gespeicherte Aktionen vorgesehen, auch über Retries hinweg.
Große Werkzeugbeschreibungen und Ergebnisse werden seitenweise bereitgestellt.

Nicht unterstützt werden OAuth-Anmeldung am MCP-Dienst, stdio-Prozesse, Resources, Prompts sowie interaktive Rückfragen eines MCP-Servers. Ein Dienst, der zusätzliche Eingaben verlangt, wird daher nicht als erfolgreich abgeschlossen gewertet.

Selbstständig erzeugte Infinity-Zyklen führen keine externen MCP-Aktionen aus. Konkrete Nutzeraufträge in der Warteschlange verwenden die normalen Projektfreigaben.

Dein Entwicklungsablauf

Maker-Projekte mit GitHub verbinden

Die interne Versionshistorie funktioniert ohne Git. Wenn du mit einem Repository arbeiten möchtest, öffne die Projekteinstellungen und verbinde ein initialisiertes GitHub-Repository mit einem vorhandenen Branch. Verwende ein eigenes, auf dieses Repository beschränktes Token.

Für Exporte benötigt das Token Lese- und Schreibrechte auf Repository-Inhalte, für Pull Requests zusätzlich die entsprechenden Pull-Request-Rechte. Änderungen an GitHub-Workflow-Dateien können weitere Berechtigungen benötigen. Regeln und geschützte Branches deines Repositories bleiben wirksam.

Importiere externe Änderungen zuerst in den Maker. Bei Dateikonflikten wählst du die gewünschte Version; die Übernahme erfolgt erst nach der Prüfung. Git-Zugangsdaten gehören ausschließlich in das Token-Feld, nicht in den Chat oder in Projektdateien.

Änderungen getrennt entwickeln

Einen geprüften Stand auf einen neuen Branch übertragen

Öffne „Branches & Pull Requests“, wähle einen neuen Branchnamen und bereite den Vorgang vor. Prüfe Repository, Quell-Commit und Dateiversionen, bevor du die Ausführung bestätigst. Der neue Branch enthält den fertigen Commit; vorhandene Branches werden dabei nicht ersetzt.

Mit „Branch übernehmen“ kannst du den erstellten Branch anschließend ausdrücklich zum Ziel für zukünftige Importe und Exporte machen. Diese Auswahl ändert weder die Projektdateien noch deine interne Versionshistorie.

Review im Team

Einen Pull Request als Entwurf erstellen

Übertrage den aktuellen geprüften Stand zuerst auf den verbundenen Branch. Bereite anschließend einen Pull Request zu deinem Zielbranch vor, ergänze Titel und Beschreibung und bestätige den angezeigten Vorgang. Der Maker gleicht die exportierten Dateien mit dem freigegebenen Stand ab.

Der Pull Request wird als Entwurf angelegt. Review, GitHub-CI und Merge bleiben separate Schritte. Ein angelegter Pull Request bedeutet nicht, dass die Prüfungen deines Repositories bestanden sind. Eine Kennung in der Beschreibung hilft, den ursprünglichen Vorgang nach einem Verbindungsabbruch wiederzufinden.

Nachvollziehbare Übergaben

Unklare Ergebnisse prüfen, statt doppelt zu senden

Gespeicherte Vorgänge bleiben nach dem Schließen des Browsers sichtbar. Bei „Ergebnis noch unklar“ wählst du „Status bei GitHub prüfen“. Der Maker sucht nach der ursprünglichen Aktion, ohne sie erneut auszuführen. Wurde das Ziel inzwischen verändert oder gelöscht, kann eine zusätzliche Prüfung direkt bei GitHub nötig sein.

Eine noch nicht versandte Freigabe kannst du zurückziehen. Bereits erfolgte Änderungen bei GitHub werden dadurch nicht rückgängig gemacht. Ein zwischenzeitlich geänderter Projektstand oder eine neue Verbindung kann eine neue Freigabe erfordern.

Git-Exporte sind auf 10 MiB pro Datei und 50 MiB insgesamt begrenzt. Das Verzeichnis .lxi/ ist für Exportmetadaten reserviert.

Terminal und Automationen

Branches und Pull Requests per CLI

Ab CLI 1.1 verwendest du dieselben gespeicherten Git-Vorgänge wie im Maker. Verbinde das Repository zunächst in den Projekteinstellungen. Dein LXI-Token benötigt maker und zusätzlich maker_git. Die zusätzliche Berechtigung wird bestehenden Tokens nicht automatisch zugewiesen.

lxi auth login --scope maker --scope maker_git
lxi --json maker git prepare-branch PROJECT_UUID --target feature/task-menu --operation-key task-menu-1
lxi --json maker git status PROJECT_UUID OPERATION_ID
# Erst Repository, Dateistand, Ziel und request_hash prüfen:
lxi maker git execute PROJECT_UUID OPERATION_ID --request-hash REVIEWED_HASH --confirm
# Separat als verbundenen Branch übernehmen:
lxi maker git adopt PROJECT_UUID OPERATION_ID --request-hash REVIEWED_HASH --confirm
lxi maker git prepare-pr PROJECT_UUID --target main --title "Task menu" --operation-key task-menu-pr-1

Den neu vorbereiteten Pull Request prüfst und bestätigst du anschließend als eigenen Vorgang. Die CLI übernimmt keine Freigabe, führt keinen Merge aus und wiederholt keine Schreibanfrage automatisch.

Bei git_operation_unconfirmed oder dem Zustand unknown zuerst den gespeicherten Vorgang lesen und mit lxi maker git reconcile PROJECT_UUID OPERATION_ID abgleichen. Eine Antwort kann nach 60 Sekunden ausbleiben, während die Aktion weiterläuft. Das ist keine Bestätigung, dass nichts passiert ist.

Fehlt nach der Vorbereitung die Antwort mit der Kennung, kannst du ausschließlich diese Vorbereitung mit demselben operation_key und unveränderten Eingaben wiederholen. list zeigt die letzten 30 Vorgänge; cancel zieht nur noch nicht versandte Freigaben zurück. Mit --json erhältst du Datensätze auf stdout und strukturierte Fehler auf stderr. Prüfe immer das Feld state.

REST-Basis: /api/v1/maker/projects/{project_id}/git/operations. GET listet Vorgänge, POST bereitet einen vor. Unter /{operation_id} liest du den Status; POST auf /execute, /adopt, /cancel oder /reconcile führt die benannte Aktion aus. Ausführung und Übernahme verlangen request_hash und confirmed: true. Eingabeschemas und Fehler sind in OpenAPI dokumentiert.

Die LXI API in deinem Stack.