Der MCP-Werkzeugwildwuchs bricht bereits Teams: Wie Sie eine Laufzeitumgebung für Agenten statt 10 inkompatibler Werkzeuge wählen

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und ich liefere mit DennisCraft AI Studio produktive KI-Systeme auf Basis von Claude, Supabase, n8n, Doppler und self-hosted Postgres. Das häufigste Problem, das ich derzeit in Projekten sehe, ist nicht die Modellqualität, sondern ein sehr praktischer Bruch: Ein Team verbindet MCP-Server, Arbeitsabläufe, lokale Hilfsprogramme und Modell-SDKs, zeigt eine saubere Demo und verliert danach Wochen an Rechteproblemen, Zeitüberschreitungen, uneinheitlichen Fehlermeldungen und fehlender Nachvollziehbarkeit im Produktivbetrieb.

MCP ist dabei nicht der Fehler. Der Fehler ist Werkzeugwildwuchs. Sobald jeder Teil des Stacks ein eigenes Ausführungsmodell, ein eigenes Fehlerformat, eine eigene Authentisierung und einen eigenen Zustandsspeicher mitbringt, entsteht kein verlässliches Agentensystem mehr, sondern eine Ansammlung von Übergängen. In regulierten Umgebungen wird das sehr schnell zu einem Prüfungs- und Haftungsthema.

Warum Werkzeugwildwuchs früher schadet als Modellfehler

Viele Teams erwarten den ersten Ausfall in der fachlichen Schlussfolgerung des Modells. In realen Systemen sehe ich häufiger etwas anderes: Das Modell wählt die richtige Aktion, aber der Werkzeug-Wrapper liefert ein anderes Format als erwartet, ein Arbeitsablauf läuft in eine Zeitüberschreitung, ein Geheimnis wurde an einer Stelle rotiert und an einer anderen nicht, oder ein Seiteneffekt wird ohne Berechtigungsprüfung ausgeführt.

Die Dokumentation von Anthropic zu Tool Use und Model Context Protocol ist deshalb hilfreich, weil sie zu standardisierten Werkzeugdefinitionen und zu vorhersehbarem Kontextaustausch führt. Quelle: Anthropic Docs, 2025, https://docs.anthropic.com/. Für den Produktivbetrieb ist das wichtiger als ein weiterer Konnektor. In mehreren aktuellen Projekten lagen die teuersten Fehler nicht im Denken des Modells, sondern in der Ausführungsschicht zwischen Modell und Infrastruktur.

Typische Anzeichen für Werkzeugwildwuchs

Was eine Laufzeitumgebung für Agenten tatsächlich leisten muss

Ich verwende den Begriff bewusst eng. Eine Laufzeitumgebung ist weder nur ein SDK noch nur ein Protokoll. Sie ist die Ausführungsschicht, die eine Werkzeugentscheidung entgegennimmt, validiert, Regeln anwendet, Wiederholungen und Zeitgrenzen steuert, Zustandswechsel protokolliert und genügend Daten für spätere Prüfung speichert. Wenn diese Schicht fehlt, haben Sie keine Laufzeitumgebung, sondern Integrationen.

In meinem Stack übernimmt Claude oder das Anthropic SDK in der Regel die Auswahl der Werkzeuge. Postgres oder Supabase speichert Zustand und Prüfspur. n8n führt geschäftsnahe Arbeitsabläufe aus, wenn sichtbare Orchestrierung sinnvoll ist. Doppler verwaltet Geheimnisse. Entscheidend ist, dass das Modell nur einen stabilen Ausführungsvertrag sieht und nicht fünf voneinander getrennte Teilsysteme.

Ein minimales Werkzeugschema mit echtem SDK

from anthropic import Anthropic
import os, json

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

tools = [{
    "name": "create_invoice",
    "description": "Create invoice in ERP",
    "input_schema": {
        "type": "object",
        "properties": {
            "customer_id": {"type": "string"},
            "amount": {"type": "number"}
        },
        "required": ["customer_id", "amount"]
    }
}]

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=800,
    tools=tools,
    messages=[{"role": "user", "content": "Create invoice for C-102 with 1200 EUR"}]
)

print(json.dumps(response.model_dump(), indent=2))

Dieser Ausschnitt löst die Orchestrierung noch nicht vollständig. Er zeigt aber den Kern: ein explizites Schema, ein expliziter Modellaufruf und kein freiformatiger Textparser als Schein-API. Darauf können Sie Richtlinien, Prüfungen und Protokollierung sauber aufsetzen.

Wie Sie eine Laufzeitumgebung statt 10 Werkzeuge auswählen

Ich würde nicht mit der Zahl der verfügbaren Integrationen beginnen, sondern mit fünf strengeren Kriterien.

1. Ein Standard für Werkzeugdefinitionen

Wenn ein Teil Ihres Systems Werkzeuge per JSON Schema definiert und ein anderer Teil über Prompt-Konventionen arbeitet, ist Abweichung vorprogrammiert. Ein- und Ausgaben sowie Fehlerfälle brauchen einen gemeinsamen Vertrag.

2. Nachvollziehbarkeit auf Aktionsebene

Sie sollten erkennen können, welcher Agent welches Werkzeug mit welchen Parametern aus welchem Zustand unter welcher Regelentscheidung aufgerufen hat und welcher Seiteneffekt daraus entstand. Ohne diese Kette wird Ursachenanalyse zur Vermutung.

3. Zustand außerhalb des Modells

Kritischer Zustand darf nicht nur im Kontextfenster leben. Legen Sie ihn in Postgres oder Supabase ab, mit Versionierung und klarer Zuständigkeit. Sonst werden Wiederanläufe und Wiederherstellung unzuverlässig.

4. Richtlinienprüfung vor Seiteneffekten

Das Modell sollte nicht eigenständig entscheiden, ob es Auszahlungen ändert, E-Mails versendet oder personenbezogene Daten abruft. Diese Entscheidung gehört in eine getrennte Regel- und Prüfebene. Das ist nicht nur technisch sinnvoll, sondern in DACH-Kontexten auch im Sinne von DSGVO, ISO 27001, BSI Grundschutz und perspektivisch EU AI Act gut begründbar.

type ToolCall = { name: string; input: Record<string, unknown> };

export function allowTool(call: ToolCall, role: string): boolean {
  const restricted = ["send_email", "update_payout", "delete_record"];
  if (restricted.includes(call.name) && role !== "approved_operator") {
    return false;
  }
  if (call.name === "update_payout" && typeof call.input["amount"] === "number") {
    return Number(call.input["amount"]) <= 1000;
  }
  return true;
}

5. Automatisierte Prüfung vor der Bereitstellung

Wenn Agenten Code, SQL oder Ablaufdefinitionen erzeugen, sollten Sie diese vor der Bereitstellung prüfen. Das OWASP GenAI Security Project nennt wiederkehrende Risiken wie excessive agency und insecure output handling. Quelle: OWASP GenAI Security Project, 2025, https://genai.owasp.org/. Für Python- und Repository-Prüfung setze ich häufig semgrep, bandit und gitleaks in der Lieferkette ein.

semgrep --config=p/owasp-top-ten .
bandit -r app/ -f json -o bandit-report.json
gitleaks detect --source . --report-format json --report-path gitleaks.json

Wann n8n, Supabase und Postgres helfen und wann sie stören

n8n ist nützlich, wenn viele Fremdsysteme sichtbar miteinander verbunden werden müssen. Problematisch wird es, wenn die eigentliche Agentenlogik in schwer testbaren Knoten und stillen Verzweigungen verschwindet. Supabase eignet sich gut als verwaltete Schicht für Zustand, Authentisierung und interne Werkzeuge. Für sensiblere Fälle bevorzuge ich dennoch oft self-hosted Postgres als eindeutige Wahrheitsquelle.

Eine gesunde Architektur erkennen Sie daran, dass Sie das Modell wechseln oder einen weiteren Werkzeuganbieter ergänzen können, ohne Richtlinienebene, Zustandsmodell und Prüfspur vollständig umzubauen. Eine ungesunde Architektur koppelt alles so eng, dass schon ein Werkzeugwechsel einen Umbau des Gesamtsystems auslöst.

Ein praxistaugliches Muster für regulierte Märkte

Mein Standardmuster ist bewusst zurückhaltend. Das Modell entscheidet, führt Seiteneffekte aber nicht direkt aus. Jeder Werkzeugaufruf läuft durch eine Regelprüfung. Zustandswechsel und Ergebnisse werden in Postgres protokolliert. Geheimnisse werden zentral verwaltet. Geschäftsprozesse mit Bedarf an sichtbarer Orchestrierung liegen in n8n. Erzeugte Artefakte durchlaufen statische Analyse und bei Geldflüssen, Kundendaten oder externer Kommunikation zusätzlich eine menschliche Freigabe.

Das löst nicht jedes Problem. Es beseitigt aber die häufigste Ursache für spätere Instabilität: Teams glauben, sie bauen Agenten, bauen in Wahrheit jedoch ein Geflecht inkompatibler Zwischenstücke.

FAQ

Reicht MCP aus, um den gesamten Stack zu standardisieren?

Nein. MCP standardisiert die Beschreibung und den Aufruf von Werkzeugen, ersetzt aber weder Zustandsverwaltung noch Richtlinienprüfung, Prüfspur oder Wiederherstellungsstrategie.

Sollte die Orchestrierung in n8n bleiben?

Teilweise ja, wenn dadurch Transparenz und Geschwindigkeit entstehen. Wenn jedoch die zentrale Entscheidungslogik und Fehlerbehandlung nur in Ablaufknoten steckt, werden Wartung und Prüfung schnell teuer.

Funktioniert dieser Ansatz auch ohne self-hosted Postgres?

Ja, sofern Ihre verwaltete Umgebung Anforderungen an Protokollierung, Sicherung, Zugriff und Nachweis erfüllt. Entscheidend ist eine eindeutige Wahrheitsquelle statt mehrerer halber Zustände.

Was ist im Produktivbetrieb wichtiger: Modell oder Laufzeitumgebung?

In der Regel die Laufzeitumgebung. Ein Modellwechsel ist vergleichsweise schnell möglich; eine fehlerhafte Ausführungsschicht verursacht dagegen monatelange Nacharbeit.

Wie beginnen Sie eine Prüfung auf Werkzeugwildwuchs?

Mit einer Karte aller Werkzeugaufrufe, Geheimnisquellen, Zustandsspeicher und Seiteneffekte. Wenn Ihr Team in 30 Minuten nicht erklären kann, wo eine Entscheidung entsteht und wo sie ausgeführt wird, ist der Wildwuchs bereits da.

Welche Schicht verursacht in Ihrem Agentensystem derzeit die meisten Probleme im Produktivbetrieb: Werkzeugausführung, Richtlinienprüfung, Zustandswiederherstellung oder Nachvollziehbarkeit? Diese Antwort ist für mich meist aussagekräftiger als jeder Modellvergleich.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.