ToolMesh — Sichere MCP-Control-Layer für KI-Agenten-Tools
KI-Agenten an echte Systeme lassen
— sicher.
ToolMesh ist die sichere Control-Layer zwischen KI-Agenten und deinen Backends. Jeder Tool-Call läuft durch eine Fail-Closed-Pipeline: authentifizieren → autorisieren → Credentials injizieren → Output prüfen → ausführen → auditieren. Vor jedem bestehenden MCP-Server einsetzbar — und macht aus jeder REST-API gesteuerte Tools über deklarative DADL-Dateien.
ToolMesh ist eine Enterprise Tool Library — in der Praxis.
MCP löst, wie ein Agent mit einem Tool spricht. Es löst nicht, wie ein Unternehmen einen vierstelligen Werkzeugkatalog über viele Backends hinweg regiert. Genau diese Lücke schließt eine Enterprise Tool Library — und genau das implementieren ToolMesh + DADL, offen und self-hosted, ohne Vendor dazwischen.
- Eine Auth/AuthZ-Grenze. Aufrufer authentisieren sich einmal; tool-genaue, benutzerspezifische Autorisierung über OpenFGA.
- Eine zusammenhängende Audit-Linie. Jeder Tool-Call landet in einem SQL-abfragbaren Log — wer, was, wann, mit welchem Payload.
- Eine gemeinsame deklarative Sprache. DADL beschreibt jede REST-API in YAML — versionierbar in Git, generierbar aus einer OpenAPI-Spec.
- Konstanter Kontext-Footprint. Code Mode hält den Token-Verbrauch flach, egal wie groß der Katalog wird — siehe Code Mode.
Vollständiges Argument im Blog: Enterprise Tool Library — warum der Begriff jetzt zählt.
Dein LLM schreibt die Integration.
Fast jede REST-API — in Minuten agentenfähig.
Sobald die Governance steht, brauchst du auch einen schnellen Weg, Tools hinzuzufügen. DADL beschreibt fast jede REST-API als Agent-Tools in purem YAML — dein LLM kann es aus einer bestehenden OpenAPI-Spec generieren, und ToolMesh stellt es durch dieselbe Governance-Pipeline bereit.
import { Server } from "@modelcontextprotocol/sdk";
import express from "express";
const app = express();
const server = new Server({ name: "github" });
server.setRequestHandler("tools/list", () => ({
tools: [{
name: "list_repos",
description: "List repositories",
inputSchema: {
type: "object",
properties: {
sort: {
type: "string",
enum: ["created", "updated"]
}
}
}
}]
}));
server.setRequestHandler("tools/call",
async (req) => {
const resp = await fetch(
"https://api.github.com/user/repos",
{ headers: {
Authorization: "Bearer " + TOKEN
}}
);
return { content: [
{ type: "text", text: await resp.text() }
]};
});
app.use(server.transport);
app.listen(3000);
// + error handling, pagination,
// retries, auth refresh, types...spec: "https://dadl.ai/spec/v0.1"
backend:
name: github
type: rest
base_url: https://api.github.com
auth:
type: bearer
credential: github_token
defaults:
pagination:
strategy: link_header
tools:
list_repos:
method: GET
path: /user/repos
description: "List repositories"
params:
sort:
type: string
enum: [created, updated]hetzner-cloud.dadl — 98 Tools, sofort einsatzbereit Oder aggregiere die MCP-Server, die du schon betreibst.
ToolMesh funktioniert auch ohne DADL — richte es vor deine bestehenden MCP-Server, und jeder Aufruf läuft durch dieselben Autorisierungs-, Credential-, Gating- und Audit-Schichten.
Was DADL ist — und was nicht.
Die DADL-Spezifikation steht unter CC BY 4.0 — wie OpenAPI, aber optimiert für LLM-Tool-Nutzung. Eigene Dateien schreiben, in Git versionieren, teilen, forken.
ToolMesh liest .dadl-Dateien aus deinem eigenen config/-Verzeichnis. Der Server läuft komplett offline und self-hosted — deine DADLs verlassen deine Infrastruktur nie.
dadl.ai ist ein optionaler Community-Katalog — wie Docker Hub für Tool-Definitionen. ToolMesh ruft dadl.ai zur Laufzeit nicht auf. Dateien zum Build holen, spiegeln, selbst schreiben — alles ist gültig.
ToolMesh läuft auch als reiner MCP-Aggregator. Stelle deine bestehenden MCP-Server dahinter — DADL ist ein Eingangspfad, keine Bedingung.
Runtime ist Apache 2.0, Spec ist CC BY 4.0 — nichts daran ist proprietär. DADL-Details →
Was passiert, wenn ein Agent deine API aufruft?
Agent erhält: "Liste offene Rechnungen von Stripe auf"
trusted stripe_list_invoices sk_live_4eC39HqL... GET /v1/invoices?status=open [GESCHWÄRZT] Agenten an Produktivsystemen sind beängstigend.
Zugangsdaten in Prompts. Kein Audit-Trail. Keine Inhaltskontrolle. Ein halluzinierter API-Call vom Datenleck entfernt.
ToolMesh fügt die fehlende Schicht ein.
Jeder Aufruf authentifiziert, autorisiert, mit Credentials versehen, inhaltlich geprüft und protokolliert. Fail-Closed-Pipeline — wenn eine Prüfung fehlschlägt, wird nichts ausgeführt.
Jede API, integriert in Minuten.
Zeig deinem LLM eine API-Spezifikation und erhalte eine funktionierende DADL-Datei zurück. Kein Wrapper-Code, kein Deployment, keine Wartung. Mehr Tools anbinden — schneller als je zuvor.
Architektur auf einen Blick
Jeder Tool-Call durchläuft eine Fail-Closed-Pipeline. Wenn eine Stufe ablehnt, wird nichts ausgeführt.
Was du bekommst
Jede API in Minuten
30 Zeilen DADL ersetzen einen ganzen MCP-Server. LLM-generiert aus API-Specs, mit Auth, Pagination und Retries eingebaut.
Flache Token-Kosten für 24+ Backends
Code Mode ersetzt jede Tool-Definition durch zwei Meta-Tools und ein SQL-artiges Discovery-API. ~142.000 Tokens für die Ankündigung von 3.115+ Tools fallen auf ~1.000 — Faktor ~142, egal wie groß der Katalog wird.
Secrets vor dem Modell verbergen
API-Keys werden zur Laufzeit vom ToolMesh-Server injiziert. Das LLM sieht nie Zugangsdaten — nicht in Prompts, nicht in Konfigurationen, nicht in Antworten.
Kontrollieren, wer was darf
Tool-genaue, benutzerspezifische Autorisierung über OpenFGA. Beispiel: Free-User bekommen nur Lese-Tools, Pro-User alles.
Mehrstufiges Output Gate
Layer 1 ist heute aktiv: deterministische goja-basierte JS-Policies blockieren vertrauliche Payloads vor der Ausführung und schwärzen PII in Antworten. Weitere Ebenen (semantisch, modellgestützt) in Entwicklung.
Jeden Aufruf sehen
SQL-abfragbarer Audit-Trail. Jeder Tool-Aufruf einem Benutzer, Plan und Aufrufer zugeordnet. 'Was hat der Agent getan?' — mit einer Query beantwortet.
Wissen, welcher Agent aufruft — und entsprechend vertrauen.
ToolMesh ist das einzige bekannte MCP-Gateway, das unterscheidet, welcher KI-Client jeden Tool-Call auslöst. Claude Code bekommt vollen Zugriff. Ein unbekannter Drittanbieter-Agent bekommt PII-Filterung und eingeschränkte Tools. Gleiche Infrastruktur, abgestuftes Vertrauen.
| CallerClass | PII-Filterung | Tool-Zugriff |
|---|---|---|
trusted | Nur Credentials | Vollständig |
standard | Hochrisiko-PII + Credentials | Vollständig |
untrusted | Alle PII-Muster | Sensible Tools gesperrt |
Nginx hat Web-Apps produktionsreif gemacht — Reverse Proxy, SSL, Load Balancing.
ToolMesh macht KI-Agent-Tool-Calls produktionsreif — Autorisierung, Credentials, Audit, Content-Gating.
ToolMesh ist kein Harness — es ist das, was einen Harness gut macht.
Aktuelle Forschung beschreibt einen Agent-Harness in sechs Komponenten — Execution Loop, Tool Registry, Context, State, Lifecycle Hooks, Verification/Audit. ToolMesh implementiert die letzten drei, über MCP erreichbar. Bring deinen Harness mit, behalte deine Observe-Think-Act-Schleife; ToolMesh übernimmt die Tool-Governance für alle.
Zwei Wege zum Start.
In 60 Sekunden testen.
Claude Desktop, Claude Code oder ChatGPT mit unserer öffentlichen ToolMesh-Instanz verbinden — keine Installation, keine eigenen Credentials nötig. Der schnellste Weg zu erleben, wie gesteuerte Tool-Calls aussehen.
Hosted Demo öffnen Demo-Instanz — für Produktion bitte self-hosten.Eigene Instanz betreiben.
Mehrstufiges Setup, kein Zeitversprechen — klonen, .env und Backends konfigurieren, dann mit Docker Compose starten. Dein Audit-Log, deine Credentials, deine Daten.
git clone https://github.com/DunkelCloud/ToolMesh.git && cd ToolMeshcp .env.example .env.env bearbeiten — TOOLMESH_AUTH_PASSWORD, TOOLMESH_API_KEY und die CREDENTIAL_* Backend-Keys setzen. docker compose upclaude mcp add -t http -H "Authorization: Bearer MY_API_KEY" -s user toolmesh http://localhost:8123/mcpconfig/backends.yaml hinzufügen 
