MCP Server selbst hosten: DSGVO-konformes Setup

Letzte Woche hat The New Stack die MCP-Dynamik sinngemäß so zugespitzt: Plattformen ohne MCP-Support drohen aus der nächsten Generation von AI-Apps herauszufallen. Das ist als These hart formuliert, aber der Trend ist in Kunden-Workshops deutlich spürbar. Wer im DACH-Raum ernsthaft Agents in Produktionsabläufen will, kommt am Model Context Protocol (MCP) kaum vorbei.

Die nächste Frage kommt dann sofort: "Müssen wir das bei Anthropic oder OpenAI hosten?" Kurze Antwort: Nein. MCP ist ein offenes Protokoll, du kannst es komplett in eigener Infrastruktur oder in einem regionalen Rechenzentrum betreiben — und wenn du auf DSGVO-, Schrems-II- und CLOUD-Act-Argumente Rücksicht nehmen musst, solltest du diese Option ernsthaft prüfen. In diesem Artikel zeige ich dir, wie ein produktionstaugliches Setup aussieht: Architektur, Docker-Compose-Beispiel, Anbindung an dein Frontend und eine Compliance-Checkliste am Ende.

Wenn du den technischen Teil überspringen willst und einfach eine fertige Plattform suchst, die das alles schon mitbringt: Wir bauen genau diese Setups als unsere AI-OpenStack-Lösung — Architektur-Workshop, Setup und Betrieb als Service inklusive.

Was MCP überhaupt ist (und was nicht)

Das Model Context Protocol ist ein von Anthropic im November 2024 veröffentlichter offener Standard, der eine einheitliche Schnittstelle zwischen LLMs und externen Tools, Datenquellen und Aktionen definiert. Du kannst dir MCP als "USB-C für AI Agents" vorstellen: Statt für jedes Modell eine eigene Tool-Calling-Schnittstelle zu bauen, sprichst du MCP — und jeder MCP-kompatible Client (Claude Desktop, Cline, OpenWebUI, eigene UIs) kann deine Tools nutzen, ohne dass du den Code zwei Mal schreibst.

Konkret besteht MCP aus zwei Rollen: dem MCP Server (der Tools, Resources und Prompts bereitstellt) und dem MCP Client (der LLM-Anwendung, die die Tools nutzt). Die Kommunikation läuft über JSON-RPC 2.0, entweder via stdio (lokal) oder via HTTP/Server-Sent-Events (remote). Anthropic positioniert MCP ausdrücklich als offene Verbindungsschicht für Agenten, Daten und Tools. Auch GitHub Copilot Custom Agents und Atlassian Rovo Studio zeigen, dass Agent-Plattformen ohne saubere Tool- und Kontextschnittstellen schnell an Grenzen stoßen.

Was MCP nicht ist: keine Datenbank, keine Vektorsuche, kein Agent-Framework. Es ist eine reine Protokoll-Schicht. Du brauchst trotzdem ein LLM, eine Inferenz-Engine, optional eine Vektordatenbank für RAG und ein Frontend. MCP regelt nur die Tool-Calling-Schnittstelle dazwischen — aber das tut es sauber genug, dass du damit ein modulares System bauen kannst.

Warum überhaupt selbst hosten?

Drei Argumente, die in DACH-Beratungen immer wieder dieselben sind:

1. DSGVO und Schrems II. Sobald personenbezogene Daten in Prompts oder Tool-Calls fließen, fällt die Verarbeitung unter die DSGVO. Bei Cloud-LLMs in den USA musst du nach dem Schrems-II-Urteil des EuGH von 2020 Standardvertragsklauseln, Transfer-Impact-Assessments und ergänzende Maßnahmen prüfen. Das ist nicht unmöglich — aber aufwändig und mit Restrisiko verbunden.

2. CLOUD Act. Selbst Daten in EU-Rechenzentren US-amerikanischer Cloud-Provider können unter den US CLOUD Act fallen, wenn der Provider in den USA inkorporiert ist. Für regulierte Branchen — Gesundheit, Finanzen, kritische Infrastruktur, öffentliche Verwaltung — ist das oft ein Ausschlusskriterium.

3. EU AI Act. Die Digital-AI-Omnibus-Debatte könnte die High-Risk-Pflichten verschieben — aber Kennzeichnung, Transparenzpflichten und Verbote für bestimmte Anwendungsfälle bleiben auf der Roadmap. Wer einen eigenen MCP-Server betreibt, hat deutlich mehr Kontrolle über Logging, Audit-Trails und Compliance-Reporting. Bei einem fremd-gehosteten Service bist du stärker auf die Nachweise und Konfiguration des Anbieters angewiesen.

Dazu kommt das wirtschaftliche Argument: Bei moderaten Token-Volumina (etwa ab 5–10 Millionen Tokens pro Tag) wird Self-Hosting selbst inklusive Hardware-Abschreibung günstiger als Cloud-API-Pricing. Bei richtig großen Volumen ist die Lücke dramatisch — auch deshalb, weil sich der westlich-chinesische Preisabstand bei vergleichbarer Benchmark-Performance auf Faktor 5 bis 25 ausgeweitet hat.

Wenn dir Hardware-Beschaffung und 24/7-Betrieb zu aufwändig sind, bieten wir das Setup auch als Managed Service an: Der Modell-Stack läuft in einem regionalen Rechenzentrum, ohne dass du selbst Hardware beschaffen musst, und Datenflüsse werden projektspezifisch dokumentiert und begrenzt.

Architektur: Die vier Bausteine eines MCP-Setups

Bevor wir in die Konfig springen, eine kurze Skizze. Ein produktionstaugliches MCP-Setup besteht aus vier Schichten:

┌──────────────────────────────────────────────────┐
│  Frontend (OpenWebUI, eigene UI, Cline, etc.)   │
└──────────────────────────────────────────────────┘
                       │ HTTP / SSE
┌──────────────────────────────────────────────────┐
│  LLM Gateway (LiteLLM Proxy)                     │
│  - Auth, Rate Limiting, Routing, Logging         │
└──────────────────────────────────────────────────┘
                       │
        ┌──────────────┴──────────────┐
        │                             │
┌───────▼────────┐         ┌──────────▼─────────┐
│  Inferenz      │         │  MCP Server(s)     │
│  (vLLM)        │         │  - Filesystem      │
│  - Llama 4     │         │  - DB Connector    │
│  - Mistral 3   │         │  - Custom Tools    │
│  - Qwen 3.5    │         └────────────────────┘
└────────────────┘                   │
                                     │
                          ┌──────────▼─────────┐
                          │  Datenquellen      │
                          │  Qdrant, Postgres, │
                          │  Nextcloud, NAS    │
                          └────────────────────┘

1. Inferenz-Engine (vLLM) — die GPU-Schicht, die deine Open-Weight-Modelle ausführt. Aktuelle vLLM-Releases sind für viele produktive Serving-Setups geeignet; welche Modellfamilien wirklich stabil laufen, sollte aber pro Modell, Quantisierung und Hardware getestet werden.

2. LLM Gateway (LiteLLM Proxy) — die Routing-Schicht. Sie nimmt OpenAI-kompatible API-Calls entgegen, prüft Auth, leitet weiter und loggt. MCP-Integration und Gateway-Verhalten hängen vom konkreten LiteLLM-Release ab; im produktiven Setup solltest du die Version pinnen und gegen deine Clients testen.

3. MCP Server — der Tool-Layer. Hier liegen alle Funktionen, die das LLM aufrufen können soll: Datenbank-Queries, Filesystem-Zugriffe, eigene Business-Logik, externe APIs. Ein MCP-Server pro Tool-Domäne ist eine saubere Trennung.

4. Datenquellen — alles, was du anbinden willst: Qdrant als Vektordatenbank für RAG, PostgreSQL für strukturierte Daten, Nextcloud für Dokumente, eine lokale NAS für File-Storage. Keine Big-Player-Abhängigkeiten — alles, was du brauchst, läuft Open Source auf eigener Hardware.

Hands-On: Docker-Compose-Setup

Hier ist ein minimales, aber produktionsnahes Compose-Setup. Es ist nicht copy-paste-bereit für deinen Cluster — das wäre auch unverantwortlich, weil jedes Setup eigene Netzwerk-, Storage- und Security-Constraints hat. Aber es zeigt dir die Struktur.

# docker-compose.yml
version: "3.9"

services:
  vllm:
    image: vllm/vllm-openai:v0.20.2
    runtime: nvidia
    environment:
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
    volumes:
      - ./models:/root/.cache/huggingface
    command: >
      --model mistralai/Mistral-Medium-3.5
      --tensor-parallel-size 4
      --max-model-len 131072
      --gpu-memory-utilization 0.92
    ports:
      - "127.0.0.1:8000:8000"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 4
              capabilities: [gpu]

  litellm:
    image: ghcr.io/berriai/litellm:v1.84.0
    environment:
      - LITELLM_MASTER_KEY=${LITELLM_KEY}
      - DATABASE_URL=postgresql://litellm:${PG_PASS}@postgres:5432/litellm
    volumes:
      - ./litellm-config.yaml:/app/config.yaml:ro
    command: --config /app/config.yaml --port 4000
    ports:
      - "127.0.0.1:4000:4000"
    depends_on:
      - vllm
      - postgres

  mcp-filesystem:
    image: ghcr.io/modelcontextprotocol/server-filesystem:latest
    environment:
      - MCP_ALLOWED_PATHS=/data/shared
    volumes:
      - /mnt/nas/shared:/data/shared:ro
    ports:
      - "127.0.0.1:5001:5001"

  mcp-qdrant:
    build: ./mcp-servers/qdrant
    environment:
      - QDRANT_URL=http://qdrant:6333
      - QDRANT_API_KEY=${QDRANT_KEY}
    depends_on:
      - qdrant
    ports:
      - "127.0.0.1:5002:5002"

  qdrant:
    image: qdrant/qdrant:v1.15.0
    volumes:
      - ./qdrant-storage:/qdrant/storage
    ports:
      - "127.0.0.1:6333:6333"

  postgres:
    image: postgres:17-alpine
    environment:
      - POSTGRES_USER=litellm
      - POSTGRES_PASSWORD=${PG_PASS}
      - POSTGRES_DB=litellm
    volumes:
      - ./pgdata:/var/lib/postgresql/data

  openwebui:
    image: ghcr.io/open-webui/open-webui:v0.9.5
    environment:
      - OPENAI_API_BASE_URL=http://litellm:4000/v1
      - OPENAI_API_KEY=${LITELLM_KEY}
      - WEBUI_AUTH=true
    volumes:
      - ./openwebui-data:/app/backend/data
    ports:
      - "8080:8080"
    depends_on:
      - litellm

Die LiteLLM-Konfig dazu, in der wir die MCP-Server beispielhaft registrieren. Je nach LiteLLM-Version kann die exakte MCP-Konfiguration abweichen — für ein echtes Setup also immer gegen die aktuelle Doku prüfen:

# litellm-config.yaml
model_list:
  - model_name: mistral-medium
    litellm_params:
      model: openai/mistralai/Mistral-Medium-3.5
      api_base: http://vllm:8000/v1
      api_key: dummy

mcp_servers:
  filesystem:
    transport: http
    url: http://mcp-filesystem:5001
  qdrant:
    transport: http
    url: http://mcp-qdrant:5002

general_settings:
  master_key: ${LITELLM_MASTER_KEY}
  database_url: ${DATABASE_URL}
  enforce_user_id: true
  store_audit_logs: true

Mit docker compose up -d startet das gesamte Setup. Die wichtigsten Endpoints:

• http://localhost:4000/v1/chat/completions — OpenAI-kompatible Inferenz, mit Auth über LiteLLM
• http://localhost:4000/mcp/tools — Liste der verfügbaren MCP-Tools (über alle registrierten Server hinweg)
• http://localhost:8080 — OpenWebUI als optionales Frontend für direkte Interaktion

Frontend-Anbindung

OpenWebUI ist eine der Optionen — und für viele Teams ein guter Einstiegspunkt, weil es sich schnell an einen OpenAI-kompatiblen LiteLLM-Endpoint anbinden lässt. MCP-Tools laufen dann über die Gateway- und Server-Schicht, nicht über lose Einzelintegrationen im Frontend. Für strukturierte Geschäftsprozesse wie Rechnungsfreigabe, Reklamationsbearbeitung oder Vertragsanalyse stößt eine generische Chat-UI aber irgendwann an Grenzen.

Genau deshalb bauen wir in unserer AI-OpenStack-Lösung neben OpenWebUI eigene, optimierte UIs für strukturierte Prozesse. Die Idee: OpenWebUI bleibt für freie Recherche und Experimente, und für die produktiven Workflows gibt es spezialisierte Oberflächen, die nur das anzeigen, was im Prozess relevant ist. Beides spricht denselben LiteLLM-Endpoint, beides nutzt dieselben MCP-Server — der Unterschied liegt im Frontend.

Wer eine ganz schlanke Variante will: Cline als VS-Code-Extension funktioniert direkt mit deinem LiteLLM-Endpoint und kann MCP-Server als Tools nutzen. Für Developer-Workflows ist das oft die schnellere Lösung als ein Web-UI aufzusetzen.

DSGVO-Compliance-Checkliste

Hier eine pragmatische Checkliste, die wir in DACH-Setups standardmäßig durchgehen:

• Hosting-Standort dokumentieren: Rechenzentrum in EU/EWR, idealerweise mit ISO 27001 oder C5-Testat. Bei eigenem Rechenzentrum: Zutritts-, Brand- und Stromversorgungs-Konzept.
• Auftragsverarbeitungsverträge: Mit jedem externen Beteiligten (Rechenzentrum, Hardware-Wartung, externe Admins) ein AVV nach Art. 28 DSGVO.
• Datenfluss-Diagramm: Visualisierung, wer welche Daten wo verarbeitet. Pflichtteil des Verarbeitungsverzeichnisses (Art. 30).
• Audit-Logs: LiteLLM bietet store_audit_logs: true — aktivieren, Aufbewahrungsfrist definieren (üblich: 90 Tage, plus Backup-Lifecycle).
• Rollen-/Berechtigungs-Modell: Wer darf welche MCP-Tools nutzen? Welche Datenquellen werden mit welcher Identität angefragt? LDAP/AD-Integration über LiteLLM ist möglich, und in unserer AI-OpenStack-Lösung ist die LDAP/AD-Anbindung Standard.
• Pseudonymisierung in Prompts: Wenn personenbezogene Daten in Prompts landen, klären, ob Pseudonymisierung machbar ist. Bei RAG mit Patientendaten oder Personalakten Pflicht.
• Datenschutz-Folgenabschätzung (DSFA): Bei systematischer Verarbeitung personenbezogener Daten Art. 35 DSGVO prüfen. Faustregel: Wenn es im Verarbeitungsverzeichnis steht und sensible Daten umfasst, ist eine DSFA fällig.
• EU-AI-Act-Klassifizierung: Ist deine Anwendung High-Risk nach Annex III? Auch wenn die Pflichten erst Dezember 2027 greifen — die Klassifizierung jetzt machen, weil sie das Design beeinflusst.
• Kennzeichnungsstrategie: Wenn dein MCP-Server Bilder, Texte oder andere generative Inhalte ausgibt, plane Kennzeichnung und Watermarking in den Output-Pfad ein, bevor die Pflicht konkret greift.

Das ist keine vollständige Liste — bei regulierten Branchen oder grenzüberschreitenden Setups kommen weitere Punkte dazu. Aber das deckt die Basis ab, die wir bei jedem Projekt durchgehen.

Was du im ersten Sprint nicht unterschätzen solltest

Drei Punkte, die in den ersten Setups oft schiefgehen:

1. GPU-Speicher-Planung. Große Open-Weight-Modelle können je nach Quantisierung auf einem H200-Knoten realistisch werden — aber sobald du mehr Concurrency willst oder größere Context-Windows nutzt, brauchst du Headroom. Plane mindestens 20 % VRAM-Reserve ein, und teste mit realen Workloads, bevor du in Produktion gehst.

2. MCP-Tool-Berechtigungen. Ein MCP-Filesystem-Server mit Zugriff auf / ist eine offene Tür. Lege die MCP_ALLOWED_PATHS so eng wie möglich, prüfe Read- vs Write-Berechtigungen separat und logge jede Tool-Invocation.

3. Modell-Lifecycle. Open-Weight-Modelle entwickeln sich schnell — Llama, Mistral, Qwen, Gemma und DeepSeek sind die Modellfamilien, die du Stand Mai 2026 regelmäßig evaluieren solltest. Plane einen Quartals-Review für deinen Modell-Stack ein, in dem du gegen neue Benchmark-Ergebnisse, Lizenzänderungen und vLLM-Support testest.

Fazit

Einen MCP-Server selbst zu hosten ist kein Forschungsvorhaben mehr — die Werkzeuge sind reif genug, die Standards stabil genug, und die wirtschaftlichen wie regulatorischen Argumente sprechen für DACH-Unternehmen zunehmend dagegen, kritische AI-Workloads ungeprüft in US-Clouds zu legen. Was du brauchst: eine GPU-Hardware-Basis (eigene oder als Service), ein sauberes Architektur-Bild (Inferenz, Gateway, MCP-Server, Datenquellen), Disziplin bei Berechtigungen und Audit-Logging, und ein Frontend, das zu deinen Workflows passt — OpenWebUI als guter Einstiegspunkt, eigene UIs für strukturierte Prozesse.

Wenn du das Setup nicht selbst aufbauen willst oder einfach jemanden brauchst, der die Architektur vor der ersten Investition gegenliest: Melde dich direkt bei uns — wir machen Architektur-Workshops, Migrationspläne und betreiben die AI-OpenStack-Lösung auf Wunsch als Managed Service in einem regionalen Rechenzentrum, ohne dass du selbst Hardware beschaffen musst.

Tieferer Kontext zur DSGVO-Lage findest du in unseren Pillars zu Sovereign AI, DeepSeek V4 On-Premise und Agentic Engineering 2026.