# DeepL v3 Customization Hub — in einer DADL abgedeckt

> DeepL hat gerade 13 neue REST-Endpoints ausgerollt — Style Rules, mehrsprachige Glossare, Translation Memory, /v3/languages, tag_handling v2. Der offizielle MCP-Server hat heute keinen davon. Wir haben alle in einer 38 KB großen DADL abgedeckt. Hier ist das Build-Log.

Canonical: https://www.toolmesh.io/de/blog/deepl-v3-customization-hub-in-one-yaml-file/

Ende Mai hat DeepL den [Customization Hub](https://www.deepl.com/en/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`](https://github.com/DeepLcom/deepl-mcp-server) immer noch neun Tools — alle v2 — und die Community-Alternative [`mcp-deepl`](https://github.com/NimbleBrainInc/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`](https://github.com/DunkelCloud/dadl-registry/blob/main/deepl.dadl). Gemergt in [PR #34](https://github.com/DunkelCloud/dadl-registry/pull/34). Die DADL-Spec selbst: [dadl.ai/spec](https://dadl.ai/spec/dadl-spec-v0.1.md).

## 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:

```js
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:**

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](/de/blog/dadl-the-end-of-mcp-server-boilerplate/) 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 {{registry.apis}} Backends mit {{registry.tools}} 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](https://www.dunkel.cloud/de/blog/deepl-customization-hub-via-dadl/)