ToolMesh | Blog

Einen UniFi-Standort in einem Prompt gegen NetBox abgleichen

Sat, 20 Jun 2026 00:00:00 GMT

Eine Quelle der Wahrheit bleibt nur so lange wahr, bis jemand das Netz anfasst. Tausch einen Access Point, lass DHCP eine neue Management-Adresse vergeben, häng in einem Hinterzimmer ein Gerät dazu — und der Controller hat sofort recht, während NetBox still und leise falsch liegt. Das fällt niemandem auf, der nicht jede Woche zehn Geräte von Hand vergleicht, also driftet die Dokumentation, und das Vertrauen in sie driftet mit.

Die übliche Antwort ist ein Sync-Skript. Stattdessen sollte ein Satz genügen:

Keine Pipeline. Kein ausbuchstabiertes Feld-Mapping. Wenn sich das Netz nächsten Monat ändert, läuft derselbe Satz erneut.

Was darunter passiert

Der Agent spricht über ein Gateway mit zwei Backends: Er liest den Live-UniFi-Controller und liest und schreibt NetBox, und jeder Aufruf läuft über die auditierte, policy-gesicherte Oberfläche des Gateways statt über eine Shell oder ein gespeichertes Admin-Token. Im Code Mode ist es ein kurzes Skript, das das Modell selbst schreibt, und seine Form ist ein Vergleich, kein Massenimport:

const site = "23by5njv";                           // desc: "HOME"
const live = await toolmesh.unifi_list_devices({ site });

for (const ap of live) {
  const model = MODEL_MAP[ap.model] ?? ap.model;   // U7PG2 -> "UniFi AC Pro Gen2", etc.
  const [nb]  = await toolmesh.netbox_list_devices({ name: ap.name });

  if (!nb) {                                        // new device -> create
    await toolmesh.netbox_create_device({ name: ap.name, device_type: typeId(model), role: AP, site: LII });
    log("created", ap.name);
  } else if (mgmtIp(nb) !== ap.ip) {               // moved address -> update one field
    await toolmesh.netbox_update_device(nb.id, { primary_ip4: ipId(ap.ip) });
    log("updated mgmt IP", ap.name, mgmtIp(nb), "->", ap.ip);
  } else {
    log("ok", ap.name);                            // already matches -> write nothing
  }
}

Zwei Dinge darin lohnen den genaueren Blick, weil Abgleich schwieriger ist als Import.

Die Modellcodes sind keine Produktnamen. Um zu entscheiden, ob ein UniFi-Gerät schon zu seinem NetBox-Eintrag passt, muss der Vergleich das normalisieren, was der Controller meldet. UniFi liefert jedes Gerät als internen Code: U7PG2 ist der UAP-AC-Pro (die 7 hat nichts mit Wi-Fi 7 zu tun), UAL6 ein U6 Lite, U7NHD ein nanoHD, U6EXT ein U6 Extender, U7PRO tatsächlich ein U7 Pro, und US8P60 der US-8-60W-Switch. Diese Übersetzungstabelle ist der Unterschied zwischen „dieser AP ist bereits korrekt” und einem Duplikat, das neben dem echten Gerät entsteht.

„Lass korrekte Einträge in Ruhe” ist die tragende Klausel. Jeder Zweig oben ist ein Get-or-Create-or-Update. Ein passendes Gerät erzeugt einen Schreibvorgang von nichts. Genau das macht den Satz sicher genug, ihn planmäßig gegen ein NetBox laufen zu lassen, das bereits Daten enthält — statt eines einmaligen Imports, den man nie zu wiederholen wagt.

Was dieser Lauf tatsächlich getan hat

Wir haben ihn gegen den Live-Controller laufen lassen. Hier das echte Ergebnis, kein konstruiertes:

reconcile HOME -> NetBox (site LII)
  AP-Kueche               U7NHD    192.168.100.43    ok
  AP-Praxis               U7NHD    192.168.100.46    ok
  AP-Labor                U7PG2    192.168.100.41    ok
  AP-Buero                U7NHD    192.168.100.44    ok
  AP-Garage               U7PG2    192.168.100.42    ok
  AP-U7-Pro Heizungsraum  U7PRO    192.168.100.154   ok
  AP-U6-Extender          U6EXT    192.168.100.199   ok
  AP-Mobil                UAL6     192.168.100.47    ok
  AP-Wohnzimmer           U7PG2    192.168.100.45    ok
  UbSwi-01                US8P60   192.168.100.183   ok
  -- 10 checked, 10 matched, 0 written.

Neun Access Points über fünf Modelle und ein PoE-Switch, jedes Gerät bereits vorhanden, jede Management-IP noch passend, das IoT-VLAN und das Management-Prefix bereits angelegt. Nettoänderung an NetBox: null.

Das ist die Antiklimax, die eigentlich der Punkt ist. Ein Agent, der nichts schreibt, wenn nichts gedriftet ist, ist genau die Eigenschaft, mit der man ihn auf ein CMDB richten kann, das einem wichtig ist, und ihn wieder und wieder laufen lässt. Man muss ihm nicht vertrauen, dass er die Daten nicht zerschießt. Man kann ihm beim Nichtstun zusehen.

Der Drift-Fall ist der, der sich auszahlt. Wäre AP-Garage auf .142 statt .42 aufgetaucht, hätte der Lauf eine Zeile ausgegeben, updated mgmt IP AP-Garage 192.168.100.42 -> 192.168.100.142, genau diesen einen Eintrag geschrieben und die anderen neun auf ok gelassen. Das Audit-Log zeigt exakt, welches Feld sich an welchem Gerät geändert hat, ausgeführt von welchem Konto — ohne dass man einen Diff durchlesen muss.

Die Definitionen brauchen dieselbe Sorgfalt

Die Geräte abzugleichen hält das Inventar ehrlich. Die Device-Type-Definitionen dahinter prüft ein Name-und-IP-Lauf nicht, und sie driften auf ihre eigene Weise. Dieser Lauf war ein guter Moment, eine davon zu erwischen: Der U7 Pro im Heizungsraum war — korrekt — mit einem Device-Type verknüpft, dessen Slug passte, aber dieser Typ war noch als „AC Pro, 802.11ac” beschriftet. Das Gerät passte, also hätte der Abgleich es nicht markiert; das Label war schlicht falsch, denn Modellcode und die Wi-Fi-7-Firmware des Geräts sagen etwas anderes. Wir haben es in derselben Sitzung korrigiert. Eine Quelle der Wahrheit ist nur so gut wie die Definitionen, auf die sie zeigt, und die verdienen einen bewussten Blick statt einer Annahme.

„Das mache ich seit Jahren mit Nornir”

Stimmt, und es funktioniert. Der Unterschied ist, dass es hier kein Skript zu pflegen gibt. Die Mapping-Tabelle lebt im Kontext des Modells, die Anweisung ist Klartext, und „gleich auch die Client-Liste ab” oder „lass die Gast-SSID aus” ist eine Änderung am Satz, nicht an einer Codebasis und ihren Tests. Wenn Ubiquiti in einem Controller-Update einen Modellcode umbenennt, korrigierst du eine Zeile eines Prompts.

Probier es gegen deinen eigenen Controller

Die UniFi- und NetBox-Connectoren sind offen: DADL, eine YAML-Datei pro API, hinter einem Apache-2.0-Gateway. Klone es und richte es auf deinen eigenen Controller und dein eigenes NetBox. Wenn du es lieber als Managed-Instanz betreiben willst, sprich mit uns unter vertrieb@dunkel.cloud. Fragen und Erfahrungsberichte sind in den GitHub Discussions willkommen.

Tool Discovery für 4.800 MCP-Tools — ohne Vektordatenbank

Thu, 11 Jun 2026 00:00:00 GMT

Auf unserer ToolMesh-Produktivinstanz lieferte eine discover_tools-Anfrage nach allem, was mit NetBox zu tun hat, rund 320 KB TypeScript-Deklarationen. Das sind etwa 80.000 Tokens — für viele Modelle das halbe Kontextfenster, verbraucht bevor der Agent ein einziges Tool aufgerufen hat. Die Anfrage nach allen Tools hätte eine Ausgabe in der Größenordnung von 2 MB erzeugt.

Das hat niemand so entworfen. Es ist so gewachsen.

Wie ein Discovery-Aufruf auf 320 KB kommt

ToolMesh ist ein self-hosted MCP-Gateway, das Code Mode spricht: Backends werden als flache JavaScript-Funktionen exponiert (toolmesh.netbox_list_devices(...)), und ein discover_tools-Meta-Tool liefert TypeScript-Signaturen, damit das Modell korrekte Aufrufe schreiben kann. Mit einer Handvoll Backends ist es genau richtig, jede passende Signatur vollständig zurückzugeben.

Unsere Instanz ist längst keine Handvoll mehr. Sie betreibt 49 Backends mit 4.767 Tools: NetBox allein steuert 608 bei, zwei MikroTik-Switches je 297, zwei OPNsense-Firewalls je 292, GitHub 203, Cloudflare 200. Eine vollständige Signatur liegt im Schnitt bei ~530 Bytes — NetBox-List-Endpoints tragen ein Dutzend und mehr Filterparameter.

Drei Effekte verstärken sich auf dieser Skala gegenseitig:

Volle Deklarationen sind der einzige Ausgabemodus. Jeder Treffer wird mit kompletter Parameterliste gerendert.
Das Such-Regex matcht Namen und Beschreibungen. Ein Pattern wie device fächert gleichzeitig über NetBox, UniFi, MikroTik und Shelly auf.
Multi-Instanz-Backends teilen sich Prefixe. Die Suche nach mikrotik liefert beide Switches — 594 Deklarationen.

Eine völlig vernünftige Agenten-Anfrage — „zeig mir die NetBox-Tools” — sprengt damit das Kontextfenster.

Die Lösung, die alle erwarten

Die reflexhafte Antwort des Jahres 2026 lautet: Tool-Beschreibungen embedden, in eine Vektordatenbank legen, semantisch suchen. Wir betreiben dieses Muster an anderer Stelle, und dort verdient es sein Geld.

Für dieses Problem haben wir bewusst Nein gesagt — aus drei Gründen.

Der Korpus ist winzig und statisch. ~4.800 kurze, gut benannte, gut beschriebene Dokumente, die sich nur bei einem Config-Reload ändern. Das ist ein In-Memory-Index, der in Millisekunden neu aufgebaut ist — kein Persistenzproblem. PostgreSQL/pgvector in ein Single-Binary-Go-Gateway zu holen, um fünftausend Strings zu durchsuchen, ist Infrastruktur außer jedem Verhältnis. Selbst der schlanke Weg — ein eingebettetes ONNX-Modell — schleppt eine native Runtime-Bibliothek mit, ein realer Packaging-Schmerz für Software, die andere selbst deployen.

Das Vokabular ist bereits ausgerichtet. Tool-Namen und -Beschreibungen sind für LLM-Konsum geschrieben. Lexikalisches Ranking hat exzellentes Material.

Vor allem aber: Der Agent ist selbst die semantische Schicht. Ein LLM, das eine kompakte, gerankte Trefferliste mit einer ehrlichen Statuszeile sieht, formuliert seine Anfrage in einem Zug selbst um. Es braucht keine perfekte Suche. Es braucht eine billige Iterationsschleife und Feedback darüber, was es gerade sieht.

Was wir stattdessen gebaut haben

Drei Änderungen, alle in ToolMesh v0.3.1+, null neue Dependencies.

1. Ausgabe, die degradiert statt detoniert

discover_tools skaliert seinen Detailgrad jetzt mit der Treffermenge: bis 25 Treffer kommen volle TypeScript-Signaturen, bis 250 Einzeiler-Zusammenfassungen, bis 2.000 nur Namen, darüber Zählungen pro Backend. Ein detail-Parameter übersteuert die Automatik, und ein harter 50-KB-Cap sichert jede Stufe ab.

Der frühere 2-MB-Worst-Case — gar kein Filter — antwortet jetzt mit etwa 1,5 KB:

// ToolMesh tools — per-backend overview
rest:netbox — 608 tools
rest:mikrotik-sw-lii-labor-perlman — 297 tools
rest:mikrotik-sw-mikrotik-10g — 297 tools
rest:opnsense_backup — 292 tools
...

// ── 4767 of 4767 tools matched — detail: overview (auto).
// Refine: narrower pattern, query:"<free text>" for ranked results,
//         detail:"full"|"summary"|"names"|"overview", limit:N.

Dieser Footer ist die wichtigste Zeile des ganzen Features. Jede Antwort sagt, wie viel vom Katalog gematcht hat, wie viel gezeigt wird und wie man verfeinert. Der Agent verwechselt eine gekürzte Sicht nie mit der ganzen Welt — und korrigiert sich im nächsten Aufruf selbst, statt zu raten.

2. Geranktes Freitext-Suchen — BM25 in ~200 Zeilen Go

Regex-Patterns sind großartig für exakte Lookups (^netbox_list) und schlecht für Exploration. Der neue query-Parameter macht geranktes Freitext-Suchen:

discover_tools({ query: "create dns record for a zone" })

liefert die Top 25 nach Relevanz — Cloudflare-, INWX- und Linode-DNS-Tools in gemischter Reihenfolge, ohne NetBox-Rauschen. Darunter liegt ein schlichter BM25-Index über Tool-Namen (geboostet), Beschreibungen und Parameternamen — etwa 200 Zeilen dependency-freies Go, pro Aufruf in Mikrosekunden neu aufgebaut. Weil Parameternamen mitindexiert sind, findet eine Query wie rack_id das Tool netbox_list_devices, obwohl „rack” im Tool-Namen nirgends vorkommt.

BM25 ist fünfzig Jahre alte Information-Retrieval-Technik. Das ist keine Schwäche — bei dieser Korpusgröße ist es genau der Punkt.

3. Discovery in der Sandbox

Der größte strukturelle Gewinn: Agenten brauchen überhaupt keinen separaten Discovery-Roundtrip mehr. Innerhalb von execute_code stehen zwei lokale Helfer bereit:

// find → inspect → call, in ONE round trip
const hits = toolmesh.discover("move task to kanban bucket", 5);
const schema = toolmesh.describe(hits[0].name);
return await toolmesh[hits[0].name]({
  project_id: 2, view_id: 8, task_id: 200, bucket_id: 5
});

toolmesh.discover() und toolmesh.describe() laufen gegen den In-Memory-Index — kein Backend-Call, keine Kontextkosten über das hinaus, was der Code explizit zurückgibt, ausgenommen vom Call-Budget pro Ausführung und gefiltert nach der Autorisierung des Aufrufers wie jede andere Oberfläche auch. Discovery wird etwas, das der Code tut — nicht etwas, das der Kontext bezahlt.

Was der Live-Test in zwanzig Minuten fand

Wir haben den Branch produktiv deployt und aus einer echten Agenten-Session heraus getestet. Zwei Bugs zeigten sich fast sofort — beide für Unit-Tests unsichtbar:

Ein veraltetes Client-Schema machte aus limit einen String. Der MCP-Client hatte das alte discover_tools-Schema gecacht und serialisierte den unbekannten Parameter limit: 5 als String "5" — den der Server stillschweigend ignorierte. Clients, die man nicht kontrolliert, halten veraltete Schemas; agentenseitige Parameter akzeptieren jetzt auch numerische Strings.

Zusammenfassungen brachen bei „e.g.” ab. Der Einzeiler-Summarizer schnitt am ersten Punkt-plus-Leerzeichen und produzierte Set device key properties (e.g. — ein Punkt beendet einen Satz jetzt nur noch, wenn ein Großbuchstabe folgt.

Beides ist unglamourös. Beides ist der Unterschied zwischen einem Feature, das gut demonstriert, und einem, das den Kontakt mit echten Clients überlebt.

Prior Art — und was sich auf Skala ändert

Progressive Disclosure für Tools ist nicht unsere Erfindung. Anthropics Beitrag zu Code Execution mit MCP beschreibt das bedarfsweise Laden von Tool-Definitionen; Claude Code lädt Tool-Schemas erst bei Bedarf; Cloudflares Code Mode hat das Muster „Code gegen Tools schreiben” populär gemacht. Das Pattern konvergiert zum Konsens.

Was der Produktionsmaßstab hinzufügt, sind die Teile, die in Demos selten vorkommen: Ranking (weil 764 Kandidaten irgendwo auf „dns” matchen), eine immer präsente Feedback-Zeile (weil Agenten gut verfeinern — aber nur, wenn man ihnen sagt, was sie gesehen haben), harte Output-Caps (weil irgendein Client immer nach allem fragt) und Discovery in der Sandbox (weil der billigste Kontext der ist, der nie ausgegeben wird).

Wie es weitergeht

Derselbe Index bekommt zwei weitere Konsumenten: einen Capability Index für verschachtelte Code-Mode-Backends — MCP-Server, die selbst nur search/execute exponieren und deren Fähigkeiten ToolMesh bei der Registrierung sondiert und indexiert — und daraus generierte synthetische Tool-Beschreibungen auf MCP-Ebene. Und falls reale Vokabular-Lücken es je rechtfertigen, lässt sich ein optionaler Embedding-Kanal hinter derselben query-API nachrüsten — erst messen, dann bauen.

Die Implementierung ist Open Source (PR #80, Apache 2.0). Die Tool-Definitionen, die sie durchsucht, kommen aus DADL — eine YAML-Datei pro API, über 25 fertige in der Registry.

Wenn du ein MCP-Setup betreibst, das seiner Tool-Liste entwachsen ist: Wir würden wirklich gern hören, wie Discovery auf deiner Skala aussieht — GitHub Discussions oder presse@dunkel.cloud.

Von der Switch-Konfiguration zu NetBox in einem Prompt

Mon, 01 Jun 2026 00:00:00 GMT

Die Ausgangslage

Du betreibst NetBox als deine Single Source of Truth. Das funktioniert — bis es das nicht mehr tut.

Letzten Dienstag hat jemand einen Switch in Rack B getauscht. Zwei VLANs hinzugefügt, ein paar Interfaces umbenannt, einen Uplink verschoben. NetBox weiß von all dem nichts. Jetzt ist dein IPAM still und heimlich falsch, deine Cable Map lügt, und die nächste Person, die sich für eine Change-Planung auf NetBox verlässt, wird einen schlechten Nachmittag haben.

Die übliche Lösung ist ein Sync-Skript. Du schreibst ein paar hundert Zeilen, die die Live-Konfiguration ziehen, gegen NetBox diffen und die Deltas zurückschreiben. Es funktioniert. Dann liefert der Hersteller ein Firmware-Update, ein Interface-Namensschema ändert sich, du nimmst ein zweites Switch-Modell dazu — und jetzt pflegst du das Skript so sorgfältig wie das Netz, das es beschreibt.

Es gibt eine andere Form dafür.

Die Anweisung

So sieht die Aufgabe aus, wenn das Tooling die Konnektivität trägt und du die Absicht:

Lies die Live-Konfiguration vom Switch perlman. Vergleiche seine Interfaces, IP-Adressen und VLANs mit dem, was NetBox für dieses Gerät hat. Nenn mir jeden Unterschied und aktualisiere dann NetBox so, dass es zum Switch passt — aber halt an und zeig mir alles, was nach einer Löschung aussieht, bevor du es entfernst.

Das ist alles. Kein Skript. Morgen lautet die Anweisung „… und gleich noch den MikroTik in Rack B mit ab”, und nichts in deiner Codebase muss sich ändern — weil es keine Codebase gibt. Die Anweisung ist die Automatisierung, und sie ist bewusst Wegwerfware.

Was darunter tatsächlich passiert

Das ist keine Magie, und der Sinn dieser Serie ist, dass du genau sehen kannst, was läuft. Der Agent hat zwei Tool-Oberflächen vor sich, beide über einen einzigen ToolMesh-Endpoint bereitgestellt:

den MikroTik-Switch, beschrieben durch eine DADL-Datei — rund dreißig Zeilen YAML machen aus seiner REST-API aufrufbare Tools wie export_config, list_interfaces und list_ip_addresses
NetBox, auf dieselbe Weise — netbox_get_device, netbox_create_interface, netbox_create_ip_address, netbox_update_*

Im Code Mode feuert das Modell nicht einen Tool-Call pro Round-Trip ab. Es schreibt ein kurzes Stück JavaScript, das serverseitig läuft und nur das Ergebnis zurückgibt:

// pull live state
const live = await toolmesh.mikrotik_perlman_list_interfaces({});
const liveIps = await toolmesh.mikrotik_perlman_list_ip_addresses({});

// pull NetBox's view of the same device
const device = await toolmesh.netbox_get_device({ name: "perlman" });
const nbIfaces = await toolmesh.netbox_list_interfaces({ device_id: device.id });

// diff happens here, in code, not in the model's head
return diff(live, liveIps, device, nbIfaces);

Eine Ausführung, ein Ergebnis zurück an das Modell. Ein Katalog aus achtzig NetBox-Tools plus den Switch-Tools würde rund 142.000 Tokens kosten, um ihn bei jedem Reasoning-Schritt zu annoncieren, wenn man sie alle als JSON-Schemas auflisten würde. Code Mode hält das näher an tausend, konstant, egal wie viele Backends du hinzufügst. Genau das ist der Unterschied zwischen „das ist nett in einer Demo” und „das kann ich gegen mein echtes Netz laufen lassen”.

Die Stellen, vor denen du Respekt hättest — abgesichert

Nichts wird stillschweigend gelöscht. Die Anweisung sagte: halt an und zeig mir Löschungen — und das wird am Gate erzwungen, nicht bloß dem guten Willen des Agenten überlassen. Zwei Kern-Mechanismen sorgen dafür. Zuerst die Autorisierung: Über OpenFGA kann ein Agent netbox_create_* und netbox_update_* halten, aber niemals netbox_delete_* — die Lösch-Tools werden für ihn schlicht nie freigeschaltet. Und die ExecuteTool()-Pipeline führt vor jedem Call, der das Backend erreicht, ein Pre-Gate aus, in dem eine kurze harte Regel — schlichtes JavaScript — alles abweist, was auf netbox_delete_* passt. Die Pipeline ist fail-closed: Kann eine Regel nicht entscheiden, wird der Call abgelehnt, nicht durchgewinkt. Anlegen und Updates laufen durch; Löschungen werden am Gate abgewiesen, sodass der Agent dir die gefundenen Löschungen zeigt und keine davon ausführt. Das schreibst du einmal, und es gilt für jeden Prompt, den du je ausführst.

Keine Credentials im Prompt. Der API-Token des Switches und der NetBox-Token erreichen das Modell nie. Sie liegen in ToolMeshs Credential Store und werden zum Zeitpunkt des Calls injiziert. Das Modell orchestriert; ein Geheimnis sieht es nie.

Du kannst beweisen, was passiert ist. Jeder Call landet in einem strukturierten Audit-Log — welches Tool, welches Gerät, was sich geändert hat, wie lange es gedauert hat, Erfolg oder abgelehnt. Wenn in drei Wochen jemand fragt, warum das Interface sfp-sfpplus3 umbenannt wurde, ist die Antwort eine Abfrage und kein archäologisches Projekt.

Was das ist — und was nicht

Wenn deine Reaktion ist „Config-to-NetBox mache ich seit zehn Jahren mit Nornir” — ja, das tust du, und gut. Die Behauptung hier ist nicht, dass das mächtiger ist als ein eigens gebautes Skript. Sondern dass es kein Skript zu pflegen gibt. Die Abgleich-Logik ist nicht an einen Hersteller, ein Namensschema oder eine NetBox-Version genagelt. Die Anweisung passt sich der Situation in einfacher Sprache an; die Tools darunter sind in YAML deklariert, das du in Git diffen kannst. Wenn sich die Situation ändert, änderst du einen Satz, keine Pipeline.

Das ist die ganze Wette: Netz-Zustand ändert sich ständig, also sollte die Schicht, die ihn abgleicht, der billige, wegwerfbare Teil sein — nicht der, den du babysittest.

Willst du es in deinem eigenen Netz ausprobieren?

Die ehrliche Hürde hier ist das Setup: ToolMesh aufsetzen, die DADL für deinen Switch schreiben, NetBox verdrahten. Wenn genau diese Hürde dich aufhält, überspring sie. ToolMesh ist ein Angebot der Dunkel Cloud GmbH, und wir richten dir eine persönliche Instanz auf einer eigenen VM ein — du behältst die volle Kontrolle und deine eigenen Credentials, wir übernehmen nur die anfängliche Verdrahtung, damit du sie auf deine Hardware richten und sehen kannst, ob der Abgleich gegen deine Realität wirklich standhält.

Dieses Angebot ist ernst gemeint, und es ist der schnellste Weg herauszufinden, ob das zu deiner Arbeitsweise passt.

Dies ist Beitrag 1 einer Serie über das Steuern von NetBox aus realer Infrastruktur: MikroTik, OPNsense, Xen Orchestra, Hetzner, vSphere und UniFi. Jeder einzelne ist ein echter Workflow aus unserem eigenen Stack, keine konstruierte Demo.

ToolMesh ist Open Source (Apache 2.0). DADL ist eine offene Spezifikation (CC BY-SA 4.0) mit einer öffentlichen Registry unter dadl.ai.

Die volle REST-API von Xen Orchestra 6.5 — 245 Tools aus einer DADL

Fri, 29 May 2026 00:00:00 GMT

Xen Orchestra hat die letzten beiden Releases darauf verwendet, seine REST-API zu etwas zu machen, auf dem man aufbauen kann. XO 6.4 (April 2026) hat /rest/v0/ als stabil markiert und fein granulares RBAC v2 ergänzt; 6.5 hat PATCH /vms/{id} für partielle VM-Updates und eine eigene /vm-controllers-Collection hinzugefügt. Im Februar hat Vates außerdem einen eigenen MCP-Server mit XO 6.2 ausgeliefert — sieben Tools, bewusst read-only, damit Teams ihn vom ersten Tag an in der Produktion aktivieren können.

Wir haben einen anderen Schnitt derselben API gewählt. Die DADL für Xen Orchestra deckt die gesamte 245-Endpoint-REST-Oberfläche ab — lesend und schreibend — als eine YAML-Datei. Dieser Post ist das Build-Log und eine ehrliche Antwort auf die naheliegende Frage: Warum zwei MCP-Oberflächen für dasselbe Produkt?

Was die REST-API jetzt abdeckt

Die XO REST-API ist längst keine dünne Leseschicht mehr. Ab 6.5 exponiert sie den vollständigen Objektgraphen — VMs (inklusive PATCH-Teilupdates und Snapshot-Revert), VM-Controller, VM-Templates, VM-/VDI-Snapshots, Hosts, Pools, Storage (SR/VDI/VBD), Netzwerk (VIF/PIF/PBD), Hardware-Passthrough (PCI/PGPU/SM) — dazu jede Lifecycle-Aktion: Power, Snapshot, Clone, Migration, Export/Import, Hotplug. Über den Objekten liegen die operativen Oberflächen: Tasks, Backups (Jobs, Logs, Repositories, Restore, Schedules), Echtzeit-Änderungsevents über Server-Sent Events, RBAC v2 (Users, Groups, ACL-Roles, ACL-Privileges) und Host-/Pool-Wartung (Rolling Reboot, Rolling Update, Emergency Shutdown).

Das ist eine große API, und fast alles davon verändert Infrastruktur. Nichts von der Schreibseite ist über den eigenen MCP-Server erreichbar — by design, nicht aus Versehen.

Die Zahlen

	DADL (`xen-orchestra.dadl`)	`@xen-orchestra/mcp` (Vates, eigen)
Tools	245	7
Umfang	lesend und schreibend	read-only by design
Coverage	jedes REST-Objekt + Lifecycle-Aktion, Backups, RBAC v2, SSE-Events, SDN-Traffic-Rules, Dashboards, Auth-Tokens	Infrastruktur-Summary, Pools / Hosts / VMs auflisten und inspizieren, Pool-Dashboard, Dokumentationssuche
Create / Start / Migration / Delete?	ja	nein — bewusst
Verteilung	eine 245-Tool-YAML-Datei	Node-Server, mitgeliefert ab XO 6.2
Einem neuen API-Release folgen	~30 Zeilen YAML pro Endpoint	kommt mit dem XO-Release
Governance-Schicht	Credentials, Autorisierung, Audit (über ToolMesh)	keine — lokal, in-process

Die lokale Validierung, ausgeführt aus dem Registry-Checkout:

> cd dadl-registry && npm run validate
✅ xen-orchestra.dadl — 245 tools

Quelle auf GitHub: dadl-registry/xen-orchestra.dadl. Live in der Registry unter dadl.ai/d/xen-orchestra. Die DADL-Spezifikation selbst: dadl.ai/spec.

Ein durchgespieltes Beispiel: eine VM-Änderung, rückgängig machbar

Der Sinn der Schreibseite ist, dass sie Infrastruktur tatsächlich verändert — sicher, mit Spur. Hier ist ein Round-Trip aus drei Calls: eine laufende VM finden, sie snapshotten, damit die Änderung umkehrbar ist, und sie dann patchen.

// 1. Find the VM by name (XO filter syntax, compact fields)
const [vm] = await toolmesh.xen_orchestra_list_vms({
  filter: "name_label:web-fra-01",
  fields: "uuid,name_label,tags"
});

// 2. Snapshot first, so the change is undoable
await toolmesh.xen_orchestra_snapshot_vm({
  id: vm.uuid,
  name_label: `pre-change ${new Date().toISOString().slice(0, 10)}`
});

// 3. PATCH the live VM — tags is a hot field, applied while running (XO 6.5)
await toolmesh.xen_orchestra_update_vm({
  id: vm.uuid,
  tags: [...vm.tags, "managed:toolmesh"]
});

Drei Calls. Kein Glue-Code. Schritt 2 und 3 sind genau das, was ein read-only MCP-Server nicht kann — und die DADL übernimmt transparent:

die ungewöhnliche cookie-basierte Authentifizierung (der Token wird serverseitig als Cookie: authenticationToken=… injiziert — das Modell sieht ihn nie);
das async-by-default-Aktionsmodell — die meisten Writes geben eine Task-Referenz zurück; sync setzt man nur für kurze Operationen, und für lange (Migration, Export) pollt man get_task, um HTTP-Client-Timeouts zu vermeiden;
die Cold-vs-Hot-Field-Unterscheidung bei update_vm — memoryStaticMax, cpusStaticMax, secureBoot brauchen eine heruntergefahrene VM, während tags, nameLabel und cpus live greifen (das Beispiel nutzt tags, läuft also ohne Downtime);
Retries bei transienten Fehlern und terminale Klassifizierung für 404 (“no such VM”) und RBAC-403.

Dieselben Calls aus Claude oder jedem anderen Agenten. Kein Xen-Orchestra-spezifischer Code auf der Client-Seite.

Read-only ist ein Feature, keine Lücke

Das naheliegende Framing — “245 schlägt 7” — ist das falsche. Die beiden Oberflächen beantworten verschiedene Fragen.

Der eigene MCP-Server von Vates ist absichtlich read-only. Er läuft in-process, kommt mit XO mit, braucht keine externe Infrastruktur und kann nichts kaputt machen. Wenn die Frage lautet “lass einen Assistenten meine Infrastruktur ansehen und Fragen dazu beantworten”, ist das die richtige Form, und man sollte ihn nutzen. Wir versuchen nicht, ihn zu ersetzen — die DADL enthält sogar ein get_mcp_status-Tool, das meldet, ob XOs eigener eingebauter MCP-Server aktiviert ist.

Die DADL beantwortet eine andere Frage: “lass einen Agenten meine Infrastruktur betreiben — erstellen, patchen, snapshotten, migrieren, sichern, RBAC provisionieren — ohne ihm rohe Admin-Credentials zu geben.” Das ergibt nur mit einer Kontrollschicht darunter Sinn. Über ToolMesh läuft jedes der 245 Tools hinter zentralisierten Credentials (der XO-Token erreicht das Modell nie), Autorisierung (ein Agent kann list_vms und snapshot_vm erhalten, aber nicht delete_sr) und einem Audit-Log (jeder Call protokolliert mit Was, Wann und Warum). Die Schreibseite ist der ganze Punkt, und die Governance-Schicht ist das, was die Schreibseite sicher exponierbar macht.

Beide Definitionen liegen in derselben Registry. Sie sind Ergänzungen: read-only-Discovery in-process, vollständiges Lifecycle-Management über ein governtes Gateway.

Der API hinterherzukommen ist ein YAML-Diff

XO 6.4 hat RBAC v2 ergänzt; 6.5 hat PATCH /vms/{id}, /vm-controllers und einen REST-Snapshot-Revert-Endpoint hinzugefügt. Jedes davon in der DADL nachzuziehen ist dieselbe kleine Arbeitseinheit: xen-orchestra.dadl öffnen, den Tool-Block ergänzen (~30 Zeilen YAML pro Endpoint), npm run validate laufen lassen, einen PR aufmachen, das Diff reviewen, mergen. ToolMesh nimmt die neuen Tools beim nächsten Reload auf. Keine SDK-Änderungen, kein Release zum Schnüren, kein npm-Publish, kein “bitte upgraden” an die Nutzer.

Zwei konkrete Beispiele aus dem aktuellen Release:

6.5 hat POST /vms/{id}/actions/revert_snapshot für automatisierbaren Snapshot-Revert ausgeliefert. Die DADL führt ihn bereits als revert_vm_to_snapshot, annotiert mit “requires XO 6.5+ (route returns 404 on older builds)” — gegen einen älteren Host bekommt der Agent also einen sauberen terminalen Fehler statt eines stillen Fehlschlags.
6.5 legt außerdem die Grundlage für eine eigene VM-Administrator-Rolle. Darauf muss man nicht warten: Die DADL exponiert die volle RBAC-v2-Oberfläche (create_acl_role, create_acl_privilege, attach_acl_role_to_user), sodass man heute schon eine least-privilege Operator-Rolle zusammenstellen und einem Agenten genau die Privilegien geben kann, die er haben soll — read auf vm, host, pool, mehr nicht.

Das allgemeine Argument haben wir in einem früheren Post gemacht; XO ist die konkrete Fallstudie für eine schreiblastige API.

Das Context-Window-Argument

Es gibt einen zweiten Grund, warum die Tool-Zahl weniger zählt, als sie aussieht: Code Mode. Statt alle 245 XO-Tool-Beschreibungen in das Context-Window des Modells zu injizieren, exponiert ToolMesh zwei Meta-Tools (list_tools und execute_code). Das Modell entdeckt bei Bedarf, was verfügbar ist, und ruft flache Tool-Namen aus einer gesandboxten JavaScript-Runtime auf — toolmesh.xen_orchestra_list_vms, toolmesh.xen_orchestra_snapshot_vm, keinen verschachtelten Namespace.

Die Token-Kosten sind ungefähr konstant: ~1 k Tokens Meta-Tool-Beschreibung, egal ob die Registry ein Backend mit 7 Tools hält oder 27 Backends mit 3.338. Ein 245-Tool-Backend fügt jeder Claude-Konversation, die Xen Orchestra nicht aktiv anfasst, null Tokens hinzu. Das ist auch der Grund, warum das JavaScript im Beispiel oben keine Illustration ist — es ist buchstäblich das, was das Modell schreibt, um die Tools aufzurufen.

Ehrliche Einschränkungen

Die DADL ist kein universeller Gewinn. Echte Grenzen:

Der SSE-Event-Stream ist halb deklarativ. open_events_stream gibt eine Subscription-ID zurück, und die DADL beschreibt den Subscribe-Handshake, aber der Server-Sent-Events-Stream selbst ist ein Streaming-Protokoll — DADL beschreibt REST, keine langlebigen Streams. Für das Pollen von Task-Status pollt get_task?wait=true sauber; für einen echten Echtzeit-Feed ist man am Rand dessen, was eine deklarative REST-Definition modelliert.
VDIs lassen sich nicht über REST umbenennen. Es gibt kein PATCH /vdis/{id} in der API — also auch kein update_vdi-Tool. Umbenennen geht über Tags oder den Abstieg zur JSON-RPC-API. Wir exponieren, was existiert; wir können nicht exponieren, was es nicht gibt.
SDN-Traffic-Rules brauchen ein Premium-Plugin. Die vier Traffic-Rule-Tools (add/delete_network_traffic_rule, add/delete_vif_traffic_rule) steuern den SDN-Controller von XO — ein Plugin, das XOA Premium beiliegt und nicht Teil der dokumentierten Kern-REST-API ist. Ohne geladenes Plugin liefern die Routen 404, der Agent bekommt also einen sauberen terminalen Fehler statt eines stillen No-ops. Die übrigen 241 Tools laufen gegen eine Standard-REST-API.
Die Schreibseite braucht Privilegien. Vollständige Coverage setzt einen Admin-User oder einen RBAC-v2-User mit den richtigen acl-privileges voraus. Wenn man nur schauen will, ist der read-only-Server von Vates weniger Setup und ein kleinerer Blast-Radius — nimm ihn.
Jeder Call hüpft durch ToolMesh. Für interaktiven Betrieb ist das unsichtbar; für High-Throughput-Batch-Jobs gegen XO ist der direkte REST-Aufruf schneller.

DADL ist gut in einer bestimmten Sache — eine REST-API-Oberfläche schnell für Agenten verfügbar zu machen, mit einer echten Kontrollschicht darunter. Bei Xen Orchestra ist diese Oberfläche zufällig 245 Endpoints überwiegend verändernder Operationen — genau der Fall, in dem sich eine Governance-Schicht auszahlt.

Was tatsächlich anders ist

Die substanzielle Frage ist nicht “DADL vs. der eigene MCP-Server” — ToolMesh betreibt beide, und sie koexistieren in derselben Registry. Die Frage ist: Was kostet es, einem Agenten die Schreib-Seite einer API zu geben, sicher?

Bei einem read-only-Server lautet die Antwort “gar nicht” — das ist der bewusste Trade. Bei einem handgeschriebenen Read-Write-Server kostet es einen Engineering-Zyklus pro Endpoint: SDK-Shapes, Handler, Tests, ein Release, ein npm-Publish, Nutzer-Upgrades, plus die Autorisierung und das Audit, die man selbst bauen muss. Bei einer DADL hinter ToolMesh kostet es einen PR mit einem YAML-Diff, und Credentials, Autorisierung und Audit kommen aus der Runtime.

Das ist die Asymmetrie. Nicht “alle sollten den eigenen Server wegwerfen” — behalte ihn für read-only-Discovery. Nur: wenn ein Agent Xen Orchestra tatsächlich betreiben soll, ist die Arbeitseinheit ein YAML-Diff, und die Sicherheit liegt in der Schicht darunter statt im Weglassen der Schreib-Tools.

Anatomie einer Enterprise Tool Library

Tue, 26 May 2026 00:00:00 GMT

Die meisten Teams laufen am selben Freitagnachmittag gegen dieselbe Wand. Eine Handvoll MCP-Server lief in der Entwicklung problemlos. Inzwischen sind es fünfzehn, die Hälfte davon hängt an Produktion, und niemand kann die einfachen Fragen beantworten — wer hat was aufgerufen, mit welchem Credential, gegen welche Policy, und wo ist das Log. Das Problem ist nicht ein einzelner Server. Das Problem ist, dass es darunter keine gemeinsame Schicht gibt.

In diesem Artikel geht es um genau diese Schicht. Er beschreibt, wie eine Enterprise Tool Library gebaut ist: die sechs Anliegen, die sie in einer Runtime vereinen muss, die fail-closed Pipeline, die jeder Tool-Call durchläuft, und die beiden Ideen — DADL und Code Mode — die das Ganze auf Dutzende Backends skalierbar machen, ohne den Kontext des Agenten aufzublähen. Die geschäftliche Einordnung auf Deutsch liefert der Schwester-Artikel auf dunkel.cloud (DE).

Was eine Enterprise Tool Library tatsächlich ist

Der Begriff „MCP Gateway” wird für zwei sehr verschiedene Dinge verwendet. Das eine ist ein Passthrough-Proxy, der Tool-Calls an einen einzelnen Upstream-Server weiterreicht. Das andere ist eine kontrollierte Ausführungsschicht, die vor jedem Backend der Organisation sitzt. Nur das Zweite ist eine Enterprise Tool Library.

Das unterscheidende Merkmal ist nicht die Anzahl der Backends. Es ist strukturell. Eine Library hat:

Eine Authentifizierungs- und Autorisierungsgrenze. Jeder Tool-Call — egal welches Upstream-System er am Ende trifft — durchläuft dieselbe Identitätsprüfung und dieselbe Zugriffsentscheidung pro Tool. Eine einzige Quelle der Wahrheit für „wer darf was aufrufen”.
Eine kohärente Audit-Linie. Jeder Call landet im selben Store, mit denselben Feldern, abfragbar mit einer SQL-Query. Nicht „Logs hier drüben, MCP-Server-Logs da drüben, ein CSV, das jemand letztes Quartal exportiert hat”.
Eine gemeinsame deklarative Beschreibungssprache. REST-APIs, MCP-Server, interne Dienste — alle über dasselbe Definitionsformat zugänglich, sodass Policy, Retry, Pagination und Credential-Injection Runtime-Anliegen statt maßgeschneiderter Wrapper-Code sind.
Ein konstanter Kontext-Footprint. Das zwanzigste Backend hinzuzufügen verdoppelt nicht die Tokens, die der Agent mitschleppen muss. Die Kosten für „mehr Tools” trägt die Library, nicht jeder Prompt.

Ein einzelner MCP-Server hat nichts davon. Ein Passthrough-Gateway hat bestenfalls die ersten zwei, und das auch nur für ein Backend gleichzeitig. Eine Enterprise Tool Library ist das, was entsteht, wenn diese vier Eigenschaften über die gesamte Tool-Oberfläche hinweg gelten.

ToolMesh ist unsere Open-Source-Implementierung dieser Form. Der Rest dieses Artikels läuft durch, wie die Teile zusammenpassen.

Die sechs Säulen als Mechanik

ToolMesh ordnet die Arbeit in sechs Säulen. Jede löst ein konkretes Problem, lebt in einem bestimmten Paket und hat einen einzigen Config-Berührungspunkt.

1. Any Backend — zwei Eingangspfade, eine Runtime

Die Library muss vor allem stehen können, was die Organisation bereits betreibt. ToolMesh unterstützt zwei Eingangspfade in dieselbe Ausführungs-Pipeline:

MCP-Backends umschließen bestehende MCP-Server via HTTP- oder STDIO-Transport. Wer schon einen funktionierenden Server hat, behält ihn; ToolMesh legt die Governance-Schicht drumherum.
DADL-Backends beschreiben REST-APIs deklarativ in YAML. Kein eigener Server-Code, keine separate Runtime — die Beschreibung ist die Integration.

Beide Pfade registrieren sich über dasselbe interne backend.Register()-Interface und produzieren Tools, die für das Modell identisch aussehen. Der Backend-Typ wird zum Implementierungsdetail; die Sicherheitsgarantien hängen nicht davon ab. Konfiguration lebt in einer einzigen Datei:

config/backends.yaml

backends:
  - name: github
    type: rest
    file: github.dadl
  - name: cloudflare
    type: rest
    file: cloudflare.dadl
  - name: legacy-internal
    type: mcp
    transport: http
    url: http://internal-mcp:8080

Ein Backend hinzuzufügen heißt, eine Datei zu editieren — keinen Dienst zu bauen.

2. Code Mode — flache Tool-Oberfläche, konstanter Kontext

Ein naives MCP-Setup gibt jede Tool-Definition direkt an das Modell. Bei einem Backend ist das in Ordnung. Bei zwanzig wird es ruinös: Dutzende Tool-Schemata, jedes mit eigenen Parametern und Beschreibungen, allesamt in den Kontext geladen, bevor der Agent die Frage des Nutzers überhaupt gelesen hat. Rund 50.000 Tokens an reinen Tool-Metadaten ist eine normale Beobachtung in der Praxis.

ToolMesh umgeht das vollständig. Das Modell sieht zwei Meta-Tools — discover_tools und execute_code — und ein kompaktes TypeScript-Interface, das die verfügbaren Funktionen beschreibt. Dieses Interface umfasst grob 1.000 Tokens, egal ob ein oder zwanzig Backends angeschlossen sind. Der Agent ruft discover_tools einmal auf, um die Typ-Signaturen zu sehen, und schreibt dann JavaScript dagegen:

const issues = await toolmesh.github_list_issues({
  owner: "DunkelCloud",
  repo: "ToolMesh",
  state: "open",
});
const recent = issues.filter(i => Date.now() - new Date(i.created_at) < 7*864e5);
return recent.map(i => ({ number: i.number, title: i.title }));

Der execute_code-Runner parst dieses JavaScript mit einem Go-AST-Walker, extrahiert jeden toolmesh.*-Aufruf und schickt ihn durch die normale Pipeline. Das Modell führt nie beliebigen Code gegen Ihre Infrastruktur aus — es produziert ein Skript, dessen Tool-Calls statisch extrahiert und einzeln autorisiert werden. Code Mode ist im Detail unter /de/code-mode/ beschrieben.

3. Credential Store — Laufzeit-Injection, nie im Prompt

Das Anliegen, das die meisten Setups stillschweigend ignorieren. Eine typische MCP-Konfiguration legt API-Keys in Client-Configs, in Env-Vars auf Entwickler-Laptops oder — im schlimmsten Fall — direkt in den Modell-Kontext. Nichts davon rotiert gut, nichts davon auditiert gut, und jedes davon kann in ein Transkript lecken.

ToolMesh referenziert Credentials per Namen in der DADL-Datei und löst sie serverseitig zur Ausführungszeit auf. Das Modell sieht das Tool-Interface und die gefilterte Antwort. Es sieht nie das Token. Die Credential-Schicht ist über credentials.Register() austauschbar:

Stufe	Backend	Einsatz
Embedded	Env-Vars (`CREDENTIAL_*`)	Lokale Entwicklung, Single-Tenant
Geplant	Infisical	Zentrales Secret-Management
Geplant	HashiCorp Vault / OpenBao	Enterprise-Secret-Governance

Das Embedded-Backend ist der Default und ist im Binary enthalten. Die gehosteten Backends sind über den Enterprise-Build-Tag geplant — das Registrierungs-Muster (inspiriert von Go’s database/sql-Treibern) ist bereits an Ort und Stelle, also erfordert das Hinzufügen eines Backends keinen Eingriff in den Executor.

4. OpenFGA — ReBAC, ehrlich gegenüber dem Default

Autorisierung in ToolMesh ist beziehungsbasiert, betrieben von OpenFGA. Das Modell ist user → plan → tool: Nutzer gehören zu Plänen, Pläne haben Tool-Berechtigungen, und der Executor fragt OpenFGA, ob der Aufrufer dieses spezifische Tool aufrufen darf, bevor irgendetwas läuft.

Heute werden zwei Modi ausgeliefert:

`OPENFGA_MODE`	Verhalten
`bypass` (Default)	Keine Autorisierungs-Checks. Nur für Dev.
`restrict`	OpenFGA bei jedem Tool-Call durchgesetzt. Produktion.

Der Default ist bypass, damit docker compose up eine lauffähige Instanz produziert, ohne jeden Mitwirkenden durch ein OpenFGA-Setup zu zwingen. Das ist eine bewusste DX-Entscheidung, keine Sicherheitsaussage. Produktiv-Deployments wechseln auf restrict und führen ./config/openfga/setup.sh aus, um das Modell zu seeden. Den Default auf bypass zu setzen ist ehrlich darüber, wo die Dev-Oberfläche beginnt; die Seite Authorization dokumentiert die Produktions-Checkliste.

5. Output Gate — deterministisches JS, mit Wachstumsraum

Nicht jede Response sollte das Modell unverändert erreichen. Kundendatensätze enthalten PII. Interne Systeme liefern Metadaten zurück, die der Agent nicht braucht. Fehlermeldungen leaken gelegentlich Infrastruktur-Details.

Heute liefert ToolMesh Layer 1 des Gates aus: deterministische JavaScript-Policies, ausgeführt in der eingebetteten goja-Engine. Eine Policy bekommt die Response und den Caller-Kontext und gibt einen gefilterten Payload oder eine Ablehnung zurück:

policies/redact-pii.js

export function onResponse(response, ctx) {
  if (ctx.user.callerClass === "trusted") return response;
  return redactEmails(redactPhones(response));
}

Policies sind reviewbarer Code, der im Repo eingecheckt ist, keine Black-Box-Konfiguration. Das Gate sitzt auf einer austauschbaren Evaluator-Registry (gate.RegisterEvaluator()) — weitere Layer sind geplant, darunter LLM-basierte Inhaltsklassifikation für Compliance-Anwendungen. Heute liefern wir einen Layer aus. Wir tun nicht so, als wären es mehr. Siehe /de/output-gate/.

6. Audit — slog und SQLite, SQL-abfragbar

Jeder Tool-Call wird aufgezeichnet: wer ihn aufgerufen hat, welches Tool, mit welchen Parametern, was das Ergebnis war, wie lange er gedauert hat und ob er erfolgreich war. ToolMesh liefert zwei Audit-Backends aus — Gos strukturiertes slog für log-orientierte Setups und einen Append-only-SQLite-Store für abfragbare Compliance-Audits.

Wenn jemand fragt „was hat dieser Agent letzten Dienstag zwischen 14:00 und 15:00 gemacht?”, ist die Antwort eine SELECT-Query — keine forensische Übung über fünf Log-Aggregatoren hinweg.

Die fail-closed Request-Pipeline

Die Säulen sind wichtig, aber ihr Wert entsteht durch die Reihenfolge, in der sie laufen. Ein einzelner Tool-Call läuft diesen Weg:

┌─────────────────────────────────────────────────────────────────┐
│  Client (Claude Desktop / ChatGPT / CLI / Hosted Agent)         │
└──────────────────────────────┬──────────────────────────────────┘
                               │
                               ▼
                  ┌───────────────────────┐
                  │ 1. Authentication     │   OAuth 2.1 PKCE / API-Key
                  │    → UserContext      │   → Identität feststeht
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 2. Authorization      │   OpenFGA: user × plan × tool
                  │    (fail closed)      │   → allowed oder DENY
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 3. Credential         │   Serverseitig aufgelöst,
                  │    Injection          │   nie an das Modell exponiert
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 4. Output Gate (in)   │   Optionaler Pre-Execution-Check
                  │    (fail closed)      │   → allowed oder REJECT
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 5. Execute            │   MCP-Server oder REST via DADL
                  │                       │   → Rohe Response
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 6. Output Gate (out)  │   PII-Redaktion, Shaping
                  │                       │   → Gefilterte Response
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 7. Audit              │   Append-only, abfragbar
                  │                       │   → SQLite / slog
                  └──────────┬────────────┘
                             ▼
                       Zurück an Client

Die Pipeline ist fail-closed: Lehnt AuthZ ab, läuft nichts. Lehnt das Gate ab, läuft nichts. Schlägt die Credential-Auflösung fehl, läuft nichts. Der Default bei jeder Unsicherheit ist „nicht ausführen”. Das ist die Umkehrung dessen, was die meisten Ad-hoc-Setups tun, wo ein fehlender Check stillschweigend „weiter” bedeutet.

CallerClass — die zweite Achse, die sonst niemand hat

Die meisten Gateways behandeln Autorisierung als eine einzige Achse: wer ist der Nutzer? Das ist notwendig, aber nicht hinreichend. Derselbe Nutzer, mit derselben Frage, läuft auf einem ganz anderen Vertrauensniveau, wenn er in eine lokale Claude-Desktop-Session tippt, im Vergleich dazu, wenn ein hosted Agent den Call in seinem Namen als Teil eines geplanten Workflows macht.

ToolMesh behandelt das als erstklassiges Konzept: CallerClass, an jeden Request angehängt, mit drei Werten:

CallerClass	Typischer Ursprung	Typische Filterung
`trusted`	Lokale CLI, Entwickler-Laptop	Minimal — nur Credentials werden redigiert
`standard`	Authentifizierter Nutzer über bekannten Client	PII-Redaktion, Schema-Shaping
`untrusted`	Hosted Agents, CI-Bots, Drittclients	Streng — keine Admin-Tools, aggressive Redaktion

CallerClass moduliert zwei Dinge gleichzeitig: welche Tools überhaupt erreichbar sind (ein untrusted-Aufrufer kann von admin-Tools ausgeschlossen werden, selbst wenn der Plan des Nutzers sie normalerweise zulassen würde) und was das Output Gate vor dem Modell redigiert. Dasselbe Backend, derselbe Nutzer, anderer Trust-Envelope — automatisch durchgesetzt.

Das ist der Teil, den es in Passthrough-Gateways nicht gibt. Sie modellieren den Nutzer. Sie modellieren nicht „wer fragt im Namen des Nutzers”. Für Agenten-Infrastruktur liegt das echte Risiko vor allem auf dieser zweiten Achse.

Beispiel aus der Praxis: ein Backend hinzufügen

Den list_issues-Endpunkt von GitHub als kontrolliertes Tool hinzuzufügen, sieht in voller Länge so aus:

# github.dadl
backend:
  name: github
  type: rest
  base_url: https://api.github.com

  auth:
    type: bearer
    credential: github_token       # zur Laufzeit aufgelöst, nie im Prompt

  defaults:
    errors:
      retry_on: [429, 502, 503]
      retry_strategy:
        max_retries: 3
        backoff: exponential

  tools:
    list_issues:
      method: GET
      path: /repos/{owner}/{repo}/issues
      access: read                  # → über OpenFGA auf Plan-Berechtigungen gemappt
      description: "List issues in a repository"
      params:
        owner:    { type: string, in: path,  required: true }
        repo:     { type: string, in: path,  required: true }
        state:    { type: string, in: query, default: open }
        per_page: { type: integer, in: query, default: 30 }
      pagination:
        strategy: link_header

Dreiundzwanzig Zeilen. Datei in die Registry legen, in backends.yaml referenzieren, neu starten. Was Sie kostenlos dazu bekommen:

Authentication — OAuth oder API-Key am Eingang, Bearer-Token-Injection auf der Outbound-Seite, beides von der Runtime erledigt.
Authorization — access: read ordnet das Tool im OpenFGA-Modell ein; der Request wird vor der Ausführung abgelehnt, wenn der Plan des Aufrufers ihn nicht enthält.
Credential-Isolation — github_token wird zur Ausführungszeit aus dem Credential Store geholt; das Modell sieht den Wert nie.
Retry und Pagination — in der Beschreibung deklariert, von der Runtime ausgeführt.
Audit — jeder Call landet im Audit-Store mit Aufrufer, Parametern, Status, Latenz.
Output-Filterung — das Gate läuft auf der Response, bevor das Modell sie sieht, und wendet die für die CallerClass passende Policy an.

Nichts davon ist Wrapper-Code, den jemand speziell für GitHub geschrieben hat. Das ist, was die Runtime für jedes per DADL beschriebene Tool tut. Dieselbe Governance um einen handgerollten MCP-Server zu bauen, sind mehrere hundert Zeilen Boilerplate pro Backend — Arbeit, die die meisten Teams ungebaut ausliefern und später bereuen.

Der Schwester-Artikel Stop Rebuilding REST API Wrappers for MCP geht tiefer auf das DADL-Format ein und darauf, was wegfällt, wenn man es einsetzt.

Warum der Kontext-Footprint konstant bleibt

Die meisten Gateways skalieren linear mit der Anzahl der Backends — jeder neue Server fügt Tool-Definitionen hinzu, die in jedem Prompt mitfahren. Zwanzig Backends, zwanzig Schema-Bundles, fünfzigtausend Tokens, bevor der Nutzer überhaupt ein Wort getippt hat.

Code Mode bricht diese Skalierung. Das Modell sieht discover_tools und execute_code sowie ein kompaktes TypeScript-Interface, das auflistet, was verfügbar ist. Ein zusätzliches Backend lässt die Interface-Beschreibung wachsen, aber nicht den Overhead pro Request — der Agent schlägt Tools bei Bedarf nach, statt sie permanent mitzuschleppen.

In der Praxis surft eine ToolMesh-Instanz vor der aktuellen öffentlichen DADL-Registry — 27 APIs, 3.338 einzelne Tools über GitHub, Cloudflare, GitLab, Stripe, Hetzner Cloud, Linode, NetBox, DeepL und andere — gegenüber dem Modell mit ungefähr denselben Kontext-Kosten wie ein einziger handgebauter MCP-Server mit einem Dutzend Tools. Genau dieses Verhältnis ist der ganze Punkt. Ohne es funktioniert die Library-Form überhaupt nicht.

Scope und Ehrlichkeit: ausgeliefert vs. geplant

ToolMesh ist Early Stage. Ein Teil der Architektur ist ausgeliefert, ein Teil ist in Bewegung. Das explizit zu benennen ist nützlicher als ambitionierte Behauptungen.

Heute ausgeliefert:

Alle sechs Säulen durch die fail-closed Pipeline verdrahtet
Authentication (OAuth 2.1 PKCE, API-Keys, Multi-User via users.yaml)
Authorization (OpenFGA, Modi bypass / restrict)
Credential Store mit eingebettetem Env-Var-Backend
Output Gate Layer 1 (deterministische goja-JS-Policies)
Audit via slog und SQLite
MCP- und DADL-Backends, Registry-basiert
Code Mode mit AST-extrahierten Tool-Calls

Bewusste Entwickler-Defaults — für Produktion umschalten:

OPENFGA_MODE=bypass (keine Autorisierung)
Debug-Logging an
HTTP+TLS-Reverse-Proxy davor angenommen für TLS-Terminierung

Diese Defaults sorgen dafür, dass docker compose up sauber in der Entwicklung läuft. Sie sind als nicht-produktionsreif dokumentiert. Die Seite Configuration listet jede Variable und ihre Produktions-Empfehlung auf.

Geplant, registriert, aber noch nicht ausgeliefert:

Infisical- und HashiCorp-Vault-Credential-Backends (Erweiterungspunkt existiert)
Weitere Gate-Layer (LLM-basierte Klassifikation, Compliance-Filter)
Erweiterte DADL-Registry-Abdeckung (Community-Beiträge willkommen)

Diese als „geplant” zu bezeichnen ist das richtige Maß an Selbstvertrauen. Die Registrierungs-Mechanik steht; die Arbeit, sie anzubinden, liegt vor uns.

Backends in der Praxis

Dieser Artikel ist die architektonische Referenz. Die detaillierten Connector-Walkthroughs — wie man NetBox aus Cloud-APIs befüllt, wie man OPNsense hinter eine Tool-Schicht setzt, wie man den HashiCorp-Stack integriert — leben in eigenen Beiträgen. Die aktuellen Folgen:

Populating NetBox from Real Infrastructure with ToolMesh
Weitere folgen zu OPNsense, der HashiCorp-Suite und weiteren registry-getriebenen Integrationen

Wer Infrastruktur betreibt, die ein gutes Worked Example abgäbe, beginnt am besten in der DADL-Registry — die meisten APIs mit OpenAPI-Spec können an einem Nachmittag zu DADL-Dateien werden.

Ausprobieren

Der schnellste Weg von diesem Artikel zu einer laufenden Instanz:

Hosted Demo. Try the Demo — ein gemanagtes ToolMesh mit einem kuratierten Backend-Set, kein Setup.
Self-Host-Quickstart. Repo klonen, docker compose up, MCP-Client auf http://localhost:8080 zeigen lassen. Der vollständige Walkthrough liegt unter Getting Started.

Eine Enterprise Tool Library ist keine Bibliothek von Tools. Sie ist die Schicht darunter, die „any backend” zu einer Eigenschaft der Runtime macht, statt zu einer Eigenschaft jedes einzelnen Wrappers. Die sechs Säulen, die fail-closed Pipeline und die CallerClass-Achse sind das, was einen Haufen MCP-Server in etwas verwandelt, das ein Unternehmen tatsächlich betreiben kann.

DeepL v3 Customization Hub — in einer DADL abgedeckt

Fri, 22 May 2026 00:00:00 GMT

Ende Mai hat DeepL den Customization Hub scharfgeschaltet — 13 neue REST-Endpoints für Style Rules, mehrsprachige Glossare, Translation Memory, die neu gestaltete /v3/languages-Ressource und einen optionalen tag_handling v2 Algorithmus. An dem Morgen, an dem wir unsere DADL dafür gemergt haben, exponierte der offizielle deepl-mcp-server immer noch neun Tools — alle v2 — und die Community-Alternative mcp-deepl war im gleichen Stand, zuletzt released am 2026-05-09. Nicht, weil irgendjemand langsam wäre. Die Arbeitseinheit für API-Coverage ist auf beiden Seiten dieser Linie grundlegend verschieden, und das neue Release legt die Lücke deutlich offen. Dieser Post ist das Build-Log.

Was das neue Release gebracht hat

Customization Hub ist der Marketing-Name für eine ehrliche API-Erweiterung. DeepL erlaubt API-Konsumenten jetzt sprachspezifische Style-Profile (etwa “Brand voice — DE”), mehrsprachige Glossare (ein Glossar, viele source → target-Wörterbücher) und Translation Memories (Wiederverwendung auf Segment-Ebene mit konfigurierbarem Match-Threshold) zu verwalten. /v2/translate akzeptiert drei neue Parameter — style_id, custom_instructions, translation_memory_id — und jeder davon hebt das Modell stillschweigend auf quality_optimized. Der neue /v3/languages-Endpoint ersetzt das alte /v2/languages und exponiert ressourcenbezogene Feature-Flags (Formality-Support, Glossary-Support, Style-Rules-Support, Voice). Schließlich liefert tag_handling_version: v2 einen deutlich verbesserten Algorithmus zur HTML/XML-Strukturerhaltung — positionsunabhängige Übersetzung, besser erhaltenes Nesting.

Das ist eine substanzielle Erweiterung. Nichts davon steckt heute im offiziellen MCP-Server.

Die Zahlen

	DADL (`deepl.dadl`)	`deepl-mcp-server` (offiziell)
Tools	27	9
Coverage	Textübersetzung, Dokumentübersetzung, mehrsprachige v3-Glossare, Style Rules CRUD, Custom Instructions CRUD, TM-Listing, Write/Rephrase, `/v3/languages`, Usage	translate-text, rephrase-text, translate-document, list-glossaries, get-glossary-info, get-glossary-dictionary-entries, get-source-languages, get-target-languages, get-writing-styles
Verteilung	38 KB YAML	Node.js-Server (TypeScript SDK, Build-Schritt, Runtime zum Hosten)
Neuen Endpoint hinzufügen	~30 Zeilen YAML	Tool-Definition + Request-Handler + Tests + Release
v3 Customization Hub Coverage	vollständig	heute keine

Die lokale Validierung, ausgeführt aus dem Registry-Checkout:

> cd dadl-registry && npm run validate
✅ deepl.dadl — 27 tools

Source auf GitHub: dadl-registry/deepl.dadl. Gemergt in PR #34. Die DADL-Spec selbst: dadl.ai/spec.

Ein durchgespieltes Beispiel: Style Rules end-to-end

Das Interessante an Style Rules ist, dass sie tatsächlich greifen — custom_instructions schlagen sich im Modell-Output nieder. Hier der Round-Trip:

const style = await toolmesh.deepl_create_style_rule({
  name: "Brand voice — DE",
  language: "de",
  custom_instructions: [
    { label: "Greeting",     prompt: "Begin every translation with 'Sehr geehrte Damen und Herren'." },
    { label: "Product term", prompt: "Render 'ToolMesh' verbatim, never translate." }
  ]
});

const r = await toolmesh.deepl_translate({
  text: ["The deployment of ToolMesh was successful."],
  source_lang: "EN", target_lang: "DE",
  style_id: style.style_id
});
// → "Sehr geehrte Damen und Herren, die Bereitstellung von ToolMesh war erfolgreich."

Zwei Calls. Kein Glue-Code. Der erste trifft POST /v3/style_rules; der zweite referenziert das Ergebnis per style_id in POST /v2/translate. Die DADL behandelt transparent:

das ungewöhnliche DeepL-Auth-Key-Authorization-Schema (Custom-Prefix, serverseitige Credential-Injection — das Modell sieht den Key nie);
die Casing-Falle bei Sprachcodes (UPPERCASE für translate, lowercase für Style Rules — beides korrekt typisiert);
den stillen Model-Switch — style_id, custom_instructions oder translation_memory_id zu übergeben kippt model_type auf quality_optimized;
Retries auf 429 / 529 mit Retry-After und terminale Klassifizierung für 400/401/403/456 (der Free-Plan-Quota-Code ist 456, nicht 429 — ein Footgun in handgeschriebenen Clients).

Derselbe Call aus Claude oder einem beliebigen anderen Agenten. Kein DeepL-spezifischer Code auf der Client-Seite.

Asymmetrie in der Wartung

Das ist der Teil, der nicht im Tool-Count auftaucht, aber bestimmt, wie schnell eine Integration einer Upstream-API folgt.

Die v3-Endpoints zur DADL hinzufügen:

deepl.dadl öffnen.
Die neuen Tool-Blöcke ergänzen (~30 Zeilen YAML pro Endpoint).
npm run validate — Output ist ✅ deepl.dadl — 27 tools.
Einen PR aufmachen. Den YAML-Diff reviewen. Mergen.
ToolMesh zieht die neuen Tools beim nächsten Reload. Nutzer sehen sie.

Dieselben Endpoints zu einem handgeschriebenen MCP-Server hinzufügen:

Das TypeScript SDK aktualisieren, um die neuen Request- und Response-Shapes abzubilden.
Tool-Definitionen und Request-Handler hinzufügen (einer pro Endpoint).
Tests schreiben oder erweitern.
Release schneiden. Taggen. Auf npm publizieren.
Nutzern sagen, dass sie upgraden sollen. Auf sie warten.
Für das Python-SDK wiederholen, falls man eines pflegt. Für etwaige Downstream-Forks wiederholen.

DADL kollabiert die Schritte 1, 2, 4, 5 und 6 zu “eine YAML-Datei editieren.” Der PR-Diff ist ein reviewbares Change-Set, kein Software-Release. Wir haben die allgemeine Version dieses Arguments in einem früheren Post gemacht; das DeepL-Release ist die konkrete Fallstudie.

Die Kehrseite, die ausgesprochen gehört: Wenn man Verhalten braucht, das die Runtime nicht unterstützt, rettet einen die YAML-Datei nicht. DADL ist deklarativ — es gibt keinen Escape-Hatch für Custom-Orchestration. Im DeepL-Fall ist der Dokumentübersetzungs-Flow (upload_document → check_document_status → download_document) rein sequenzielles REST und passt sauber. Eine protokoll-ebene Abweichung — etwa die WebSocket Voice API — würde es nicht.

Das Context-Window-Argument

Der andere Grund, warum der Tool-Count weniger zählt, als es aussieht: Code Mode. Statt jede vollständige Tool-Liste aller Backends ins Context-Window des Modells zu injizieren, exponiert ToolMesh zwei Meta-Tools (list_tools und execute_code). Das Modell findet on demand heraus, was verfügbar ist, und ruft flache Tool-Namen aus einer sandboxed JavaScript-Runtime auf — toolmesh.deepl_translate, toolmesh.deepl_create_style_rule, nicht toolmesh.deepl.translate.

Die Token-Kosten sind im Wesentlichen konstant: ~1 k Tokens Meta-Tool-Beschreibung, egal ob die Registry ein Backend mit 9 Tools oder 27 Backends mit 3.338 enthält. Tool-Count-getriebener Bloat verschwindet. Den v3 Customization Hub hinzuzufügen hat die DADL von 14 auf 27 Tools gebracht und null Tokens zu jeder Claude-Konversation hinzugefügt, die DeepL nicht aktiv anfasst.

Im Code Mode ist das JavaScript im obigen Beispiel keine Illustration — es ist buchstäblich das, was das Modell schreibt, um die Tools aufzurufen. Deshalb liest es sich wie JavaScript und nicht wie JSON-Tool-Call-Payloads.

Ehrliche Einschränkungen

Die DADL ist kein vollständiger Coverage-Ersatz. Echte Limits:

Voice-Übersetzung ist WebSocket-basiert. DeepLs Echtzeit-Voice-Übersetzung ist ein bidirektionales Streaming-Protokoll. DADL beschreibt REST-APIs deklarativ; sie beschreibt keine Streaming-Protokolle. Dieser Endpoint ist nicht in unseren 27 Tools enthalten und wird es auch nicht — das ist Custom-Server-Terrain.
Die Admin-API ist bewusst out-of-scope. DeepL exponiert Admin-Endpoints (Org-Analytics, Developer-Key-Management). Wir haben diese DADL absichtlich auf nutzerseitige Übersetzungsoberflächen begrenzt. Admin-Endpoints haben ein anderes Bedrohungsmodell und gehören in ein separates, höher privilegiertes Backend — nicht ins selbe Paket wie das tägliche translate-Tool, das jedes Teammitglied benutzen könnte.
Translation-Memory-Mutationen gehen nur über die Web-UI. /v3/translation_memories ist über die API per Mai 2026 nur lesbar — TMs werden in der DeepL Web-UI angelegt und editiert. Wir exponieren list_translation_memories; wir können keine Endpoints exponieren, die nicht existieren.
Stateful MCP-Clients sind ein legitimer Use-Case. Wer Claude Desktop, Cursor oder Continue direkt fährt und einen lokalen MCP-Server ohne Governance-Layer dazwischen will, für den ist der offizielle deepl-mcp-server die richtige Form. Der DADL-via-ToolMesh-Ansatz setzt eine Runtime voraus, die Credentials, Authorization und Audit zentralisiert — und jemanden, der sie hosten will. Für einen einzelnen Entwickler ohne Governance-Anforderungen ist das Overhead, kein Wert.
Latenzkritische Pipelines. Jeder Call geht durch ToolMesh. Bei interaktiver Übersetzung auf menschlichen Latenzen ist das unsichtbar; bei Batch-Pipelines mit hohem Durchsatz ist der direkte Aufruf der DeepL-Client-Library wahrscheinlich schneller.

DADL ist gut in genau einer Sache — REST-API-Oberfläche schnell für Agenten verfügbar machen, mit einer echten Control-Layer darunter. Es ist keine Silver Bullet und versucht nicht, jede Art von MCP-Server zu ersetzen.

Was tatsächlich anders ist

Die substanzielle Frage ist nicht “DADL vs MCP-Server” — dieses Framing ist falsch; ToolMesh fährt beides, und sie koexistieren in derselben Registry. Die substanzielle Frage ist: Was kostet es, einem Upstream-API-Release zu folgen?

Für einen handgeschriebenen Server kostet es einen Engineering-Zyklus: SDK-Änderungen, Tool-Definitionen, Handler, Tests, ein Release, ein npm-Publish, Nutzer-Upgrades. Deshalb hinken Community-MCP-Server schnellbewegten APIs typischerweise hinterher — nicht aus mangelndem Einsatz, sondern weil die Arbeit linear in Software-Releases ist, nicht in YAML-Zeilen.

Für eine DADL kostet es einen PR mit einem YAML-Diff. DeepL hat Mitte Mai 13 neue Endpoints ausgeliefert. Wir haben die aktualisierte DADL am 21. Mai ausgeliefert — 14 alte Tools plus die 13 neuen, validiert, gemergt, live. Die Arbeit für die neuen Endpoints waren ein paar Stunden, der meiste Teil davon Lesen in DeepLs API-Referenz und Verhaltensverifikation gegen einen Free-Key. Den Rest hat die Runtime erledigt.

Das ist die Asymmetrie. Nicht “alle sollten MCP-Server fallenlassen.” Nicht “DADL ist universell besser.” Nur: Wenn die Arbeitseinheit für API-Coverage ein YAML-Diff statt eines Software-Releases ist, folgt die Integration der Upstream-API schneller. Das zählt, wenn der Upstream einen Customization Hub ausliefert.

→ Für die deutsche Geschäfts-Perspektive: dunkel.cloud/de/blog/deepl-customization-hub-via-dadl

NetBox aus realer Infrastruktur befüllen mit ToolMesh

Thu, 16 Apr 2026 00:00:00 GMT

Ein typisches Szenario: drei Cloud-Provider, zwei Hypervisoren, eine Handvoll Edge-Standorte. Irgendwo um die 200 Geräte und VMs, Pi mal Daumen. Man startet NetBox, starrt auf das leere Dashboard und merkt, dass die eigentliche Arbeit noch nicht angefangen hat. Import-Skripte für fünf verschiedene APIs zu schreiben, ist eine Woche Arbeit, die niemand machen will — also bleibt NetBox leer, und die Tabellenkalkulation gewinnt wieder.

Dieser Beitrag zeigt, wie man sich diese Woche spart. Wir gehen durch, wie man mit ToolMesh Live-Infrastrukturdaten aus mehreren Quellen abruft und über den NetBox-DADL-Konnektor in NetBox schreibt. Für den Business Case und das breitere „Warum” lies den Schwester-Artikel auf dunkel.cloud. Hier geht es um das „Wie”.

Architektur-Überblick

Der Datenfluss:

Hetzner Cloud ───┐
Linode        ───┤
Xen Orchestra ───┼── ToolMesh ── NetBox DADL ── NetBox API
Unifi         ───┤
Tailscale     ───┘

Jedes Quellsystem hat seine eigene API, seine eigene Authentifizierung und sein eigenes Datenmodell. ToolMesh fungiert als Gateway: Es authentifiziert sich gegen jede Quelle mit hinterlegten Credentials, normalisiert die Antworten und schreibt die Ergebnisse über die NetBox-DADL-Definition in NetBox.

DADL (Declarative API Definition Language) ist ein YAML-basiertes Format, das REST-APIs als Tool-Definitionen beschreibt. Statt für jede API einen eigenen MCP-Server-Wrapper zu schreiben, beschreibt man Endpoints, Parameter und Authentifizierung in einer einzigen Datei. ToolMesh verwandelt diese Beschreibung zur Laufzeit in aufrufbare Tools — und erledigt Credential-Injection, Autorisierung und Audit-Logging automatisch. Die NetBox-DADL deckt den Großteil der NetBox-REST-API ab; jede Quell-DADL deckt eine Cloud oder Appliance ab. Dazwischen sitzt kein eigener Glue-Code.

Mapping: Quellobjekte auf NetBox-Objekte

Die Kernaufgabe ist die Übersetzung zwischen Datenmodellen. Ein Hetzner-„Server” wird zu einem NetBox-„Device”. Eine Linode-„Instance” wird ebenfalls zu einem Device, aber die Feldnamen unterscheiden sich. So sieht das Mapping der wichtigsten Objekte aus:

Quelle	Quellobjekt	NetBox-Objekt	Schlüsselfelder
Hetzner Cloud	Server	Device	name, server_type → device_type, datacenter → site
Hetzner Cloud	Network	Prefix	ip_range → prefix, name → description
Linode	Instance	Device	label → name, type → device_type, region → site
Linode	IPv4/IPv6	IP Address	address → address, linode_id → zugewiesenes Device
Xen Orchestra	VM	Virtual Machine	name_label → name, power_state → status
Xen Orchestra	Network	VLAN	name_label → name, MTU
Unifi	Device	Device	name, model → device_type, site → site
Tailscale	Node	Device	hostname → name, addresses → IP Addresses

Konkret sieht ein einzelner Hetzner-Server in der Antwort so aus:

{
  "id": 42891337,
  "name": "web-fra-01",
  "server_type": { "name": "cx22", "cores": 2, "memory": 4 },
  "datacenter": { "name": "fsn1-dc14", "location": { "name": "fsn1" } },
  "public_net": { "ipv4": { "ip": "95.217.xx.xx" } },
  "status": "running"
}

Nachdem ToolMesh das Objekt durch die NetBox-DADL geschickt hat, erzeugt dieses eine Quellobjekt drei verknüpfte NetBox-Records: eine Site (fsn1), einen DeviceType (cx22, 2 Cores, 4 GB) und ein Device (web-fra-01) mit angehängter primärer IP. Site und DeviceType werden einmal angelegt und bei jedem weiteren Hetzner-Server im selben Rechenzentrum wiederverwendet.

Mappings sind nicht hartcodiert. Die Logik für die Feldübersetzung lebt in der Orchestrierungsschicht zwischen Quell-DADL und NetBox-DADL. Mappings lassen sich überschreiben, eigene Felder hinzufügen oder Objekte komplett überspringen — wenn die Server eine Rolle im Hostnamen kodieren (web-fra-01, db-fra-02), setzt eine kleine Transformation das device_role entsprechend. Abhängigkeiten werden automatisch aufgelöst: Voraussetzungs-Objekte werden vor dem Haupt-Record angelegt.

Das Trust-Escalation-Modell

Cloud-Inventar blind in eine produktive NetBox zu synchronisieren, ist zu Recht etwas, wovor man Respekt haben sollte. Der empfohlene Ansatz ist graduelles Vertrauen — mit null Risiko starten und mit wachsender Sicherheit eskalieren. Nichts davon ist ein eigens gebautes CLI; alles läuft als Prompt in natürlicher Sprache an Claude (oder einen beliebigen Agenten) mit angebundenem ToolMesh. Die folgenden Beispiele sind die tatsächlich verwendeten Prompts.

Phase 1: Initial-Import (leere Datenbank). Bevor Devices angelegt werden können, braucht NetBox ein minimales Grundgerüst: mindestens eine Site (Devices müssen einer zugeordnet sein), einen Manufacturer für Device Types und idealerweise einen Tenant zur organisatorischen Gruppierung. Man füttert Claude mit den Fakten zur eigenen Infrastruktur und lässt es einrichten:

Richte NetBox für meine Firma ein. Unser Tenant ist „Acme GmbH”. Ich betreibe Infrastruktur in zwei Regionen: Linode Frankfurt (eu-central) und Linode Amsterdam (nl-ams) — leg die als Sites unter einer Region namens „Europe” an. Der Manufacturer für alle Linode-Instanzen ist „Akamai/Linode”. Sobald das steht, importiere alle meine Linode-Instanzen als Devices, leg die passenden Device Types (g6-standard-2, g6-standard-4 usw.) direkt mit an und häng die öffentlichen IPv4- und IPv6-Adressen dran. NetBox ist leer, also kein Dry-Run nötig — mach es einfach und zeig mir am Ende eine Zusammenfassung.

Claude ruft die Linode-Tools auf, um Instanzen zu listen, und die NetBox-Tools, um Sites, Tenant, Manufacturer, Device Types, Devices und IPs in der richtigen Reihenfolge anzulegen. Die Zusammenfassung am Ende sagt, wie viele von jedem Objekttyp angelegt wurden.

Phase 2: Read-only-Diff. Sobald NetBox Daten enthält, fragt der nächste Check, was sich ändern würde, ohne irgendetwas anzufassen:

Vergleiche meine aktuellen Linode-Instanzen mit dem, was in NetBox steht. Ändere nichts — sag mir nur in einfachen Worten, was die Unterschiede sind.

Die Antwort ist Prosa, kein Maschinen-Diff:

Ich habe 23 Linode-Instanzen mit den 22 Devices in NetBox verglichen, die mit source=linode getaggt sind. Vier Unterschiede:

Neue Instanz: db-ams-04 existiert bei Linode (Region nl-ams, Typ g6-standard-4, gestern angelegt), ist aber noch nicht in NetBox.

IP-Änderung: web-ams-01 hat in NetBox eine primäre IPv4 (172.104.x.12), Linode meldet jetzt aber 172.104.x.47. Sieht nach einem Rebuild aus.

Status-Drift: worker-ams-03 ist in NetBox als active markiert, Linode meldet ihn aber als offline (vor 6 Tagen heruntergefahren).

Fehlt an der Quelle: legacy-bastion-ams existiert in NetBox, ist bei Linode aber nicht mehr vorhanden. Wahrscheinlich außer Betrieb genommen — vor dem Anfassen lieber bestätigen lassen.

Soll ich 1–3 anwenden und 4 zur Prüfung markieren?

An dieser Stelle wird der größte Teil des Vertrauens aufgebaut. Man sieht genau, was passieren würde, in einer Sprache, die man auf einen Blick auditieren kann.

Phase 3: Reconcile mit Bestätigung. Änderungen werden angewendet, mit einem Menschen in der Schleife bei allem Destruktiven:

Mach mit 1, 2 und 3 weiter. Für alles, was ein Device löscht oder als außer Betrieb markiert, frag mich vorher.

Anlegen und Updates passieren direkt; die Legacy-Bastion löst eine Rückfrage aus („Soll legacy-bastion-ams aus NetBox gelöscht oder auf decommissioning gesetzt und der Record behalten werden? [delete / decommission / skip]”), bevor etwas Unwiderrufliches geschieht. Destruktive Operationen erfordern immer eine explizite Bestätigung, auch wenn der Workflow später automatisiert läuft.

Phase 4: Geplanter Sync. Sobald das Mapping vertrauenswürdig ist, übergibt man den Workflow an einen geplanten Agenten:

Hol jede Stunde den aktuellen Linode-Stand und gleich ihn mit NetBox ab. Neue Einträge und Feld-Updates wend direkt an. Für alles, was ein Device löschen oder seinen Status auf decommissioned setzen würde, öffne stattdessen ein Ticket in unserem Tracker — das prüfe ich manuell.

ToolMesh führt den Prompt nach Zeitplan aus, der Agent macht dieselbe Arbeit wie im interaktiven Lauf, und destruktive Aktionen bleiben hinter einer Freigabe durch einen Menschen. Neue Server tauchen Minuten nach dem Provisionieren in NetBox auf. Jeder Tool-Call landet im Audit-Log, sodass sich später jederzeit nachvollziehen lässt, was geändert wurde, wann und warum.

Wie es weitergeht

Der NetBox-DADL-Konnektor deckt den Großteil der NetBox-4.x-REST-API ab. Quell-Konnektoren für Hetzner Cloud, Linode, Xen Orchestra, Unifi und Tailscale sind heute verfügbar. Falls die eigene Infrastruktur noch nicht abgedeckt ist, ist eine neue DADL-Datei eine Sache von Minuten, nicht Tagen — die DADL Registry auf bestehende Definitionen prüfen oder selbst auf GitHub beitragen.

Der eigentliche Gewinn kommt nach dem Import. Eine befüllte NetBox ist nicht nur Dokumentation — sie wird zum Substrat, über das ein KI-Agent argumentieren kann. „Welche Server in Falkenstein laufen auf Kernel 5.x und brauchen nächsten Dienstag ein Reboot-Fenster?” ist eine NetBox-Abfrage plus ein ToolMesh-Tool-Call, keine Woche Shell-Skripte. Genau deshalb starten wir hier: NetBox ist die Karte, ToolMesh ist die Art, wie Agenten sie sicher lesen und neu zeichnen.

Für die strategische Sicht lies die vollständige Analyse auf dunkel.cloud.

ToolMesh — die fehlende Kontrollschicht für KI-Agenten

Tue, 07 Apr 2026 00:00:00 GMT

KI-Agenten erreichen Produktivsysteme schneller, als Security und Governance hinterherkommen. Teams verbinden Agenten mit CRMs, Cloud-APIs, internen Datenbanken, Ticketsystemen und IoT-Geräten — aber die Infrastruktur zwischen Agent und Zielsystem hält sich nur mit Umgebungsvariablen und guten Vorsätzen zusammen.

Das typische Setup sieht so aus: Ein MCP-Server hat direkten Zugriff auf API-Keys, jeder angebundene Agent erhält vollen Zugriff auf jedes Tool, und es existiert keinerlei Aufzeichnung darüber, was wann und von wem aufgerufen wurde. Für einen Prototyp reicht das. Für einen Agenten, der in derselben Session mit Stripe, dem HR-System und dem Cloud-Provider spricht, reicht es nicht.

Im Unternehmenskontext verstärkt sich das Problem. Organisationen betreiben Dutzende Backend-Systeme über Teams und Abteilungen hinweg. Jedes braucht seine eigene Integration, seine eigenen Credentials, seine eigene Access-Policy. Ohne zentrale Kontrollschicht ist jede neue Agenten-Anbindung eine neue, unauditierte Vertrauensbeziehung — und die Angriffsfläche wächst mit jeder einzelnen.

ToolMesh ist unsere Antwort auf diese Lücke.

Was ToolMesh ist

ToolMesh ist die fehlende Kontrollschicht zwischen KI-Agenten und Unternehmenssystemen. Es sitzt zwischen KI-Agenten und Backend-Systemen und verwandelt unkontrollierte Tool-Calls in einen gesteuerten, auditierbaren Prozess — und bindet jede REST-API oder jeden MCP-Server in Minuten statt Monaten an.

Jeder Tool-Call durchläuft eine strikte Pipeline: Auth → AuthZ → Credential Injection → Execution → Output Gate → Audit. Wenn ein Schritt den Request nicht explizit zulässt, passiert nichts. Das Modell sieht niemals rohe Secrets. Jeder Call wird protokolliert. Outputs können gefiltert werden, bevor sie den Agenten erreichen.

Es läuft als einzelnes Binary oder Docker-Container. Es ist Apache-2.0-lizenziert. Es gibt keine SaaS-Abhängigkeit.

Die sechs Säulen

ToolMesh ist um sechs Belange herum aufgebaut, die die meisten Agenten-Setups inkonsistent oder gar nicht behandeln.

1. Authentication

ToolMesh unterstützt OAuth 2.1 mit PKCE für interaktive Clients wie Claude Desktop, API-Keys für programmatischen Zugriff und Multi-User-Setups über eine users.yaml-Konfiguration. Jeder Request wird authentifiziert, bevor er in die Pipeline eintritt.

Für einen schnellen Start genügt eine einzige Umgebungsvariable. Für die Produktion erhält man User-Identitäten mit Rollen, Plänen und Company-Kontext — ohne die Architektur zu ändern.

2. Authorization

Zugriffskontrolle erfolgt pro Tool und pro User, betrieben von OpenFGA. DADL-Tools deklarieren ein access-Level — read, write, admin oder dangerous — und Policy-Dateien bilden diese Levels auf Rollen ab. Ist der Aufrufer für das konkrete Tool nicht autorisiert, wird der Request vor der Ausführung abgelehnt.

ToolMesh verfolgt zusätzlich die CallerClass: welcher KI-Client den Request ausgelöst hat. Eine lokale Claude-Code-Session kann andere Berechtigungen haben als ein gehosteter Agent oder ein CI-Bot, die dieselbe API ansprechen. Gleiches Backend, unterschiedliche Vertrauensstufen, automatisch durchgesetzt.

3. Credential Store

Das ist der Aspekt, den die meisten Setups stillschweigend ignorieren. In einer typischen MCP-Konfiguration liegen API-Keys in Client-Configs oder Umgebungsvariablen — für das Modell sichtbar, über Maschinen verstreut, zentral nicht rotierbar.

ToolMesh injiziert Credentials zur Laufzeit, serverseitig. Das Modell sieht das Tool-Interface und das gefilterte Ergebnis. Es sieht nie das Token, den Key oder das Session-Cookie. Credentials werden in der DADL-Datei per Name referenziert und zur Ausführungszeit aus dem Credential Store aufgelöst.

Der Default-Store liest aus Umgebungsvariablen. Die Architektur unterstützt austauschbare Backends für zentralisiertes Secret-Management (geplant: Infisical, HashiCorp Vault).

4. Output Gate

Nicht jede API-Antwort sollte das Modell unverändert erreichen. Kundendatensätze können PII enthalten. Interne Systeme können Metadaten zurückgeben, die irrelevant oder sensibel sind. Fehlermeldungen können Infrastrukturdetails preisgeben.

Das Output Gate führt JavaScript-Policies aus (über die goja-Engine), die Inputs vor der Ausführung validieren und Outputs anschließend filtern können. Anwendungsfälle reichen von PII-Redaktion über Compliance-Filterung bis hin zur kompletten Ablehnung gefährlicher Inputs. Policies sind überprüfbarer Code, keine Black Boxes.

5. Execution

ToolMesh verbindet zwei Arten von Backends:

DADL-Backends beschreiben REST-APIs deklarativ in YAML. Eine .dadl-Datei definiert Endpoints, Parameter, Authentifizierung, Error-Handling, Pagination und Retry-Logik. ToolMesh verwandelt diese Beschreibung zur Laufzeit in MCP-Tools — kein eigener Server-Code nötig. Die öffentliche DADL-Registry enthält derzeit Definitionen für 27 APIs mit 3.338 Tools für Provider wie GitHub, Cloudflare, GitLab, Stripe, DeepL, Hetzner Cloud und andere.

MCP-Server-Backends binden bestehende MCP-Server über HTTP- oder STDIO-Transport an. Wer bereits einen funktionierenden MCP-Server hat, lässt ihn von ToolMesh in dieselbe Authorization-, Credential- und Audit-Pipeline einhüllen.

Beide Typen durchlaufen dieselbe Fail-closed-Pipeline. Der Backend-Typ ist ein Implementierungsdetail — die Sicherheitsgarantien sind dieselben.

6. Audit Trail

Jeder Tool-Call wird aufgezeichnet: wer ihn aufgerufen hat, welches Tool, mit welchen Parametern, was das Ergebnis war, wie lange er gedauert hat und ob er erfolgreich war. ToolMesh bringt zwei Audit-Backends mit — strukturiertes Logging über slog für einfache Setups und einen append-only SQLite-Store für abfragbare Compliance-Audits.

Wenn jemand fragt „Was hat dieser Agent letzten Dienstag eigentlich gemacht?”, lässt sich das mit einer SQL-Query beantworten statt mit einem Schulterzucken.

DADL: deklarieren statt programmieren

Das Integrationsproblem im Agenten-Tooling ist nicht das Protokoll. Das hat MCP gelöst. Das Problem ist, dass jede neue API immer noch einen neuen MCP-Server erfordert — eine neue Codebasis, eine neue Runtime, eine neue Wartungslast. Die meisten Teams stoppen nach einer Handvoll Integrationen, weil die Kosten pro API zu hoch sind.

DADL (Declarative API Description Language) verfolgt einen anderen Ansatz. Statt für jede API einen eigenen Server zu schreiben, beschreibt man die API in YAML:

backend:
  name: deepl
  type: rest
  base_url: https://api.deepl.com/v2

  auth:
    type: bearer
    credential: deepl_auth_key

  tools:
    translate:
      method: POST
      path: /translate
      access: write
      description: "Translate text into a target language"
      params:
        text: { type: array, in: body, required: true }
        target_lang: { type: string, in: body, required: true }

Das ist eine vollständige Tool-Definition. ToolMesh übernimmt zur Laufzeit Authentifizierung, Parameter-Mapping, Error-Handling, Retries und Credential-Injection.

Weil DADL kompakt und deklarativ ist, können LLMs aus bestehender API-Dokumentation funktionierende Definitionen generieren. Die meisten der frühen Definitionen in der Registry wurden von Claude in unter einer Minute aus API-Docs erzeugt und anschließend reviewt und nachjustiert. Das Format ist AI-nativ gedacht: leicht für Maschinen zu produzieren, leicht für Menschen zu reviewen.

Dazu haben wir einen eigenen Deep Dive geschrieben: Stop Rebuilding REST API Wrappers for MCP.

Code Mode: Skalierung, die sonst nicht funktioniert

15 MCP-Server mit einem einzigen KI-Agenten verbinden? Ohne ToolMesh funktioniert das schlicht nicht — das Kontextfenster läuft voll, der Client streikt. Mit ToolMesh ist es kein Problem.

Statt Hunderte einzelner MCP-Tools zu exponieren, exponiert ToolMesh zwei Meta-Tools: list_tools und execute_code. Das Modell erhält eine kompakte TypeScript-Interface-Beschreibung (~1.000 Tokens statt 50.000+) und schreibt JavaScript dagegen. Ein einzelner Codeblock kann mehrere API-Calls in einem einzigen Roundtrip verketten.

Das ist der Unterschied zwischen „funktioniert nicht” und „läuft einfach”.

Self-hosted, Open Source

ToolMesh ist Apache-2.0-lizenziert. Das Binary ist self-contained — keine externen Abhängigkeiten für den Core-Funktionsumfang. docker compose up liefert eine laufende Instanz mit OAuth, Audit-Logging und einer Auswahl an DADL-Backends.

Es gibt keine Cloud-Abhängigkeit. Deine Credentials, deine Audit-Logs, deine Policies — alles auf eigener Infrastruktur. Der Core ist Open Source und bleibt es.

Loslegen

Der schnellste Weg von null zu einem funktionierenden Setup:

Repo klonen und docker compose up ausführen
MCP-Client so konfigurieren, dass er auf ToolMesh zeigt
Den ersten Tool-Call absetzen

Der Getting-Started-Guide führt das im Detail durch. Die Architektur-Übersicht erklärt, wie die Pipeline arbeitet. Die DADL-Registry enthält gebrauchsfertige Definitionen für 27 APIs.

ToolMesh liegt auf GitHub. Issues, Feedback und DADL-Beiträge sind willkommen.

Hört auf, REST-API-Wrapper für MCP nachzubauen

Fri, 03 Apr 2026 00:00:00 GMT

Jeder REST-zu-MCP-Wrapper beginnt gleich. Man sucht sich eine API aus, öffnet die Doku und fängt an, Glue-Code zu schreiben. Authentifizierung, Parameter-Mapping, Error-Handling, Pagination, Retries, Response-Aufbereitung. Zweihundert Zeilen später hat man eine Integration. Dann fängt man bei der nächsten API von vorn an.

Die eigentlichen Kosten sind nicht die 200 Zeilen. Es ist die Tatsache, dass man Execution Policy — Credential-Handling, Zugriffskontrolle, Audit Logging — um jeden einzelnen Wrapper herum neu implementiert. Diese Arbeit ist teuer, repetitiv und schwer zu skalieren.

DADL geht einen anderen Weg: Statt für jede REST-API einen eigenen Wrapper zu schreiben, beschreibt man die API deklarativ. ToolMesh verwandelt diese Beschreibung in Tools und übernimmt die Laufzeitbelange — auch die, die die meisten Wrapper stillschweigend ignorieren: Credential-Isolation, Autorisierung und Audit Logging.

Der Wrapper, den man immer wieder neu baut

Hier ist ein minimaler MCP-Server für einen einzelnen DeepL-Übersetzungs-Endpoint in TypeScript. Auf das Nötigste reduziert — keine Tests, keine Retries, keine Pagination, kein Rate Limiting:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

const API_KEY = process.env.DEEPL_API_KEY;
if (!API_KEY) throw new Error("DEEPL_API_KEY required");

const server = new Server(
  { name: "deepl-mcp", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "translate",
      description:
        "Translate text into a target language. " +
        "Supports up to 50 texts per request.",
      inputSchema: {
        type: "object",
        properties: {
          text: {
            type: "array",
            items: { type: "string" },
            description: "Array of texts to translate",
          },
          target_lang: {
            type: "string",
            description: "Target language code (EN-US, DE, FR ...)",
          },
          source_lang: {
            type: "string",
            description: "Source language code. Omit for auto-detect",
          },
          formality: {
            type: "string",
            enum: [
              "default",
              "more",
              "less",
              "prefer_more",
              "prefer_less",
            ],
          },
        },
        required: ["text", "target_lang"],
      },
    },
  ],
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name !== "translate") {
    throw new Error(`Unknown tool: ${request.params.name}`);
  }

  const { text, target_lang, source_lang, formality } =
    request.params.arguments;

  const body = { text, target_lang };
  if (source_lang) body.source_lang = source_lang;
  if (formality) body.formality = formality;

  const res = await fetch("https://api.deepl.com/v2/translate", {
    method: "POST",
    headers: {
      Authorization: `DeepL-Auth-Key ${API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(body),
  });

  if (!res.ok) {
    const err = await res.text();
    return {
      content: [{ type: "text", text: `DeepL error ${res.status}: ${err}` }],
      isError: true,
    };
  }

  const data = await res.json();
  return {
    content: [{ type: "text", text: JSON.stringify(data, null, 2) }],
  };
});

const transport = new StdioServerTransport();
await server.connect(transport);

Das sind 90 Zeilen für einen einzigen Endpoint — bereits auf das Minimum reduziert. Keine Retries. Kein Rate-Limit-Handling. Keine Pagination. Kein strukturiertes Error-Mapping. Und der API-Key liegt in einer Umgebungsvariable, wodurch Credentials oft ohne zentrale Governance über Client- und Server-Konfigurationen verstreut sind.

Ein produktionsreifer Wrapper mit mehreren Endpoints, ordentlichem Error-Handling, Retry-Logik und Rate Limiting wächst leicht auf über 200 Zeilen — plus package.json, Build-Schritt und ein Prozess, der laufen muss.

Jetzt multipliziere das mit jeder API, die angebunden werden soll.

Dieselbe Integration in DADL

Hier ist dasselbe DeepL-Übersetzungs-Tool in DADL beschrieben:

backend:
  name: deepl
  type: rest
  base_url: https://api.deepl.com/v2
  description: "DeepL translation API"

  auth:                              # ← credential injection handled by ToolMesh
    type: bearer
    credential: deepl_auth_key       #   references a server-side secret, never exposed to the model
    prefix: "DeepL-Auth-Key "

  defaults:
    errors:                          # ← retry and error handling for all tools
      retry_on: [429, 502, 503, 529]
      retry_strategy:
        max_retries: 3
        backoff: exponential
        initial_delay: 1s

  tools:
    translate:
      method: POST
      path: /translate
      access: write                  # ← access classification for authorization
      description: "Translate text into a target language"
      params:                        # ← parameter mapping: type, location, validation
        text:
          type: array
          in: body
          required: true
          description: "Array of texts to translate"
        target_lang:
          type: string
          in: body
          required: true
          description: "Target language code (EN-US, DE, FR)"
        source_lang:
          type: string
          in: body
          description: "Source language. Omit for auto-detect"
        formality:
          type: string
          in: body
          description: "default, more, less, prefer_more, prefer_less"

40 Zeilen YAML. Kein Code. Kein Build-Schritt. Keine eigene Server-Runtime, die gebaut und betrieben werden muss.

Doch kürzer ist nicht der Punkt. Der Punkt ist, was zur Laufzeit passiert.

Der Control Layer, den man nicht selbst baut

Die meisten handgeschriebenen Wrapper konzentrieren sich auf eine Sache: eine API aufrufbar machen. Sie bekommen den Request raus und die Response zurück. Das ist notwendig, aber für den Produktionsbetrieb nicht ausreichend.

Die schwierigeren Fragen sind: Wer darf dieses Tool aufrufen? Wo liegen die Credentials? Was passiert mit sensiblen Daten in der Response? Gibt es einen Audit Trail?

Bei einem eigenen Wrapper werden diese Aspekte entweder nachträglich drangeschraubt oder stillschweigend ignoriert. Mit DADL und ToolMesh sind sie der Default:

Concern	Custom MCP wrapper	DADL + ToolMesh
Credentials	In der Client-Konfiguration, sichtbar für das Modell	Serverseitig zur Laufzeit injiziert, nie offengelegt
Autorisierung	Typischerweise keine — voller Zugriff für alle	Pro Tool, pro Benutzer Zugriffskontrolle
Audit Logging	Nicht eingebaut	Jeder Aufruf protokolliert und abfragbar
Output Filtering	Nicht eingebaut	Policies können sensible Daten redigieren, bevor sie das Modell erreichen
Retries	Backoff-Logik selbst implementieren	Deklariert in `retry_strategy`, von der Runtime gehandhabt
Pagination	Cursor-/Offset-Logik selbst bauen	Konfiguriert via `pagination.strategy`
Error-Handling	Responses manuell parsen	Strukturiert via `errors.message_path`
Deployment	Bauen, paketieren, Prozess betreiben	Eine `.dadl`-Datei in ToolMesh ablegen

DADL beschreibt, was diese API ist. ToolMesh kümmert sich darum, wie Aufrufe an sie ausgeführt und kontrolliert werden. Diese Trennung ist die architektonische Verschiebung, auf die es ankommt — nicht nur die Zeilenzahl.

Du schreibst es nicht — dein LLM tut es

DADL wurde von Anfang an AI-native entworfen. Das Format ist kompakt, deklarativ und nah an der Struktur bestehender API-Spezifikationen.

Das heißt: Man kann seinem LLM einen OpenAPI-Spec, eine Swagger-Definition oder sogar rohe API-Dokumentation geben und es bitten, daraus eine DADL-Datei zu erzeugen. In den meisten Fällen ist das Ergebnis im ersten Durchlauf brauchbar. Reviewen, Edge Cases anpassen, deployen.

Im Vergleich dazu: ein LLM dazu bringen, einen kompletten MCP-Server zu generieren. Das Modell muss funktionierenden Code produzieren — Imports, Typdefinitionen, Error-Handling, Transport-Setup, Build-Konfiguration. Jede Zeile ist ein potenzieller Bug. Der Output muss getestet, debugged und manuell validiert werden, bevor er auch nur in die Nähe von Production kommt.

Mit DADL produziert das LLM eine Datenstruktur. Stimmt ein Feld nicht, ändert man eine Zeile YAML. Fehlt ein Parameter, fügt man drei Zeilen hinzu. Wenn etwas bricht, ist es häufiger ein reviewbares Spec-Problem als eine undurchsichtige Runtime-Exception irgendwo in generiertem Integrationscode.

Das ist der eigentliche Hebel. DADL ist nicht nur einfacher für Menschen zu schreiben. Es ist dramatisch einfacher für KI, korrekt zu erzeugen.

Wie das skaliert

Das DeepL-Beispiel oben deckt einen einzigen Endpoint ab. Echte APIs haben Dutzende.

Die vollständige DeepL-DADL-Definition deckt 13 Tools ab — Übersetzung, Dokumenten-Upload, Dokumenten-Status, Glossare, Textverbesserung, Sprachlisten, Usage-Tracking — in unter 500 Zeilen YAML. Die GitHub-Definition deckt 202 Tools ab: Repositories, Issues, Pull Requests, Commits, Code-Suche und mehr. Das als handgeschriebenen MCP-Server zu bauen ist kein Wochenend-Projekt. Das ist ein Produkt.

Aktuell enthält die DADL Registry 27 Backend-Definitionen mit 3.338 Tools über APIs wie GitHub, Cloudflare, Hetzner Cloud, Linode, GitLab und andere. Jede davon ist eine einzelne reviewbare YAML-Datei.

Mit wachsender Anzahl an Tools kommt eine weitere Skalierungsfrage: Context-Window-Overhead. ToolMesh begegnet dem mit Code Mode, bei dem das Modell über zwei Meta-Tools arbeitet — list_tools und execute_code — anstatt Hunderte von Tool-Definitionen direkt im Kontext mitzuschleppen. Damit bleibt die Tool-Discovery effizient, egal wie viele Backends angebunden sind.

Was DADL nicht tut

DADL ist ein deklaratives Format zur Beschreibung von REST-APIs. Es ist keine Workflow-Engine, keine General-Purpose-Programmiersprache und kein Ersatz für jede Art von MCP-Server.

Wenn eine Integration eigene Business-Logik, komplexe mehrstufige Orchestrierung oder Nicht-REST-Protokolle braucht, ist ein eigener Server weiterhin die richtige Wahl. ToolMesh kann auch damit umgehen — es verbindet sowohl DADL-beschriebene Backends als auch bestehende MCP-Server.

Aber für die große Klasse von Integrationen, die im Kern „eine REST-API mit den richtigen Auth-Daten und Parametern aufrufen” sind — und das sind die meisten — ist ein eigener Wrapper ein schlechter Default. Er dupliziert Infrastruktur-Aspekte, verteilt Kontroll-Logik über Codebases und erzeugt Wartungsaufwand, der keinen einzigartigen Mehrwert bringt.

Die Verschiebung

Das MCP-Ökosystem hat das Protokoll-Problem gelöst. Clients und Hosts sprechen dieselbe Sprache.

Aber Protokoll-Standardisierung hat Backend-Integration nicht günstig gemacht. Jede neue API bedeutet immer noch einen neuen Server, eine neue Codebase, eine neue Runtime, eine neue Wartungslast. Genau deshalb hören die meisten Teams nach einer Handvoll Integrationen auf, und der lange Schwanz nützlicher APIs bleibt nicht angebunden.

DADL ändert die Arbeitseinheit. Statt „einen Server bauen” wird die Aufgabe „die API beschreiben.” Statt eines Software-Projekts pro Integration bekommt man eine reviewbare YAML-Datei pro Backend — ausgeführt über eine Runtime, die Sicherheit, Credentials und Governance zentral handhabt.

Das ist nicht nur weniger Code. Es ist weniger Varianz, weniger Risiko und ein fundamental besserer Default, um KI-Agenten an reale Systeme anzubinden.

Stöbere in der DADL Registry, wirf einen Blick in die ToolMesh-Dokumentation oder den Quellcode auf GitHub.

Warum MCP-Gateways allein das eigentliche Problem nicht lösen

Thu, 02 Apr 2026 00:00:00 GMT

KI-Agenten, die Produktionssysteme berühren, brauchen zwei Dinge.

Erstens brauchen sie eine sichere Ausführungsschicht: Authentifizierung, Autorisierung, Credential-Isolation, Audit-Logging, Output-Kontrollen und eine Runtime, die fail-closed reagiert, wenn etwas nicht stimmt.

Zweitens brauchen sie einen günstigen Weg, Backends bereitzustellen: nicht nur ein oder zwei handgebaute Integrationen, sondern Dutzende oder Hunderte echter Systeme, die zu nutzbaren Tools werden, ohne dass jede API zu einem eigenen kleinen Softwareprojekt wird.

Die meisten aktuellen MCP-Diskussionen drehen sich fast ausschließlich um das erste Problem.

Das ist nachvollziehbar. Das erste Problem ist beängstigend. Wenn ein Agent Produktions-Tools aufrufen kann, ist der Blast Radius real. Credentials lecken. PII rutscht durch. Audit-Trails gehen verloren. Ein halluzinierter Aufruf kann zu einem echten Incident werden.

Also ja, Gateways sind wichtig.

Sie sind die fehlende Control Plane zwischen dem Modell und den Systemen, auf die es ankommt.

Aber sie lösen das tiefere Skalierungsproblem nicht.

Dieses Problem sitzt eine Schicht früher.

Der eigentliche Engpass liegt nicht darin, wie wir Tool-Calls proxen.

Der eigentliche Engpass ist, dass das Erstellen von Backends nach wie vor viel zu teuer ist.

Deshalb lösen MCP-Gateways allein das eigentliche Problem nicht.

MCP hat das Interface-Problem gelöst

MCP ist wichtig, weil es dem Ökosystem einen gemeinsamen Weg gibt, Tools zu entdecken und aufzurufen. Das ist bereits ein großer Schritt nach vorn. Es beseitigt unmittelbar eine ganze Klasse von Integrationsschmerzen: Clients und Hosts brauchen kein eigenes Protokoll mehr für jeden Tool-Anbieter.

Das ist echter Fortschritt.

Aber es ist nur ein Teil des Stacks.

Ein Protokollstandard ist nicht dasselbe wie ein skalierbares Integrationsmodell.

HTTP hat nicht die Notwendigkeit beseitigt, APIs zu entwerfen. OpenAPI hat nicht die Notwendigkeit beseitigt, Services zu bauen. Kubernetes hat nicht die Notwendigkeit beseitigt, gute Anwendungen zu schreiben.

Auf die gleiche Weise beseitigt MCP nicht die Arbeit, die nötig ist, um reale Systeme als nützliche, sichere und wartbare Tools verfügbar zu machen.

Es standardisiert die Invocation. Es macht Integrationen nicht günstig.

Diese Unterscheidung lässt sich in frühen Demos leicht übersehen, weil die ersten paar Tools immer die einfachsten sind. Ein simpler GitHub-Wrapper. Ein leichtgewichtiges Stripe-Beispiel. Ein interner Endpoint, der zum Proof of Concept wird.

Das reicht, damit das Protokoll wie die ganze Geschichte aussieht.

Das ist es nicht.

Der schwierige Teil beginnt, wenn sich die Frage ändert von „Können wir ein Tool bereitstellen?” zu „Können wir fünfzig Backends bereitstellen, ohne fünfzig kleine Softwareprodukte zu bauen?”

Gateways lösen Runtime-Kontrolle, nicht die Ökonomie der Integration

Ein ernstzunehmender MCP-Einsatz braucht eine Runtime, die zwischen Agenten und Backends sitzt.

Diese Runtime sollte den Aufrufer verifizieren, Autorisierung durchsetzen, Credentials zur Laufzeit injizieren, jeden Aufruf protokollieren und Output-Kontrollen anwenden, bevor sensible Daten das Modell oder den Nutzer erreichen. Sie sollte fail-closed reagieren. Wenn eine Prüfung fehlschlägt, läuft nichts.

Genau dafür ist ein Gateway da.

Und genau hier passt ToolMesh hinein: eine selbst gehostete Ausführungsschicht zwischen Agenten und Infrastruktur, die Autorisierung, Secret-Injection, Audit-Logging und Output-Policies bei jedem Tool-Call durchsetzt. Diese Schicht ist nicht optional, wenn ein Agent Produktionssysteme berührt. Sie ist der Unterschied zwischen einer schicken Demo und einer Produktivarchitektur.

Aber ein Gateway regelt nur das, was bereits existiert.

Es kann Tool-Calls absichern. Es kann Policy zentralisieren. Es kann die Ausführung beobachtbar machen.

Was es allein nicht kann, ist die Kostenstruktur zu ändern, mit der die Tools überhaupt erst gebaut werden.

In diese Falle laufen viele Teams gerade hinein.

Sie verbessern die Control-Schicht und gehen davon aus, dass das Skalierungsproblem gelöst sei.

In Wirklichkeit haben sie den oberen Teil des Funnels abgesichert und den Engpass beim Erstellen unangetastet gelassen.

Das eigentliche N×M-Problem sitzt vorgelagert

Häufig wird das N×M-Problem in MCP als Kompatibilitätsproblem beschrieben: viele Clients, viele Backends, zu viele individuelle Paarungen.

MCP reduziert einen Teil davon, was gut ist.

Aber das schmerzhaftere N×M-Problem liegt vorgelagert.

Es liegt in der wiederholten Arbeit, die nötig ist, um Backend für Backend für Backend bereitzustellen.

Für jede API bauen Teams am Ende dasselbe Bündel an Themen immer wieder neu:

Auth-Handling
Parameter-Mapping
Pagination
Retries
Error-Normalisierung
Schema-Shaping
Deployment-Packaging
Runtime-Ownership
Wartung, wenn sich die API ändert

Manchmal steckt diese Arbeit in einem eigenen MCP-Server. Manchmal wird sie zu einem dünnen Adapter. Manchmal wird sie als „kleine Integration” getarnt.

Aber es ist jedes Mal dasselbe Muster.

Deshalb fühlen sich wrapper-lastige Ansätze am Anfang gut an und im Maßstab fürchterlich.

Die erste Integration ist spannend. Die fünfte ist handhabbar. Die zwölfte wird zum Priorisierungsproblem. Bei der zwanzigsten fangen Teams an, nur noch die Endpoints freizugeben, die sie zwingend brauchen.

Alles andere landet im Backlog.

Das Ergebnis ist bekannt: eine Landschaft aus halben Wrappern, lückenhafter Abdeckung, dupliziertem Boilerplate, mehreren Runtimes und einem Long Tail von APIs, die Agenten nie zur Verfügung stehen.

Das ist kein Gateway-Versagen. Es ist ein Versagen beim Backend-Erstellen.

Bessere Proxies machen das Erstellen von Backends nicht trivial

Das ist der Kernpunkt.

Ein besserer Proxy kann Sicherheit, Konsistenz und Beobachtbarkeit verbessern.

Er kann nicht verhindern, dass ein Wrapper ein Wrapper bleibt.

Wenn jedes neue Backend immer noch mit „jemand muss einen eigenen MCP-Server bauen und betreiben” beginnt, ist die Ökonomie weiterhin kaputt.

Man kann ein wunderschön konstruiertes Gateway vor diese Welt setzen, und es wird die Produktionsreife absolut verbessern.

Aber das System wird trotzdem schlecht skalieren, weil die Arbeitseinheit weiterhin zu teuer ist.

Jedes zusätzliche Backend bedeutet immer noch mehr Code, mehr Packaging, mehr Deployment, mehr Ownership und mehr Oberfläche, die gewartet werden muss.

Die eigentliche Frage lautet also nicht:

„Wie setzen wir einen besseren Proxy vor MCP-Server?”

Die eigentliche Frage lautet:

„Wie machen wir das Bereitstellen eines Backends so günstig, dass der Long Tail nützlicher Systeme tatsächlich angebunden wird?”

Das ist der Punkt, an dem sich die Diskussion verlagern muss.

Dem MCP-Stack fehlt eine Description-Schicht

Sobald man das Problem sauber trennt, wird die Architektur offensichtlich.

Die MCP-Ära braucht drei Schichten:

eine Protokoll-Schicht für Discovery und Invocation
eine Ausführungsschicht für Governance und Runtime-Kontrolle
eine Description-Schicht, die Backends günstig bereitstellbar macht

Die erste Schicht ist MCP. Die zweite Schicht ist das Gateway. Die fehlende dritte Schicht ist dort, wo die meisten Ökosysteme noch unreif sind.

Ohne diese dritte Schicht bleibt jedes Backend eine eigene Engineering-Übung. Mit ihr wird das Bereitstellen von Backends zu einem deklarativen Problem.

Und das ändert alles.

Denn Descriptions skalieren anders als Code.

Eine gute Description-Schicht verschiebt wiederkehrende Logik aus maßgeschneiderten Wrappern in gemeinsames Runtime-Verhalten. Sie macht aus dem Bereitstellen eines Backends statt eines handgebauten Servers ein kompaktes, prüfbares, deklaratives Artefakt.

Das ist der architektonische Wandel, den das MCP-Ökosystem braucht, wenn es über eine Handvoll polierter Demos hinausgehen will.

DADL ist das fehlende Stück

Genau hier kommt DADL ins Spiel.

DADL, die Dunkel API Description Language, geht einen anderen Weg als die wrapper-zuerst-Integration. Statt für jede REST-API einen eigenen MCP-Server zu schreiben, wird das Backend deklarativ in YAML beschrieben, während die Runtime die Standardmechanik übernimmt, die sonst immer wieder neu gebaut würde: Authentifizierung, Pagination, Retries und Error-Mapping.

Das ist nicht nur eine angenehmere Developer Experience. Es ist ein anderes Kostenmodell.

Ohne Description-Schicht ist die Standard-Arbeitseinheit: einen Server bauen. Mit einer Description-Schicht wird die Arbeitseinheit: das Backend beschreiben, es reviewen und die Runtime es sicher ausführen lassen.

Das ist eine radikal bessere Skalierungskurve.

Es bedeutet, dass Teams mehr von der echten API-Oberfläche bereitstellen können, statt nach einer engen „good enough”-Auswahl zu stoppen. Es bedeutet, dass sie nicht für jede Integration eine eigene Runtime, einen eigenen Dependency-Baum, ein Docker-Image und eine eigene Wartungslast brauchen. Es bedeutet, dass gemeinsame Integrationslogik dort lebt, wo sie hingehört: in einer gemeinsamen Ausführungsumgebung.

Und weil DADL bewusst kompakt und nahe an der Struktur bestehender API-Spezifikationen gehalten ist, öffnet es auch die Tür zu etwas noch Wichtigerem: moderne LLMs können aus einer vorhandenen API-Definition oft eine brauchbare erste Version generieren.

Hier ändert sich die Kategorie wirklich.

Denn sobald das Modell beim Generieren der Description helfen kann und die Runtime sie sicher ausführt, sinken die Kosten für das Anbinden eines neuen Backends um eine Größenordnung.

Genau so beginnt man, den Long Tail zu erschließen.

Warum das der OpenAPI-Moment für MCP ist

Die beste Analogie hier ist nicht „noch ein Gateway” oder „noch ein Wrapper-Framework”.

Es ist OpenAPI.

OpenAPI hat HTTP nicht ersetzt. Es hat HTTP-Ökosysteme programmierbar gemacht. Es hat APIs auf eine Weise beschreibbar gemacht, die Tools, Docs, Code-Generatoren und Plattformen alle verstehen konnten.

Diese Verschiebung war nicht glamourös, aber sie hat die Ökonomie der API-Arbeit verändert.

Das MCP-Ökosystem braucht jetzt dieselbe Art von Verschiebung.

MCP standardisiert bereits, wie Tools aufgerufen werden. Was in vielen Architekturen noch fehlt, ist eine standardisierte Art, reale Backends zu beschreiben, sodass Tooling- und Runtime-Schichten die langweilige Arbeit einmal erledigen können, statt sie Teams für immer neu implementieren zu lassen.

Deshalb versteht man DADL am besten als OpenAPI für die MCP-Ära.

Nicht weil es MCP ersetzt. Nicht weil es ein Gateway ersetzt. Sondern weil es die fehlende Abstraktionsschicht zwischen rohen Backend-APIs und sicherer, steuerbarer Tool-Ausführung füllt.

Warum Entwickler sich dafür interessieren sollten

Für Entwickler geht es vor allem darum, der Integrationsmühsal zu entkommen.

Der meiste Wrapper-Code ist kein differenzierendes Engineering. Es ist repetitive Anpassungsarbeit, die Zeit verschlingt, die Wartungslast ausdehnt und mehr Runtime-Wildwuchs als Wert erzeugt.

Eine deklarative Backend-Schicht ändert das.

Statt zum zehnten Mal dieselbe Auth- und Pagination-Logik zu schreiben, können Teams sich auf das konzentrieren, worauf es wirklich ankommt: Domänenverhalten, Workflows, Guardrails und die Produktlogik, die auf diesen Tools aufbaut.

Ebenso wichtig: Niedrigere Integrationskosten erhöhen die API-Abdeckung.

Das ist sehr relevant.

Agenten-Systeme bleiben oft hinter ihrem Potenzial zurück, nicht weil das Modell schwach ist, sondern weil die verfügbare Tool-Oberfläche zu dünn ist. Das Backend unterstützt vielleicht fünfzig nützliche Operationen, aber nur sechs sind bereitgestellt, weil das Wrappen der übrigen zu teuer ist.

Wenn das Erstellen von Backends günstig wird, kann die Tool-Schicht beginnen, dem tatsächlichen System zu ähneln statt den Budget-Beschränkungen des Integrations-Teams.

Warum Architekten sich dafür interessieren sollten

Für Architekten ist der Wert noch klarer.

Ein Drei-Schichten-Modell trennt Verantwortlichkeiten auf die richtige Weise.

MCP übernimmt die Kommunikation. Das Gateway übernimmt Trust, Kontrolle und Auditierbarkeit. Die Description-Schicht übernimmt die Backend-Skalierung.

Das bedeutet, dass Policy nicht mehr davon abhängt, wie ein bestimmter Wrapper geschrieben wurde. Credentials bleiben außerhalb des Modell-Kontextes. Audit wird konsistent. Sicherheit wird systemisch statt zufällig.

Und neue Integrationen lassen sich hinzufügen, ohne jedes Mal einen neuen Snowflake-Service zu schaffen.

Das ist die Art von Architektur, die Unternehmen tatsächlich wollen.

Nicht einen Zoo halb gewarteter MCP-Server. Nicht eine Zukunft, in der jedes neue Backend eine weitere Runtime bedeutet, die gepatcht und beobachtet werden muss.

Sie wollen eine stabile Ausführungsschicht und einen günstigen Weg, mehr Systeme unter diese Schicht zu bringen.

Genau deshalb reichen Gateways allein nicht aus.

Die Zukunft ist nicht Gateway gegen Description-Schicht

Sie ist Gateway plus Description-Schicht.

Das ist keine Entweder-oder-Wahl.

Man braucht MCP, weil das Ökosystem ein gemeinsames Protokoll braucht. Man braucht ein Gateway, weil Produktions-Tool-Calls Governance brauchen. Und man braucht eine Description-Schicht, weil sich keine Organisation leisten kann, das Bereitstellen von Backends über endlose handgebaute Wrapper zu skalieren.

Das ist der Stack.

MCP standardisiert die Invocation. ToolMesh sichert die Ausführung. DADL macht das Erstellen von Backends günstig genug, um zu skalieren.

Sobald man das Problem so sieht, fällt es leichter, das Marktrauschen zu ignorieren.

Die Gewinner in diesem Bereich werden nicht die Teams mit der hübschesten Proxy-Geschichte sein. Es werden die Teams sein, die beide Seiten der Gleichung lösen:

sichere Ausführung für reale Systeme
triviales Erstellen für reale Backends

Das eigentliche Problem

Also ja, baut das Gateway. Es wird gebraucht.

Aber verwechselt Runtime-Kontrolle nicht mit Integrations-Skalierung.

Das eigentliche Problem ist nicht, dass MCP bessere Proxies braucht. Das eigentliche Problem ist, dass das Ökosystem das Bereitstellen von Backends nach wie vor als individuelle Software-Arbeit behandelt, obwohl es eine deklarative Operation sein sollte.

Solange das so bleibt, wird der Long Tail nützlicher Systeme abgehängt bleiben, und Agenten-Infrastruktur wird immer wieder gegen dieselbe Decke stoßen.

Diese Decke bricht nicht, indem man härter proxt.

Sie bricht, wenn das Erstellen von Backends trivial wird.

Deshalb lösen MCP-Gateways allein das eigentliche Problem nicht.

Und deshalb ist DADL wichtig.

Nicht als Komfort-Feature. Nicht als Sidecar-Format. Sondern als die fehlende Description-Schicht, die sicheres Agenten-Tooling von handwerklicher Praxis in ein skalierbares System verwandelt.

In diesem Sinne ist der eigentliche Durchbruch nicht nur sicherere Tool-Calls.

Es ist, das Erstellen von Backends endlich günstig genug zu machen, damit die MCP-Ära skalieren kann.

ToolMesh | Blog

Einen UniFi-Standort in einem Prompt gegen NetBox abgleichen

Was darunter passiert

Was dieser Lauf tatsächlich getan hat

Die Definitionen brauchen dieselbe Sorgfalt

„Das mache ich seit Jahren mit Nornir”

Probier es gegen deinen eigenen Controller

Tool Discovery für 4.800 MCP-Tools — ohne Vektordatenbank

Wie ein Discovery-Aufruf auf 320 KB kommt

Die Lösung, die alle erwarten

Was wir stattdessen gebaut haben

1. Ausgabe, die degradiert statt detoniert

2. Geranktes Freitext-Suchen — BM25 in ~200 Zeilen Go

3. Discovery in der Sandbox

Was der Live-Test in zwanzig Minuten fand

Prior Art — und was sich auf Skala ändert

Wie es weitergeht

Von der Switch-Konfiguration zu NetBox in einem Prompt

Die Ausgangslage

Die Anweisung

Was darunter tatsächlich passiert

Die Stellen, vor denen du Respekt hättest — abgesichert

Was das ist — und was nicht

Willst du es in deinem eigenen Netz ausprobieren?

Die volle REST-API von Xen Orchestra 6.5 — 245 Tools aus einer DADL

Was die REST-API jetzt abdeckt

Die Zahlen

Ein durchgespieltes Beispiel: eine VM-Änderung, rückgängig machbar

Read-only ist ein Feature, keine Lücke

Der API hinterherzukommen ist ein YAML-Diff

Das Context-Window-Argument

Ehrliche Einschränkungen

Was tatsächlich anders ist

Anatomie einer Enterprise Tool Library

Was eine Enterprise Tool Library tatsächlich ist

Die sechs Säulen als Mechanik

1. Any Backend — zwei Eingangspfade, eine Runtime

2. Code Mode — flache Tool-Oberfläche, konstanter Kontext

3. Credential Store — Laufzeit-Injection, nie im Prompt

4. OpenFGA — ReBAC, ehrlich gegenüber dem Default

5. Output Gate — deterministisches JS, mit Wachstumsraum

6. Audit — slog und SQLite, SQL-abfragbar

Die fail-closed Request-Pipeline

CallerClass — die zweite Achse, die sonst niemand hat

Beispiel aus der Praxis: ein Backend hinzufügen

Warum der Kontext-Footprint konstant bleibt

Scope und Ehrlichkeit: ausgeliefert vs. geplant

Backends in der Praxis

Verwandte Themen

Ausprobieren

DeepL v3 Customization Hub — in einer DADL abgedeckt

Was das neue Release gebracht hat

Die Zahlen

Ein durchgespieltes Beispiel: Style Rules end-to-end

Asymmetrie in der Wartung

Das Context-Window-Argument

Ehrliche Einschränkungen

Was tatsächlich anders ist

NetBox aus realer Infrastruktur befüllen mit ToolMesh

Architektur-Überblick

Mapping: Quellobjekte auf NetBox-Objekte

Das Trust-Escalation-Modell

Wie es weitergeht

ToolMesh — die fehlende Kontrollschicht für KI-Agenten

Was ToolMesh ist

Die sechs Säulen

1. Authentication

2. Authorization

3. Credential Store

4. Output Gate

5. Execution

6. Audit Trail

DADL: deklarieren statt programmieren

Code Mode: Skalierung, die sonst nicht funktioniert

Self-hosted, Open Source

Loslegen

Hört auf, REST-API-Wrapper für MCP nachzubauen

Der Wrapper, den man immer wieder neu baut

Dieselbe Integration in DADL

Der Control Layer, den man nicht selbst baut