ToolMesh — Ermöglichen Sie KI-Agenten den Zugriff auf echte Systeme. Sicher.

Die fehlende Steuerungsebene zwischen KI-Agenten und Unternehmenssystemen. ToolMesh verwandelt unkontrollierte KI-Tool-Aufrufe in einen gesteuerten, prüfbaren Prozess – und verbindet jede REST-API oder jeden MCP-Server in Minuten, nicht Monaten.

30 Zeilen YAML. Kein Server zu bauen.

In der Praxis machen MCP-Server nur einen Bruchteil der REST-API verfügbar, die sie umschließen – und Sie werden schnell auf die Lücken stoßen. Mit ToolMesh können Sie die Wrapper-Schicht durch .dadl-Dateien ersetzen – ein deklaratives YAML-Format, das jede REST-API als MCP-Tools beschreibt. Kein Wrapper-Server muss gebaut, bereitgestellt oder gewartet werden.

Current:    Claude → ToolMesh → MCP Server → REST API
With DADL:  Claude → ToolMesh → REST API (via .dadl file)

Sie schreiben das YAML nicht von Hand. Sie fragen ein LLM. Claude, GPT, Gemini – jedes Modell, das die DADL-Spezifikation kennt, generiert in Sekunden eine funktionierende .dadl-Datei. Beschreiben Sie, was Sie benötigen, legen Sie die Datei in config/dadl/, fertig.

"Erstelle ein DADL für die GitHub-API – Repos auflisten, Issues öffnen und Pull Requests erstellen."

10 Sekunden. Funktioniert mit jedem LLM, das das Format kennt.

Und im Gegensatz zu MCP-Gateways, die Tool-Aufrufe nur durchleiten, fügt ToolMesh hinzu, was Produktionsbereitstellungen tatsächlich benötigen:

• Credential-Sicherheit – Secrets werden zur Ausführungszeit injiziert, niemals in Prompts oder LLM-Client-Konfigurationen

• Autorisierung – fein abgestufte Benutzer → Plan → Tool-Steuerung (OpenFGA)

• Input & Output Gating – JS-Richtlinien blockieren vertrauliche Daten und filtern Antworten

• Audit-Trail – jeder Tool-Aufruf wird mit strukturiertem Logging oder abfragbarem SQLite aufgezeichnet

Related MCP server: MCPGate

Die sechs Säulen

Demo ausprobieren

Möchten Sie ToolMesh vor der Installation ausprobieren? Verbinden Sie sich mit unserer öffentlichen Demo-Instanz – kein Docker, keine Konfiguration, keine API-Keys:

demo.toolmesh.io – Hacker News APIs via ToolMesh. Funktioniert mit Claude Desktop, Claude Code und ChatGPT. Login: dadl / toolmesh.

Quickstart

# Clone
git clone https://github.com/DunkelCloud/ToolMesh.git
cd ToolMesh

# Configure
cp .env.example .env
# IMPORTANT: Set a password — without it, all requests are rejected:
#   TOOLMESH_AUTH_PASSWORD=my-secret-password
# Or set an API key for programmatic access:
#   TOOLMESH_API_KEY=my-api-key

# Optional: local overrides (build locally, enable OpenFGA, HTTPS proxy, ...)
# cp docker-compose.override.yml.example docker-compose.override.yml
# # then edit docker-compose.override.yml — picked up automatically by Docker Compose

# Start (runs in bypass mode by default — no authz required)
docker compose up -d

# Verify it's running (default port: 8123)
curl http://localhost:8123/health

# MCP endpoint: http://localhost:8123/mcp
# Note: Most MCP clients require HTTPS — see TLS section below

TLS (wichtig)

ToolMesh selbst liefert einfaches HTTP aus. Die meisten MCP-Clients – einschließlich Claude Desktop – erfordern HTTPS und lehnen http://-URLs ab. Sie benötigen einen TLS-terminierenden Reverse-Proxy vor ToolMesh:

Nur für die lokale Entwicklung können Sie TLS umgehen, indem Sie claude_desktop_config.json manuell bearbeiten (die GUI erzwingt https://).

Verbindung zu Claude Desktop

Fügen Sie dies zu Ihrer Claude Desktop MCP-Konfiguration hinzu:

{
  "mcpServers": {
    "toolmesh": {
      "url": "https://toolmesh.example.com/mcp"
    }
  }
}

Für die lokale Entwicklung ohne TLS-Proxy:

{
  "mcpServers": {
    "toolmesh": {
      "url": "http://localhost:8123/mcp"
    }
  }
}

Verbindung zu Claude.ai (Custom Connector)

ToolMesh unterstützt OAuth 2.1 mit PKCE S256 für den Fernzugriff. Konfigurieren Sie Benutzer in config/users.yaml und verwenden Sie die öffentliche HTTPS-URL als MCP-Endpunkt.

Authentifizierung

ToolMesh unterstützt zwei Authentifizierungsmethoden, die unabhängig oder zusammen verwendet werden können. Der gesamte OAuth-Status (Token, Auth-Codes, Clients) wird in Redis gespeichert und überlebt Server-Neustarts.

OAuth 2.1 (Interaktiver Login)

Definieren Sie Benutzer in config/users.yaml mit bcrypt-gehashten Passwörtern:

users:
  - username: admin
    password_hash: "$2a$10$..."
    company: dunkelcloud
    plan: pro
    roles: [admin]

Generieren Sie Passwort-Hashes mit jedem bcrypt-fähigen Dienstprogramm:

htpasswd -nbBC 10 "" "my-password" | cut -d: -f2

Für Single-User-Setups funktioniert TOOLMESH_AUTH_PASSWORD weiterhin als Fallback. Konfigurieren Sie die Identität mit TOOLMESH_AUTH_USER, TOOLMESH_AUTH_PLAN und TOOLMESH_AUTH_ROLES (Standardwerte: owner, pro, admin).

API-Keys (Programmatischer Zugriff)

Definieren Sie API-Keys in config/apikeys.yaml mit bcrypt-gehashten Keys:

keys:
  - key_hash: "$2a$10$..."
    user_id: claude-code-user
    company_id: dunkelcloud
    plan: pro
    roles: [tool-executor]

Jeder Key wird einer eindeutigen Benutzeridentität mit eigenem Plan und eigenen Rollen zugeordnet, die in die OpenFGA-Autorisierung einfließen.

Für Single-Key-Setups funktioniert TOOLMESH_API_KEY weiterhin als Fallback. Die gleichen Variablen TOOLMESH_AUTH_USER, TOOLMESH_AUTH_PLAN und TOOLMESH_AUTH_ROLES steuern die Identität.

DCR Rate Limiting

Die dynamische Client-Registrierung (DCR) ist auf 5 Registrierungen pro Stunde und IP begrenzt, um Missbrauch zu verhindern.

Autorisierungsmodus

OPENFGA_MODE steuert, ob die OpenFGA-Autorisierung erzwungen wird:

Starten Sie mit bypass, um schnell loszulegen, und wechseln Sie dann nach dem Bootstrapping von OpenFGA zu restrict.

Konfiguration

Siehe docs/configuration.md für alle Umgebungsvariablen.

Timeout-Anpassung

Erhöhen Sie diese Werte für Backends, die mehr Zeit benötigen (z. B. browserbasierte Web-Fetcher):

TOOLMESH_MCP_TIMEOUT=180
TOOLMESH_EXEC_TIMEOUT=180

Logging

ToolMesh verwendet strukturiertes Logging via slog. Die Standardstufe ist debug für volle MCP-Nachvollziehbarkeit von Anfang an – setzen Sie LOG_LEVEL=info oder höher für die Produktion, da Debug-Logs vollständige Request/Response-Payloads enthalten. Backend-spezifische Debug-Dateien, Log-Formate und alle Logging-Variablen sind in docs/configuration.md dokumentiert.

Architektur

Siehe docs/architecture.md für die vollständige Architekturdokumentation.

                          ┌─────────────────────────────────┐
                          │          ToolMesh               │
                          │                                 │
                          │  Redis · OpenFGA · Audit        │
                          │  Credential Store · JS Gate     │
                          │                                 │
AI Agent ──MCP──────────▶ │   AuthZ ▸ Creds ▸ Gate ▸ Exec  │
                          │                                 │
                          └──┬──────┬───────┬───────┬───────┘
                             │      │       │       │
                          MCP Client  .dadl   .dadl   .dadl
                             │      │       │       │
                             ▼      ▼       ▼       ▼
                          MCP     Stripe  GitHub  Vikunja
                          Server   API     API     API

Hinzufügen eines externen MCP-Servers

Erstellen oder bearbeiten Sie config/backends.yaml:

backends:
  - name: memorizer
    transport: http
    url: "https://memorizer.example.com/mcp"
    api_key_env: "MEMORIZER_API_KEY"

Setzen Sie das Credential als Umgebungsvariable:

CREDENTIAL_MEMORIZER_API_KEY=sk-mem-xxxxx

Tools von jedem Backend werden mit einem Präfix bereitgestellt (z. B. memorizer_retrieve_knowledge). Credentials werden zur Laufzeit vom Executor über den CredentialStore injiziert – das LLM sieht niemals API-Keys.

REST-Proxy-Modus (DADL)

Wenn ein MCP-Server einen benötigten Endpunkt nicht bereitstellt, beschreiben Sie ihn in einer .dadl-Datei und ToolMesh ruft die REST-API direkt auf – kein Wrapper-Server erforderlich. Beide Modi laufen parallel.

Fügen Sie ein REST-Backend zu config/backends.yaml hinzu:

backends:
  - name: vikunja
    transport: rest
    dadl: /app/dadl/vikunja.dadl
    url: "https://vikunja.example.com/api/v1"

Für interne Dienste mit privaten IPs oder selbstsignierten Zertifikaten:

backends:
  - name: internal-api
    transport: rest
    dadl: internal.dadl
    url: "https://192.168.1.50:8443/api"
    allow_private_url: true    # allow private/loopback addresses (default: true)
    tls_skip_verify: true      # accept self-signed certificates (default: false)

Möchten Sie, dass Claude GitHub-Issues auflistet? Das ist alles, was nötig ist:

tools:
  list_issues:
    method: GET
    path: /repos/{owner}/{repo}/issues
    description: "List issues for a repository"
    params:
      owner: { type: string, in: path, required: true }
      repo:  { type: string, in: path, required: true }
      state: { type: string, in: query }

ToolMesh übernimmt Authentifizierung, Paginierung, Wiederholungsversuche und Fehlerzuordnung. DADL unterstützt Bearer-Token, OAuth2, Session-Auth, API-Keys, automatische Paginierung, Wiederholung mit Backoff, Antworttransformation, zusammengesetzte Tools und mehr.

Für die vollständige Spezifikation, Beispiele und das Community-Register siehe dadl.ai. Der schnellste Weg, eine .dadl-Datei zu erstellen, ist, jedes LLM zu fragen, das das Format kennt.

Code Mode

15 MCP-Server mit einem einzigen KI-Agenten verbinden? Ohne ToolMesh funktioniert das einfach nicht – das Kontextfenster füllt sich, der Client überlastet. Der Code Mode macht es möglich.

Anstatt Hunderte einzelner Tool-Definitionen (50.000+ Token) offenzulegen, stellt ToolMesh zwei Meta-Tools bereit: list_tools und execute_code. Das LLM erhält kompakte TypeScript-Schnittstellen (~1.000 Token) und schreibt JavaScript dagegen:

const repos = await toolmesh.github_list_repos({ sort: "updated" });
const issues = await toolmesh.github_list_issues({
  owner: repos[0].owner.login,
  repo: repos[0].name,
  state: "open"
});

Mehrere API-Aufrufe in einem einzigen Round-Trip. ToolMesh parst den Code, extrahiert Tool-Aufrufe und leitet sie durch die vollständige Ausführungspipeline.

Erweiterungsmodell

ToolMesh verwendet ein registerbasiertes Erweiterungsmodell, das vom database/sql-Treiber-Muster von Go inspiriert ist. Drei Komponententypen sind über init()-Registrierung erweiterbar:

Unternehmenserweiterungen (InfisicalStore, VaultStore, Compliance-LLM usw.) sind geplant und werden über Go-Build-Tags eingebunden: go build -tags enterprise ./cmd/toolmesh.

Siehe docs/architecture.md für Details.

Mitwirken

Siehe CONTRIBUTING.md.

Lizenz

Apache 2.0 — Copyright 2025–2026 Dunkel Cloud GmbH