Anonymisierte Case Study

Vertraulicher MCP-Server für einen redaktionellen Workflow

Der Kunde darf nicht genannt werden. Veröffentlichbar: wie die MCP-Grenze gezogen wurde, warum die menschliche Freigabe Pflicht blieb, und wie Kostenkontrolle vom ersten Tag eingebaut statt nach der ersten Rechnung nachgerüstet wurde.

Ausgangslage

Ein Redaktionsteam produzierte mehrsprachige Long-Form-Inhalte. Sie wollten KI-Unterstützung beim Entwurf und der Übersetzung, lehnten aber zwei Dinge ab: undurchsichtige Kosten und unbeaufsichtigtes Veröffentlichen. Beide Ablehnungen sind vernünftig.

Der Brief lautete: Gebt uns KI-Tools, die wir auditieren können, die uns nicht mit einer fünfstelligen Rechnung überraschen und die nichts veröffentlichen, das kein Mensch freigegeben hat.

Warum MCP statt direkter API-Aufrufe

Direkte Aufrufe an Anthropic oder OpenAI aus WordPress-Code hätten funktioniert. Sie hätten auch Credentials über Plugins verteilt, Kosten pro Feature versickern lassen und das Audit unrealistisch gemacht.

MCP gab eine Grenze: Die WordPress-Installation der Redaktion spricht mit einem MCP-Server, der MCP-Server spricht mit Modellanbietern, und jeder Tool-Aufruf ist typisiert, geloggt und scoped.

Tool-Design

Jedes Tool war mit Zod typisiert und nach der redaktionellen Handlung benannt: suggest_outline, draft_section, translate_to_locale, evaluate_against_voice. Jedes hatte klares Input-Schema, Output-Schema und Side-Effect-Deklaration.

Tools, die Inhalt produzierten, schrieben nie direkt in wp_posts. Sie schrieben in eine Draft-Queue. Ein Mensch gab vor der Veröffentlichung frei.

Kostenkontrolle im Design

Pro-Nutzer-, Pro-Tool- und Pro-Tag-Budgets wurden an der MCP-Grenze durchgesetzt, nicht beim API-Aufruf. Erreichte ein Nutzer das Limit, gab der nächste Aufruf eine Budget-erschöpft-Antwort zurück, und das redaktionelle UI zeigte das an. Keine stillen Überschreitungen.

Dieselbe Grenze lieferte Kostenreports pro Locale, pro Themencluster und pro Tool. Finance hatte ein einziges Dashboard.

Ergebnisbereiche

Exakte Zahlen sind vertraulich. Veröffentlichbar: Editorial Throughput verbesserte sich bei Übersetzungsaufgaben, Time-to-First-Draft sank bei Long-Form-Briefs, und die Kosten blieben dank der harten Caps jeden Monat im vereinbarten Budget.

Wiederverwendbare Lektion: KI in der Redaktion funktioniert, wenn die Grenze typisiert und das Budget durchgesetzt ist, nicht wenn der Prompt clever ist. Die meisten gescheiterten KI-Redaktionstools scheitern an der Grenze, nicht am Modell.

Häufig gestellte Fragen

Hätten wir die OpenAI Assistants API statt MCP nehmen können?

Ja. Das Team wählte MCP, weil es offen, herstellerneutral ist und derselbe Server später andere KI-Clients bedienen lässt. MCP ist im Tech Radar Q4 2026 deshalb der Adopt-Eintrag im Tools-Quadranten.

Hat das Redakteure ersetzt?

Nein. Es ersetzte erste Entwürfe und Übersetzungs-Routine. Redakteure gewannen die Zeit zurück, die sie dort verbrachten, und steckten sie in Review, Urteil und Headline-Arbeit.

Was passiert, wenn das Modell falsch liegt?

Die Draft-Queue fängt das ab. Menschliche Freigabe ist Pflicht. Sinn typisierter MCP-Tools und der Freigabe-Schritt ist genau, Modellfehler billig zu machen, statt sie ausliefern zu lassen.

Funktioniert derselbe Ansatz für Support oder Kundenservice?

Ja, mit anderem Tool-Design. Das Muster ist: typisierte Tools, scoped Auth, harte Budgets, menschliche Freigabe für alles Kundenseitige. Redaktion ist eine Anwendung des Musters. Support eine andere.

Möchten Sie eine MCP-Grenze für Ihr Redaktionsteam?

Senden Sie den aktuellen redaktionellen Workflow, die Locale-Matrix und die Budgetobergrenze. Ich sage, ob MCP seine Komplexität für Ihr Team rechtfertigt oder eine kleinere Integration genügt.

MCP-Skizze anfragen