Von MCP-Demos zu MCP-Produktion (Teil 1): Das Pinterest-Muster in der Architektur

Viele MCP-Demos sehen im Video beeindruckend aus – und scheitern dann im Alltag an Ownership, Sicherheitsgrenzen oder fehlender Betriebsdisziplin. Genau deshalb ist das Pinterest-Beispiel so relevant: Dort wird MCP nicht als Showcase betrieben, sondern als produktionsnahes Ökosystem für reale Engineering-Workflows.

Diese Serie schaut bewusst nicht auf “noch einen Agenten-Quickstart”, sondern auf ein Muster, das Teams mit mehreren Produkten und Domänen wirklich einsetzen können. Teil 1 fokussiert auf die Architekturentscheidung, die fast alles danach bestimmt: ein großer MCP-Server oder viele domänenspezifische Server?

Darum Pinterest als Blueprint taugt

Pinterest beschreibt ein Setup mit Registry, klaren Zuständigkeiten und Human-in-the-loop-Mechanismen. Das ist deshalb wichtig, weil MCP in größeren Umgebungen nicht am “Tool-Aufruf” scheitert, sondern an Governance-Fragen:

Wer darf welche Aktion überhaupt anbieten?
Wie werden sensible Aktionen abgesichert?
Wie bleibt sichtbar, was geändert wurde und warum?
Wie verhindert man, dass ein Team-Shortcut zur globalen Sicherheitslücke wird?

Der Kernpunkt: Produktionsreife ist organisatorische Architektur plus technische Architektur. Nur eins von beidem reicht nicht.

Architekturentscheidung #1: Monolith vs. Domänen-Server

In vielen Firmen startet MCP als zentraler “Power-Server”, der alles kann. Das wirkt am Anfang effizient – wird aber schnell schwer steuerbar. Pinterests Muster zeigt den Gegenentwurf: viele fachliche Server, sauber über eine Plattformschicht verbunden.

Variante A: Ein monolithischer MCP-Server

Vorteile: schneller Start, einfache Demo, nur ein Endpunkt für Clients.
Nachteile: Rechte wachsen unstrukturiert, Releases koppeln zu viel, Fehler haben großen Blast Radius.

Ein Monolith ist okay für die erste Woche, aber selten für das zweite Quartal.

Variante B: Domänenspezifische MCP-Server

Vorteile: klare Ownership je Team, kleinere Sicherheitszonen, unabhängige Release-Zyklen.
Vorteile: bessere Auditierbarkeit, klarere Verträge für Inputs/Outputs, weniger Seiteneffekte.
Nachteile: mehr Plattformarbeit zu Beginn (Registry, Standards, Onboarding, Quality Gates).

Für produktive Umgebungen mit mehreren Teams ist die zweite Variante in der Regel robuster – nicht weil sie “schöner” ist, sondern weil sie Betrieb und Verantwortung entzerrt.

Das pragmatische Zielbild: Plattformkern + Domänenmodule

Ein belastbares Setup besteht meist aus vier Ebenen:

Registry-Layer: Katalog aller MCP-Server inkl. Metadaten, Versionen, Owner, Risiko-Klasse.
Domänen-Server: klar abgegrenzte Server pro Fachbereich (z. B. Billing, Deployments, CRM, Incident).
Policy-Schicht: Regeln für sensible Aktionen (Bestätigung, Rollen, Elicitation, ggf. 4-Augen-Freigabe).
Observability: Messung von Nutzung, Fehlern, Latenz, Abbrüchen und Security-Events.

Damit wird MCP von “Tool-Sammlung” zu einer kontrollierbaren Integrationsfläche für Agenten.

Typische Anti-Patterns (und wie man sie früh verhindert)

1) “Wir legen erstmal alles in einen Server”

Kurzfristig spart das Zeit, mittelfristig verliert man Kontrolle. Besser: früh Domain-Schnitte setzen und Ownership dokumentieren.

2) Keine Risikoklassen für Tools

Wenn “Ticket lesen” und “Production-Rollout anstoßen” gleich behandelt werden, ist das ein Governance-Fehler. Definiere Tool-Klassen (read-only, write-low-risk, write-high-risk) und binde sie an Policies.

3) Keine produktionsnahe Telemetrie

Ohne saubere Logs bleibt unklar, ob ein Agent wegen Prompt, Tool-Vertrag oder Berechtigung scheitert. Resultat: lange Debug-Zyklen und schlechte Lernkurven.

4) Teamübergreifende Abhängigkeiten ohne Versionierung

Wenn ein Server Inputs ändert und drei Clients brechen still, fehlt ein Vertrag. Versioniere Tool-Schemas, kommuniziere Breaking Changes und plane Migrationsfenster.

Ein 30-Tage-Plan für den Architektur-Start

Wenn ihr aus der Demo-Phase in echten Betrieb wollt, funktioniert dieses Raster gut:

Woche 1: 2–3 Domänen wählen, Owner benennen, Risiko-Klassen definieren.
Woche 2: Registry + Mindeststandard für Tool-Definitionen einführen.
Woche 3: Policies für sensible Aktionen aktivieren (Bestätigung, Rollen, Elicitation).
Woche 4: Telemetrie auswerten, Fehlermuster clustern, Verträge nachschärfen.

Wichtig: Nicht zuerst alles bauen. Erst wenige Domänen sauber aufsetzen, dann skalieren.

Was du aus Teil 1 mitnehmen solltest

Produktive MCP-Landschaften sind primär ein Plattform- und Governance-Thema.
Viele klar abgegrenzte Server sind langfristig oft stabiler als ein Alleskönner.
Registry, Ownership und Policy sind kein “Enterprise-Ballast”, sondern die Grundlage für Geschwindigkeit ohne Chaos.

Ausblick auf Teil 2

Im nächsten Teil geht es konkret um Governance & Security: Registry-Regeln, Rollenmodelle, sensible Aktionen und wie Elicitation im Alltag Fehlbedienung reduziert, ohne Teams zu blockieren.

Quellen

Mini-Case: So sieht der Unterschied im Alltag aus

Nehmen wir ein typisches Szenario: Ein Agent soll für ein Incident die Ursache eingrenzen, ein Ticket aktualisieren und – wenn nötig – einen Rollback vorbereiten. In einem Monolithen landet diese Kette oft in einem einzigen Tool-Baukasten mit breiten Rechten. Das ist schnell, aber riskant: Kleine Fehler im Prompt oder in der Tool-Auswahl können unverhältnismäßig große Wirkung haben.

Im Domänenmodell läuft derselbe Prozess kontrollierter:

Der Observability-Server liefert nur Diagnose-Daten (read-only).
Der Ticketing-Server darf Status/Kommentare schreiben, aber keine Produktionsaktionen auslösen.
Rollback-Tools liegen in einer separaten Domäne mit expliziter Bestätigung und Rollenprüfung.

Das Ergebnis ist nicht nur mehr Sicherheit. Es verbessert auch die Zuverlässigkeit: Wenn ein Teilpfad ausfällt, bricht nicht automatisch der ganze Workflow.

Architektur-Checklist für den Start

Wenn ihr gerade aufsetzt, könnt ihr diese kurze Checklist direkt verwenden:

Ownership: Jeder Server hat einen klar benannten Owner + Vertretung.
Tool-Verträge: Inputs/Outputs dokumentiert, inklusive Fehlercodes und Side-Effects.
Risikostufe: Jedes Tool ist als read, write-low-risk oder write-high-risk klassifiziert.
Policies: High-Risk-Tools brauchen Bestätigung und rollenbasierte Freigabe.
Versionierung: Breaking Changes nur mit Version + Migrationshinweis.
Beobachtbarkeit: Logging, Latenz, Fehlerraten, Abbruchgründe und Security-Events messbar.
Rollback: Für kritische Tool-Änderungen gibt es einen klaren Rückfallpfad.

Wenn drei oder mehr Punkte bei euch noch offen sind, lohnt sich ein kurzer Plattform-Sprint vor der nächsten Feature-Welle. Das spart später sehr viel Debug- und Abstimmungszeit.

Weiterlesen im Blog

Passend dazu: Für aktuelle Entwicklungen findest du laufende Updates in den LLM News; den Überblick über Serien und Deep Dives gibt’s im Artikel-Hub.