DeepL hat den Customization Hub gelauncht — der offizielle MCP-Server kennt davon noch nichts

Von Axel Dunkel

DeepL hat im Mai 2026 mit dem Customization Hub eine ernstzunehmende Erweiterung der API ausgerollt: Style Rules für eine konsistente Markenstimme über alle Übersetzungen, eine Translation-Memory-API für die Wiederverwendung geprüfter Segmente, multilinguale Glossare in einer neuen v3-Architektur, ein überarbeiteter Tag-Handler und ein neuer /v3/languages-Endpoint mit Feature-Flags pro Resource. Insgesamt dreizehn neue Endpoints — für Lokalisierungsteams und alle, die DeepL produktiv einsetzen, ist das eine signifikante Aufwertung.

Für Teams, die mit KI-Agenten arbeiten, gibt es allerdings ein Detail: Der offizielle DeepL-MCP-Server bildet zum Stand 22. Mai 2026 neun Tools ab, alle auf v2-Endpoints — keines der neuen v3-Features. Die populäre Community-Alternative <code>mcp-deepl</code> steht an derselben Stelle, letztes Release vom 9. Mai 2026. Das ist keine Nachlässigkeit der Maintainer — die Architektur eines hand-codierten MCP-Servers macht es schlicht aufwendig, eine derart umfangreiche API-Erweiterung zeitnah abzubilden. Wir haben den Customization Hub in den letzten Wochen für unsere DADL-Definition durchgearbeitet und teilen drei Punkte: was die Hauptfeatures praktisch bedeuten, welche Stolperfallen aufgefallen sind, und wie sich die Abdeckungslücke schließen lässt.

Drei Features mit messbarer Wirkung

Style Rules sind pro Sprache definierte Profile für Tonfall, Anrede, Terminologie und formale Konventionen. Ein Profil “Brand voice — DE” kann etwa vorschreiben, dass jede Übersetzung mit “Sehr geehrte Damen und Herren” beginnt und der Produktname ToolMesh niemals lokalisiert wird. Diese Regeln werden direkt im Model-Output umgesetzt, nicht als nachgelagerter Filter. Referenzierung im /v2/translate-Aufruf über style_id. Verfügbar für acht Sprachen: Deutsch, Englisch, Spanisch, Französisch, Italienisch, Japanisch, Koreanisch und Chinesisch.

Translation Memory ist die klassische TM-Funktion, jetzt API-fähig: bereits geprüfte Übersetzungen werden bei neuen Aufträgen wiederverwendet, sobald die Ähnlichkeit zum Quellsegment einen konfigurierbaren Schwellwert (Default 75 %) überschreitet. Die TMs selbst werden derzeit ausschließlich in der DeepL-Web-Oberfläche angelegt und befüllt — der API-Endpoint /v3/translation_memories ist read-only. Referenz im Übersetzungsaufruf über translation_memory_id. Für Workflows mit hohem Wiederholungsanteil — Handbücher, Produkttexte, juristische Verträge — ist das ein direkter Kostenfaktor. Pro-Plan-Feature.

Multilingual Glossaries (v3) lösen die alte einsprachige Glossar-Struktur ab. Bisher trug ein Glossar genau ein Sprachpaar; jetzt kann ein einzelnes Glossar mehrere Quelle → Ziel-Wörterbücher tragen — also etwa EN→DE, DE→EN, EN→FR und DE→FR in einem Container. Wer Firmenterminologie über mehrere Sprachen pflegt, hatte bisher mit jeder Ziel-Sprache ein neues Glossar, separate UUIDs, separate API-Aufrufe. Jetzt: ein Container, ein Update, eine Quelle.

Drei Stolperfallen, die in den Docs nicht prominent stehen

configured_rules-Enums sind sprachspezifisch. Die Doku zeigt schöne Beispiele mit Schlüsseln wie punctuation.quotes oder style_and_tone.formality. Diese Schlüssel sind aber je nach Sprache zugelassen oder nicht — für de etwa wird quotes mit einem 400 abgewiesen, ebenso style_and_tone.formality. Wer Doku-Beispiele blind kopiert, bekommt einen Fehler. Pragmatischer Workaround: bei Unsicherheit configured_rules weglassen und stattdessen custom_instructions (freie Prompts) verwenden — die sind für alle acht Style-Rules-Sprachen zugelassen.

DeepL Write ist eine separate Subscription. Der Rephrase-Endpoint /v2/write/rephrase verbessert Texte in derselben Sprache, statt zu übersetzen — auf den ersten Blick ein normales Translate-API-Feature, ist es aber nicht. Free- und Standard-API-Pläne bekommen ein 403; DeepL Write API ist als eigenes Produkt zu buchen. Wer den Endpoint in einer DADL anbietet, sollte das im Tool-Beschreibungstext klar machen.

Sprachcode-Casing wechselt zwischen v2 und v3. /v2/translate erwartet Ziel-Sprachcodes in Großbuchstaben (EN-US, DE, PT-BR). Die neuen v3-Glossaries und Style Rules erwarten Kleinbuchstaben (en, de, pt-BR). Beide Formen sind innerhalb ihres Endpoints konsistent — aber wer mehrere Aufrufe chained, läuft schnell in einen 400. Eine DADL kann das pro Tool sauber typisieren; ein hand-codierter Client muss es einmal pro Endpoint richtig hinbekommen.

Dass es funktioniert

Der praktische Test: Style Rule anlegen, mit style_id referenzieren, prüfen ob die custom_instructions im Output ankommen. Round-Trip in zwei Aufrufen:

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 Aufrufe, kein Wrapper-Code im Aufrufer. Die DADL-Schicht kümmert sich um das ungewöhnliche DeepL-Auth-Key-Schema, das oben beschriebene Casing, den impliziten Modellwechsel auf quality_optimized beim Setzen von style_id, und die Retry-Behandlung bei 429 und 529.

Wie sich die Lücke schließen lässt

Wir bauen ToolMesh — das ist also kein neutraler Hinweis, sondern Kontext für die Einordnung. Aber die Zahlen sind verifizierbar, weil beide Repositorien öffentlich sind: Unsere <code>deepl.dadl</code> im dadl-registry deckt aktuell 27 Tools ab — die alten v2-Endpoints, alle dreizehn neuen Customization-Hub-Endpoints, plus Multilingual Glossaries v3 (CRUD), Style Rules (CRUD inkl. Custom Instructions), Translation Memory (Listing), das neue /v3/languages und Usage. Das Format ist YAML-deklarativ; die DADL-Spec ist offen.

Wenn DeepL morgen einen weiteren Endpoint nachschiebt: Pull Request gegen das dadl-registry, Validierung läuft, Merge — fertig. Kein Node-Release, kein npm-Publish, kein eigener Server, der gehostet werden will. Wer eine ToolMesh-Instanz im Haus hat, sieht die neuen Tools beim nächsten Reload.

Eine ehrliche Einschränkung: DeepLs Voice-Übersetzung ist eine WebSocket-basierte Streaming-Schnittstelle und lässt sich nicht deklarativ in DADL beschreiben. Für die REST-Surface — und das ist alles, was der Customization Hub liefert — deckt eine DADL-Datei den Bedarf vollständig ab.

Der offizielle deepl-mcp-server ist nicht falsch. Er ist das richtige Werkzeug für ein bestimmtes Szenario: ein lokal laufender MCP-Server für Claude Desktop, Cursor oder Continue, in dem die DeepL-Logik direkt vor dem Modell läuft. Wenn aber das Kriterium “schneller Zugriff auf neue API-Features, ohne auf das nächste Server-Release zu warten” lautet, ist das deklarative Format strukturell im Vorteil.

Companion-Artikel: Den technischen Build-Log mit Coverage-Vergleich, Wartungsaufwand-Asymmetrie und Code-Mode-Argumentation gibt es auf Englisch unter toolmesh.io/en/blog/deepl-v3-customization-hub-in-one-yaml-file . Anfragen zu Pilotinstallationen oder fachlicher Diskussion: [email protected].