Was ist eine Enterprise Tool Library — und warum wird sie zur Pflicht, sobald mehr als ein Team mit Agenten arbeitet?

Von Axel Dunkel

Ein Team in einer mittelgroßen Versicherung baut sich einen MCP-Server, der Schadensfälle aus dem Bestandssystem ausliest. Ein anderes Team — drei Stockwerke höher, anderer Bereich, anderer Stack — baut sich ebenfalls einen MCP-Server, der genau dieselben Schadensfälle ausliest. Beide haben den OAuth-Client selbst registriert, beide loggen ihre Zugriffe lokal, beide haben das API-Schema in ihrer jeweiligen Sprache nachimplementiert. Niemand im Hause weiß, dass es beide gibt. Auch nicht der Datenschutzbeauftragte. Auch nicht das Security-Team. Auch nicht der Agent, der gerade beauftragt wird, eine Risikoanalyse über alle offenen Vorgänge zu erstellen — er sieht je nach Deployment den einen oder den anderen Server, aber nie beide, und nie konsistent.

Das ist kein erfundenes Szenario. Das ist der Normalfall, sobald in einer Organisation mehr als ein Team anfängt, ernsthaft mit KI-Agenten zu arbeiten.

Das Model Context Protocol (MCP) löst dieses Problem nicht. MCP standardisiert, wie ein einzelner Server seine Werkzeuge gegenüber einem einzelnen Agenten beschreibt. Es sagt nichts darüber aus, wie eine Organisation viele dieser Server gemeinsam verwaltet, versioniert, autorisiert und auditiert. Genau diese Lücke schließt das, was wir eine Enterprise Tool Library nennen.

Das Problem ist nicht technisch, es ist organisational

Die ersten ein, zwei MCP-Server in einem Unternehmen werden von Hand gepflegt. Das funktioniert. Der dritte ebenfalls. Spätestens beim zehnten kippt das Modell, weil sich vier Probleme parallel aufstapeln, die in der Tech-Diskussion über MCP normalerweise nicht vorkommen.

Erstens: Credential-Sprawl. Jeder MCP-Server, der eine externe API anspricht, braucht Zugangsdaten. In der Praxis liegen diese Zugangsdaten in der Umgebung des jeweiligen Servers — als Environment-Variable, als Secret im Helm-Chart, als Eintrag in einem Vault, der nur dem jeweiligen Team gehört. Die Frage “welche Service-Accounts hat unser KI-Stack eigentlich gerade aktiv?” ist in dieser Architektur nicht beantwortbar. Sie wird auch nicht durch Disziplin lösbar — sie ist strukturell nicht beantwortbar, weil die Information topologisch nicht zusammengeführt wird.

Zweitens: Autorisierungs-Inkonsistenz. Ob ein Agent ein bestimmtes Tool aufrufen darf, entscheidet im Standard-MCP-Modell der jeweilige Server. Der Server prüft, ob der Aufrufer authentisiert ist, und das war es. Welche fachliche Berechtigung dahintersteht — “darf dieser Agent im Auftrag von Frau Müller aus der Schadensabteilung Daten aus dem Bestandssystem lesen, oder nur solche aus ihrer Abteilung?” — fällt in die Verantwortung jedes einzelnen Servers, und wird in der Praxis je nach Team unterschiedlich gelöst. Oder gar nicht.

Drittens: Audit-Lücken. Wenn jeder Server seine eigenen Logs schreibt, in seinen eigenen Stack, mit seinem eigenen Format, gibt es keinen Punkt, an dem man die Frage “welche Tool-Calls hat unser KI-System gestern zwischen 14 und 16 Uhr ausgeführt” mit einer einzelnen Abfrage beantworten kann. Für interne Revision, DSGVO-Auskunftsersuchen und Sicherheitsvorfälle ist das ein Problem, das nicht durch ein Log-Aggregations-Tool gelöst wird — es muss am Punkt der Tool-Ausführung zentralisiert sein, nicht hinterher zusammengesucht.

Viertens: Das Kontextfenster. Dies ist das technische Problem, das in den anderen drei oft untergeht, aber es ist real. Jedes Werkzeug, das ein Agent kennen soll, muss ihm beschrieben werden — Name, Parameter, Typen, Rückgabewerte, Beispiele. Diese Beschreibung kostet Tokens. Bei zehn Tools fällt das nicht auf. Bei tausend Tools — was die normale Größenordnung einer ausgewachsenen Enterprise-Tool-Sammlung ist — frisst die reine Werkzeug-Beschreibung sechsstellige Token-Mengen, bevor der Agent auch nur ein einziges Tool tatsächlich aufgerufen hat. Das ist nicht nur teuer, es ist häufig technisch unmöglich, weil das Kontextfenster vorher voll ist.

Die ehrliche Beobachtung: Real existierende MCP-Deployments lösen das, indem sie dem Agenten nur einen kleinen Bruchteil ihrer tatsächlichen API-Landschaft zeigen. Was nicht in den Kontext passt, existiert für den Agenten nicht. Die Organisation hat hunderte APIs, der Agent kennt acht.

Vier Eigenschaften, die eine Sammlung erst zur Library machen

Eine Enterprise Tool Library ist keine technische Komponente, sondern ein Pattern, das genau diese vier Probleme zusammen löst. Der Begriff ist von der etablierten Idee einer Software-Bibliothek übernommen — eine Bibliothek hat einen Katalog, einen Aufsichtspunkt, eine Ausleih-Ordnung und sie ist auffindbar. Eine Enterprise Tool Library überträgt das auf API-Werkzeuge für KI-Agenten.

Konkret zeichnen sie vier Eigenschaften aus:

Eine einzige Authentifizierungs- und Autorisierungs-Grenze. Wer mit der Library spricht, authentisiert sich genau einmal. Welche Werkzeuge er oder sie aufrufen darf, wird an genau einem Punkt entschieden, mit einem zentralen Policy-Modell. In der Praxis bedeutet das: ein zentraler Identity-Layer (OIDC, SAML, beliebige Unternehmens-IdP), eine zentrale Authorization-Engine (etwa OpenFGA für relationsbasierte Zugriffsentscheidungen) und ein zentraler Credential-Store, in dem die technischen Zugangsdaten zu den nachgelagerten APIs liegen — getrennt von den fachlichen Berechtigungen der Aufrufer.

Die konsequente Erweiterung dieser Grenze — auch zu steuern, welche Werkzeuge ein Aufrufer überhaupt zu sehen bekommt, nicht nur welche er aufrufen darf — ist eine eigenständige Designaufgabe mit konzeptueller Tiefe. Sichtbarkeit ist nicht einfach “Filter über Authorization”: sie berührt Fragen der Auffindbarkeit (wie sucht ein Aufrufer, der nicht weiß was er nicht weiß?), der Vertraulichkeit (existiert ein Werkzeug für einen Aufrufer überhaupt, wenn er es nicht aufrufen darf?) und der Komposition (was passiert, wenn ein Code-Mode-Skript zur Laufzeit Werkzeuge entdeckt, die seinem Aufrufer nicht zustehen?). Das ist einer der offenen Räume in der Architektur einer Enterprise Tool Library, und wir arbeiten aktiv daran.

Eine zusammenhängende Audit-Linie. Jeder Tool-Call, den ein Agent durchführt, hinterlässt einen Eintrag in einem zentralen Audit-Log. Wer hat aufgerufen, mit welcher Identität, in welchem Auftrag, mit welchen Parametern, mit welcher Antwort, zu welcher Zeit. Diese Linie muss unmanipulierbar und vollständig sein — sonst beantwortet sie weder die Frage des Wirtschaftsprüfers noch die der Aufsichtsbehörde.

Eine gemeinsame, lesbare Beschreibungssprache. Jedes Werkzeug in der Library wird in einem Format beschrieben, das jeder im Unternehmen lesen, prüfen und erweitern kann — auch der Security-Architekt, der kein Go oder Python schreibt, und auch das nächste Team, das ein neues Werkzeug ergänzen will. Dieses Format darf nicht der Code des jeweiligen Wrapper-Servers sein. Es muss deklarativ sein, versionierbar in Git, und es muss von einem einzigen geteilten Runtime interpretiert werden können — damit Code-Review von neuen Werkzeugen tatsächlich Sache des Architektur-Boards sein kann und nicht des jeweiligen Implementierungs-Teams.

Konstanter Kontext-Footprint. Die Größe der Library darf den Token-Verbrauch des Agenten nicht linear erhöhen. Das geht nur, wenn der Agent nicht alle Werkzeug-Beschreibungen als Auswahlmenü vorgesetzt bekommt, sondern wenn er — etwa über Code Mode, also über generierten Code, der die Library als API anspricht — gezielt die Werkzeuge sucht und nutzt, die er gerade braucht. Das ist die einzig bekannte Technik, mit der eine vierstellige Werkzeug-Bibliothek einem heutigen Modell überhaupt zugänglich gemacht werden kann.

Fehlen drei von vier Eigenschaften, ist es eine Sammlung von MCP-Servern. Fehlt eine — egal welche — bleibt es eine Sammlung von MCP-Servern mit Komfort-Funktionen. Erst alle vier zusammen ergeben das, was eine Organisation braucht, sobald mehr als ein Team mit Agenten arbeitet.

Warum dieser Begriff jetzt akut wird

Im Frühjahr 2026 hat AWS mit dem Agent Toolkit das Pattern bestätigt: Die Hyperscaler haben erkannt, dass die einzelne MCP-Server-Architektur in Unternehmen nicht skaliert, und sie bauen ihre eigenen Library-Schichten — natürlich an ihre Cloud gebunden. Wer das Pattern dort übernimmt, bekommt es vermutlich schnell zum Laufen. Er bekommt aber auch ein Stück Architektur, das nur innerhalb der AWS-Welt sinnvoll funktioniert, und das alle Werkzeuge — auch die für interne Systeme, On-Premises-Datenbanken, lokale Spezialanwendungen — durch eine Hyperscaler-Kontrollschicht laufen lässt.

Das ist eine legitime Designentscheidung, aber es ist eine, die explizit getroffen werden sollte und nicht durch Default-Migration entstehen darf. Eine Enterprise Tool Library kann genauso gut self-hosted, vendor-neutral und souverän aufgebaut sein. Die vier oben genannten Eigenschaften sind in keiner Weise an einen bestimmten Cloud-Anbieter gebunden — sie sind ein Architektur-Pattern, das in jedem Stack realisierbar ist, sofern man die richtigen Bausteine wählt.

Wie wir das operationalisieren

Wir haben dieses Pattern in zwei aufeinander aufbauenden Komponenten umgesetzt und unter offenen Lizenzen veröffentlicht.

DADL — die Dunkel API Description Language — ist die deklarative Beschreibungssprache. Eine DADL-Datei beschreibt eine REST-API mit ihren Endpunkten, ihrer Authentifizierung, ihrer Pagination, ihrer Response-Form und ihrer Zugangsklassifikation in einer einzigen YAML-Datei. Kein generierter Code, kein dedizierter Server pro API. Die Spezifikation steht unter CC BY-SA 4.0 auf dadl.ai , der öffentliche Katalog enthält derzeit über 1.800 Tool-Definitionen aus 20 Diensten.

ToolMesh ist die zugehörige Runtime — eine Apache-2.0-lizenzierte Execution-Schicht, die DADL-Dateien zur Laufzeit interpretiert, alle Aufrufe durch eine zentrale Authentifizierungs- und Autorisierungs-Grenze führt, jeden Tool-Call in einem strukturierten Audit-Log dokumentiert, und über ein Code Mode-Interface dafür sorgt, dass der Kontext-Footprint unabhängig von der Katalog-Größe konstant bleibt. In unseren Messungen reduziert das die Tool-Advertisement-Kosten gegenüber dem naiven Modell um Faktor 142 — von etwa 142.000 auf etwa 1.000 Tokens — bei einem Katalog von über 1.800 Werkzeugen.

Über Authentifizierung, Autorisierung und Audit hinaus betreibt ToolMesh ein Output Gate: eine deterministische Policy-Schicht (JavaScript-Policies via goja), die einzelne Aufrufe vor ihrer Ausführung blockieren oder modifizieren kann — fail-closed, vor der eigentlichen Tool-Ausführung statt nachträglich. Diese deterministische Stufe ist heute aktiv. Sie ist zugleich die erste Ebene einer mehrstufigen Sicherheits-Boundary, deren weitere Ebenen sich in Entwicklung befinden; wir gehen darauf in zukünftigen Beiträgen ein.

Zusammen ergeben DADL und ToolMesh die Mechanik einer Enterprise Tool Library. Das Pattern selbst gehört niemandem; es ist ein Architektur-Konzept, und es wird in den nächsten Jahren in unterschiedlichen Implementierungen sichtbar werden. Wir halten unsere für die offenste und souveränste Variante — aber die wichtigere Botschaft ist nicht “nimm unseren Stack”, sondern “erkennt, dass eure Werkzeug-Sammlung längst eine Library sein müsste, und behandelt sie auch so”.

Ein einfacher Test

Wenn Sie unsicher sind, ob Ihre Organisation bereits eine Enterprise Tool Library hat oder noch nicht, hilft ein einfacher Test. Fragen Sie eine beliebige Person aus dem Architektur- oder Security-Team:

“Kannst du mir in fünf Minuten zeigen, welche Werkzeuge die KI-Agenten bei uns im Haus heute aufrufen dürfen, wer das genehmigt hat, und wer in den letzten 24 Stunden was davon tatsächlich benutzt hat?”

Wenn die Antwort nicht “ja, hier” lautet, sondern “da müsste ich erst…”, dann sammeln Sie MCP-Server. Sie haben noch keine Library. Das ist überhaupt nicht schlimm — es ist ein normaler Übergangs-Zustand. Aber es ist ein Zustand, den man nicht beibehalten will, sobald die zweite Geschäftseinheit anfängt mitzumachen.

Dieser Beitrag erschien begleitend zur Veröffentlichung des DADL-Papers (Zenodo , arXiv:2605.05247 ). Anfragen zu Pilotinstallationen oder fachlicher Diskussion: [email protected].