Zum Inhalt springen
ToolMesh
Blog

DeepL v3 Customization Hub — in einer DADL abgedeckt

Axel Dunkel

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

Abschnitt betitelt „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

Abschnitt betitelt „Die Zahlen“
DADL (deepl.dadl)deepl-mcp-server (offiziell)
Tools279
CoverageTextübersetzung, Dokumentübersetzung, mehrsprachige v3-Glossare, Style Rules CRUD, Custom Instructions CRUD, TM-Listing, Write/Rephrase, /v3/languages, Usagetranslate-text, rephrase-text, translate-document, list-glossaries, get-glossary-info, get-glossary-dictionary-entries, get-source-languages, get-target-languages, get-writing-styles
Verteilung38 KB YAMLNode.js-Server (TypeScript SDK, Build-Schritt, Runtime zum Hosten)
Neuen Endpoint hinzufügen~30 Zeilen YAMLTool-Definition + Request-Handler + Tests + Release
v3 Customization Hub Coveragevollständigheute 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

Abschnitt betitelt „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

Abschnitt betitelt „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:

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

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

  1. Das TypeScript SDK aktualisieren, um die neuen Request- und Response-Shapes abzubilden.
  2. Tool-Definitionen und Request-Handler hinzufügen (einer pro Endpoint).
  3. Tests schreiben oder erweitern.
  4. Release schneiden. Taggen. Auf npm publizieren.
  5. Nutzern sagen, dass sie upgraden sollen. Auf sie warten.
  6. 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

Abschnitt betitelt „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 24 Backends mit 3.115 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

Abschnitt betitelt „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

Abschnitt betitelt „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

Stichwörter: