Wenn Ihr Agent Websuche braucht, werden 5 MCP-Server zum Betriebsrisiko: wie Sie einen Stack ohne Integrationswildwuchs wählen

Ich bin Denis Shokhirev, Agentic AI Systems Architect aus Freiburg im Breisgau, Germany, und bei DennisCraft AI Studio betreibe ich KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. Der operative Schmerz beginnt oft an einem unscheinbaren Punkt: Ein Team ergänzt „nur noch Websuche“, und zwei Sprints später gibt es fünf MCP-Server, verschiedene Verfahren zur Anmeldung, verteilte Protokolle und keine klare Antwort darauf, warum die Laufzeiten nachts aus dem Rahmen fallen.

Im Demo-Betrieb wirkt das zunächst vernünftig. Im Produktivbetrieb, gerade in Logistik, Fintech und industrieller Automatisierung, entsteht daraus jedoch ein Betriebsproblem: mehr Netzwerkpfade, mehr Geheimnisse, schwächere Nachvollziehbarkeit und höhere Anforderungen an Prüfung, Dokumentation und Wiederholbarkeit.

Das Problem ist nicht MCP, sondern unkontrollierte Vermehrung von MCP-Endpunkten

Model Context Protocol ist als Standard sinnvoll. Das Risiko entsteht, wenn jede neue Fähigkeit als eigener Betriebsblock eingeführt wird: ein Server für Suche, einer für Crawling, einer für Browserzugriff, einer für interne Dokumente, einer für strukturierte Daten. Dann verwalten Sie nicht mehr nur Werkzeuge für einen Agenten, sondern ein verteiltes System mit uneinheitlichen Regeln.

Wo die Probleme zuerst sichtbar werden

Wenn ein Agent eine fachliche Antwort erzeugt, stellt sich im Störfall nicht die Frage, ob genug Werkzeuge vorhanden waren. Entscheidend ist: Welche Anfrage ging nach außen, welche Inhalte kamen zurück, welcher Kontext wurde zusammengesetzt, welche Regel hat den Zugriff erlaubt und was wurde für die spätere Prüfung in Postgres gespeichert?

Wie ich den Stack auswähle: möglichst geringe betriebliche Angriffsfläche

Ich bewerte Websuche für Agenten nicht nach der Breite einer Demo, sondern nach fünf betriebsrelevanten Kriterien.

1. Einheitliches Verfahren für Geheimnisse und Anmeldung

Wenn Websuche, interne Datenabfrage und Orchestrierung unterschiedliche Muster für Geheimnisse verwenden, zahlen Sie bereits einen Preis im Betrieb. Ich bevorzuge eine zentrale Verwaltung über Doppler und eine klare Begrenzung pro Dienst.

2. Durchgehende Nachvollziehbarkeit eines einzelnen Laufs

Ein Agentenlauf sollte eine gemeinsame Kennung durch n8n, Anwendungslogik, Postgres und den externen Suchpfad tragen. Ohne diese Klammer wird die Ursachenanalyse unnötig langsam.

3. Gesteuerter Ausgang ins externe Netz

In regulierten Umgebungen ist „das ganze Internet“ keine akzeptable Vertrauensgrenze. Ich möchte freigegebene Domänen, Zeitgrenzen, Mengenbegrenzungen und lesbare Zugriffsprotokolle. Das passt auch zu DSGVO, ISO 27001, BSI Grundschutz und den Anforderungen, die viele Unternehmen im Rahmen von NIS2 oder EU AI Act bereits vorbereiten.

4. Vorhersehbare Degradation

Wenn Websuche ausfällt, sollte der Agent in einen Modus mit internen Quellen wechseln, statt mit Wiederholungen die Warteschlange zu blockieren.

5. Ein gemeinsamer Prüfpfad

Ausführungsdaten, Werkzeugaufrufe und Regelentscheidungen speichere ich bevorzugt in Postgres oder Supabase. Für Prüfungen und Freigaben ist ein gemeinsamer Datenpfad deutlich einfacher als fünf verstreute Oberflächen.

Das Muster, das sich im Betrieb bewährt: ein Gateway statt vieler direkter MCP-Verbindungen

Wenn ein Agent Websuche, Browserzugriff und Retrieval braucht, gebe ich dem Modell nach Möglichkeit eine kontrollierte Werkzeugschnittstelle. Dahinter entscheidet ein Backend-Dienst, ob Suche, Postgres oder interne Regeln verwendet werden, normalisiert die Ergebnisse und schreibt einen Ablaufnachweis. Für das Modell ist das ein Werkzeug. Für den Betrieb ist das ein Vertrag.

import os
import requests
from urllib.parse import urlparse

ALLOWED_HOSTS = {"bsi.bund.de", "owasp.org"}

def fetch_url(url: str, timeout: int = 8) -> str:
    host = urlparse(url).netloc
    if host not in ALLOWED_HOSTS:
        raise ValueError(f"host not allowed: {host}")

    response = requests.get(
        url,
        timeout=timeout,
        headers={"User-Agent": "agent-gateway/1.0"}
    )
    response.raise_for_status()
    return response.text[:20000]

Der entscheidende Punkt liegt nicht im Python-Code selbst, sondern in der Reihenfolge: Die Regelprüfung erfolgt vor dem externen Aufruf. Das reduziert Risiko und erleichtert die fachliche wie regulatorische Begründung.

Warum Standardisierung allein nicht ausreicht

Anthropic beschreibt in der Dokumentation zu Tool Use und Model Context Protocol, wie Werkzeuge standardisiert angebunden werden können. Das ersetzt jedoch keine Zugriffspolitik, keine Ausleitungsregeln und keine Prüfspur. Quelle: Anthropic Documentation, 2025, https://docs.anthropic.com/.

Ein schlanker Produktiv-Stack für Websuche im Agentenbetrieb

export DATABASE_URL="postgresql://app:pass@db/app"
export ANTHROPIC_API_KEY="***"
export SEARCH_TIMEOUT_SECONDS="8"

semgrep --config auto .
bandit -r app/
gitleaks detect --source . --no-banner

python -m app.worker

Gerade bei wachsender Integrationszahl verstärken sich bekannte Fehlerbilder. Geheimnisse landen weiterhin im Repository. Unsichere Aufrufe bleiben unsicher. Unter Zeitdruck entstehen weiterhin schlecht parametrisierte Datenbankabfragen. Als Orientierung für häufige Schwachstellen ist OWASP Top 10 weiterhin sinnvoll. Quelle: OWASP Top 10, 2021, https://owasp.org/www-project-top-ten/.

Woran Sie Integrationswildwuchs erkennen

Ich nutze dafür eine einfache Liste. Wenn Sie drei oder mehr Punkte mit „ja“ beantworten, ist Vereinfachung überfällig:

• Jedes Werkzeug des Agenten hat eigene Zugangsdaten und einen anderen Verantwortlichen
• Sie können den vollständigen Ablauf einer Antwort nicht in unter 10 Minuten rekonstruieren
• Protokolle für Internetsuche und interne Datenabfrage liegen in verschiedenen Systemen
• Bei Ausfall der Suche scheitert der Agent, statt geordnet zu degradieren
• Niemand kann kurzfristig benennen, welche externen Domänen erlaubt sind

Wenn das auf Ihren Stack zutrifft, ergänzen Sie nicht den sechsten MCP-Server. Verkleinern Sie zuerst die betriebliche Fläche: ein Gateway, ein Ablaufmodell, ein Prüfpfad.

FAQ

Ist MCP grundsätzlich problematisch?

Nein. Problematisch ist unkontrolliertes Wachstum ohne gemeinsame Regeln, Verantwortlichkeiten und Nachvollziehbarkeit. Als Standard ist MCP nützlich, wenn es in eine beherrschte Architektur eingebettet ist.

Wann sind mehrere MCP-Server dennoch sinnvoll?

Wenn unterschiedliche Vertrauensgrenzen, Isolationsanforderungen oder organisatorische Zuständigkeiten bestehen. Selbst dann brauchen Sie eine einheitliche Prüfspur und gemeinsame Beobachtbarkeit.

Kann man auf Websuche verzichten?

In vielen B2B-Fällen ja, wenn internes Retrieval ausreicht. Websuche wird dort relevant, wo externe Informationen schnell altern oder Entscheidungen vom aktuellen Umfeld abhängen.

Warum nicht alles in eine Plattform auslagern?

Für einen frühen Start kann das sinnvoll sein. In regulierten Märkten stoßen Sie jedoch rasch auf Fragen zu Datenresidenz, Prüfbarkeit und Zugriffskontrolle.

Was ist zuerst wichtiger: Laufzeit oder Prüfbarkeit?

Beides zählt. In regulierten Produktivsystemen sichere ich jedoch zuerst Nachvollziehbarkeit und Kontrolle und optimiere danach die Laufzeiten.

Wo entsteht in Ihrem Agentenbetrieb derzeit die größte Reibung: bei der Nachvollziehbarkeit von Werkzeugaufrufen, bei der Kontrolle externer Zugriffe oder bei der geordneten Degradation, wenn Websuche ausfällt? Diese Antwort interessiert mich aus echtem Produktivbetrieb.

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.