Ein Remote-MCP-Server stellt KI-Clients Tools über HTTP statt über einen lokalen Prozess bereit. Dafür verpackst du den Server in einen Container, betreibst ihn auf einem VPS hinter HTTPS und verlangst eine Authentifizierung, bevor ein Client ein Tool aufrufen kann. Der aktuelle Transport heißt Streamable HTTP, und ein kleiner Server läuft problemlos auf einem einfachen VPS.
Was ist ein Remote-MCP-Server und wie unterscheidet er sich von einem lokalen Server?
Das Model Context Protocol (MCP) ist ein offenes, auf JSON-RPC basierendes Protokoll. Damit kann eine KI-Anwendung Tools erkennen und aufrufen, die ein separater Server bereitstellt. Der Ausführungsort unterscheidet die beiden Varianten. Ein lokaler MCP-Server verwendet den stdio-Transport: Der Client startet ihn als Unterprozess und kommuniziert über Standardeingabe und Standardausgabe mit ihm. Daher kann ihn nur dieser Client auf diesem Rechner verwenden. Ein Remote-MCP-Server läuft als unabhängiger Prozess hinter einem einzelnen HTTP-Endpunkt wie https://mcp.example.com/mcp. Jeder Client, der die URL erreichen und gültige Zugangsdaten vorlegen kann, darf ihn aufrufen.
Der Remote-Transport heißt Streamable HTTP. Er ersetzt den älteren HTTP+SSE-Transport, der laut Spezifikation seit Protokollversion 2025-03-26 veraltet ist und bei neuen Implementierungen nicht mehr verwendet werden soll. Die aktuelle Version 2026-07-28 vereinfacht den Transport weiter: Jede JSON-RPC-Nachricht wird separat per POST gesendet; der eigenständige GET-Stream und Sitzungen auf Protokollebene entfallen. Clients übernehmen neue Versionen unterschiedlich schnell. Verwende deshalb ein SDK, das beide Generationen unterstützt, wie das unten eingesetzte Python-SDK.
Teams betreiben eigene Server aus drei Gründen: Sie erhalten einen gemeinsamen Tool-Satz, einen dauerhaft verfügbaren Endpunkt unabhängig von einzelnen Laptops und behalten private Daten auf selbst kontrollierter Infrastruktur.
| Aspekt | Lokal (stdio) | Remote (Streamable HTTP) |
| Ausführungsort | Unterprozess, den der Client auf demselben Rechner startet | Unabhängiger Prozess auf einem Server hinter einem HTTP-Endpunkt |
| Zugriff | Nur der Client, der den Prozess gestartet hat | Jeder Client, der die URL erreichen und sich authentifizieren kann |
| Authentifizierung | Keine Authentifizierung auf Protokollebene; Zugangsdaten kommen aus der Umgebung | Authorization-Header bei jeder Anfrage; OAuth-basierter Ablauf in der Spezifikation |
| Typischer Einsatz | Persönliche Tools, die lokale Dateien oder Prozesse benötigen | Gemeinsame Team-Tools, dauerhaft aktive Integrationen und private Datendienste |
| Wichtigster Nachteil | Einfach, aber an einen Rechner und einen Benutzer gebunden | Für alle erreichbar, daher bist du für HTTPS, Authentifizierung, Protokollierung und Updates verantwortlich |
Hosting-Anforderungen für MCP-Server: Welche VPS-Größe brauchst du?
Die meisten MCP-Server sind schlanke Wrapper für eine API, daher benötigt die MCP-Schicht selbst kaum Ressourcen. Die erforderliche Größe hängt von deinen Tools ab. Richte den VPS nach dem ressourcenintensivsten Tool aus, beginne klein und prüfe die tatsächliche Auslastung mit docker stats, bevor du aufrüstest.
| Servertyp | Ursache der Ressourcennutzung | Ausgangspunkt |
| API-Wrapper | Ein Python- oder Node-Prozess, der Aufrufe an andere APIs weiterleitet | 1 vCPU, 1–2 GB RAM |
| Mit Datenbank | Abfragen und die Datenbank selbst, falls sie auf demselben VPS läuft | 2 vCPU, mindestens 4 GB RAM |
| Browser oder Code-Runner | Headless-Browser-Instanzen oder isolierter Code mit jeweils eigenem Speicherbedarf | 4 vCPU, mindestens 8 GB RAM |
Mehrere kleine Server können sich einen VPS hinter einem gemeinsamen Reverse Proxy teilen. Hier zahlt sich ein Plan mit viel RAM aus.
Einen minimalen MCP-Server für das Deployment erstellen
Dieses Beispiel verwendet das offizielle Python-SDK, das Paket mcp, zum Zeitpunkt der Veröffentlichung in Version 2.3.0. Falls du älteren Tutorials folgst, beachte die Umbenennung von FastMCP in MCPServer mit Version 2.x. Der alte Importpfad funktioniert nicht mehr. Der folgende Server besitzt ein Tool, einen Health-Endpunkt und den Streamable-HTTP-Transport. Er liest seinen öffentlichen Hostnamen aus einer Umgebungsvariable, weil das SDK nur Anfragen an ausdrücklich erlaubte Hosts beantwortet. Andere Anfragen erhalten den Fehler 421 Misdirected Request. Das schützt vor DNS-Rebinding.
# server.py
import os
from mcp.server import MCPServer
from mcp.server.transport_security import TransportSecuritySettings
from starlette.requests import Request
from starlette.responses import JSONResponse
mcp = MCPServer("word-tools")
@mcp.tool()
def word_count(text: str) -> int:
"""Count the words in a piece of text."""
return len(text.split())
@mcp.custom_route("/health", methods=["GET"])
async def health(request: Request) -> JSONResponse:
return JSONResponse({"status": "ok"})
if __name__ == "__main__":
host = os.environ["MCP_PUBLIC_HOST"]
mcp.run(
transport="streamable-http",
host="0.0.0.0",
port=8000,
stateless_http=True,
transport_security=TransportSecuritySettings(
allowed_hosts=[host, f"{host}:*"]
),
)
Drei Details sind relevant. Der MCP-Endpunkt lautet standardmäßig /mcp. Die Option stateless_http deaktiviert die Sitzungsverfolgung, sodass du bei mehreren Instanzen keine Sticky Sessions brauchst. Benutzerdefinierte Routen wie /health werden vom SDK nie authentifiziert. Gib darüber daher keine vertraulichen Informationen zurück.
MCP-Server mit Docker auf einem VPS bereitstellen
Installiere zuerst Docker; unsere Anleitung zur Installation von Docker unter Ubuntu führt dich durch alle Schritte. Lege anschließend eine Dockerfile- und eine Compose-Datei neben server.py ab. Der Container läuft unter einem Benutzer ohne Root-Rechte, startet automatisch neu und veröffentlicht seinen Port ausschließlich auf 127.0.0.1. Dadurch kann ihn nur ein Proxy auf demselben Host erreichen.
# Dockerfile
FROM python:3.13-slim
RUN pip install --no-cache-dir "mcp==2.3.0"
RUN useradd --create-home --uid 10001 mcp
USER mcp
WORKDIR /app
COPY --chown=mcp:mcp server.py .
EXPOSE 8000
CMD ["python", "server.py"]
# docker-compose.yml
services:
mcp:
build: .
restart: unless-stopped
environment:
MCP_PUBLIC_HOST: mcp.example.com
ports:
- "127.0.0.1:8000:8000"
healthcheck:
test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/health')"]
interval: 30s
timeout: 5s
retries: 3
docker compose up -d --build
docker compose ps
curl -i http://127.0.0.1:8000/health
Der letzte Befehl sollte den Status 200 mit {„status“:“ok“} zurückgeben. Ersetze mcp.example.com durch einen Hostnamen, dessen DNS-Eintrag auf deinen VPS verweist.
Remote-MCP-Server absichern: HTTPS, Authentifizierung und Limits
Über einen offenen MCP-Endpunkt kann jeder, der die URL findet, deine Tools ausführen. Lass ihn deshalb nie ungeschützt. Die folgenden Schritte ergänzen HTTPS, eine Bearer-Token-Prüfung und grundlegende Limits.
- Öffne nur die Ports 80, 443 und SSH. Unsere Anleitung zur UFW-Firewall zeigt dir die Befehle. Caddy benötigt die Ports 80 und 443 für automatische Zertifikate; außerdem muss dein DNS-A- oder AAAA-Eintrag bereits auf den Server verweisen.
- Erstelle mit openssl rand -hex 32 ein Token und speichere es in einer .env-Datei neben docker-compose.yml als MCP_TOKEN=<value>. Nimm diese Datei nicht in die Versionsverwaltung auf.
- Füge Caddy mit dem folgenden Caddyfile und Service-Block als zweiten Dienst hinzu. Caddy terminiert HTTPS, ruft selbstständig Zertifikate von Let’s Encrypt oder ZeroSSL ab und lehnt Anfragen ohne den richtigen Authorization-Header ab.
- Teste den Server von außen: Eine Anfrage ohne Token oder mit einem falschen Token muss den Status 401 zurückgeben. Füge den Server danach mit gesetztem Token zu einem Client hinzu.
- Beschränke die Tools. Stelle nur benötigte Funktionen bereit, trenne Nur-Lese- und Schreib-Tools auf Server mit eigenen Tokens und begrenze teure oder destruktive Tools pro Token.
# Caddyfile (in ./caddy/)
mcp.example.com {
@no_token not header Authorization "Bearer {$MCP_TOKEN}"
respond @no_token "Unauthorized" 401
reverse_proxy 127.0.0.1:8000
}
# add under services: in docker-compose.yml
caddy:
image: caddy:2.11
restart: unless-stopped
network_mode: host
env_file: .env
volumes:
- ./caddy:/etc/caddy
- caddy_data:/data
# add at the top level of docker-compose.yml
volumes:
caddy_data:
Falls du bereits Nginx Proxy Manager betreibst, funktioniert dort dasselbe Prinzip mit einem Proxy Host und einer Header-Prüfung. Binde die Caddy-Konfiguration als Verzeichnis ein und speichere /data dauerhaft, damit die Zertifikate Neustarts überstehen.
Dieses gemeinsame Bearer-Token dient nur als Zugangssperre und entspricht nicht dem Autorisierungsmodell der MCP-Spezifikation. Die Spezifikation stellt die Autorisierung frei, erwartet bei HTTP-Transporten jedoch einen auf OAuth 2.1 basierenden Ablauf: Dein Server arbeitet ausschließlich als Ressourcenserver, veröffentlicht OAuth Protected Resource Metadata nach RFC 9728 und liest das Zugriffstoken bei jeder Anfrage aus dem Authorization-Header, niemals aus dem Query-String. Tokens, die nicht für ihn ausgestellt wurden, muss er ablehnen. Das Python-SDK unterstützt diesen Aufbau mit einem Token-Verifizierer und einem Autorisierungsserver, der die Tokens ausstellt. Ein statisches Token enthält keine benutzerspezifische Identität und läuft nicht ab. Rotiere es daher manuell und vertraue jedem Inhaber vollständig. Wechsle zu OAuth, sobald Benutzer unterschiedliche Berechtigungen benötigen oder ein Client ausschließlich OAuth unterstützt.
Authentifizierung verhindert keine Prompt Injection. Sie bestimmt, wer deine Tools aufrufen darf, aber nicht, wie ein Modell mit den zurückgegebenen Texten umgeht. Ruft ein Tool eine Webseite, eine E-Mail oder ein Ticket ab, können darin versteckte Anweisungen einen Agenten beeinflussen, der zugleich Schreib-Tools verwenden darf. Die Spezifikation setzt auf mehrere Schutzschichten: Server müssen Eingaben prüfen, Zugriffskontrollen durchsetzen, Aufrufe begrenzen und Ausgaben bereinigen. Clients sollten Menschen die Möglichkeit geben, Tool-Aufrufe abzulehnen. Vergib für Tools nur minimale Rechte, kombiniere private Datentools nicht mit Tools, die nicht vertrauenswürdige Inhalte lesen oder Daten versenden, und protokolliere Aufrufe. So begrenzt du mögliche Schäden, machst den Server aber nicht automatisch sicher. Unsere VPS-Sicherheitscheckliste behandelt den Host.
Claude, Cursor und andere Clients mit deinem MCP-Server verbinden
Jeder der folgenden Clients kann einen Remote-Server per URL hinzufügen. Verwende den vollständigen Endpunkt und sende das Token als Header.
- Claude Code: Führe claude mcp add –transport http mit einem Namen, der URL und einer –header-Option aus. Laut Dokumentation ist der SSE-Transport veraltet.
- Cursor: Füge einen url- und einen headers-Eintrag zu .cursor/mcp.json für das Projekt oder zu ~/.cursor/mcp.json für alle Projekte hinzu. Cursor unterstützt Streamable HTTP und kann das Token aus einer Umgebungsvariable lesen.
- VS Code: Füge einen Server vom Typ http zu .vscode/mcp.json hinzu. VS Code versucht zuerst Streamable HTTP und wechselt bei Bedarf zu SSE; eine inputs-Abfrage hält das Token aus der Datei heraus.
- Claude (claude.ai, Desktop und Mobilgeräte): Füge unter Customize > Connectors einen benutzerdefinierten Connector mit der HTTPS-URL hinzu. Die Verbindung wird aus der Anthropic-Cloud aufgebaut, daher muss der Server öffentlich erreichbar sein. Als Anmeldeoptionen stehen OAuth oder keine Anmeldung zur Verfügung; feste Request-Header befinden sich für eine begrenzte Zahl von Organisationen in der Betaphase.
claude mcp add –transport http word-tools https://mcp.example.com/mcp \
–header „Authorization: Bearer $MCP_TOKEN“
// .cursor/mcp.json
{
"mcpServers": {
"word-tools": {
"url": "https://mcp.example.com/mcp",
"headers": { "Authorization": "Bearer ${env:MCP_TOKEN}" }
}
}
}
// .vscode/mcp.json
{
"inputs": [
{ "type": "promptString", "id": "mcp-token", "description": "MCP token", "password": true }
],
"servers": {
"word-tools": {
"type": "http",
"url": "https://mcp.example.com/mcp",
"headers": { "Authorization": "Bearer ${input:mcp-token}" }
}
}
}
Falls die Verbindung fehlschlägt, prüfe zuerst diese Punkte:
- 401 bei jeder Anfrage: Der Header fehlt, enthält kein Bearer-Präfix oder stimmt nicht mit MCP_TOKEN in .env überein.
- 421 Invalid Host header: Der Hostname des Clients ist nicht in allowed_hosts enthalten. Korrigiere MCP_PUBLIC_HOST und erstelle den Container neu.
- Zertifikatsfehler: DNS muss auf den VPS verweisen, und die Ports 80 und 443 müssen erreichbar sein, damit Caddy das Zertifikat ausstellen kann.
- Verbindung hängt oder bricht ab: Verwende die URL /mcp statt /sse. Claude behandelt eine auf /sse endende URL als älteren Transport. Stelle außerdem sicher, dass kein Proxy gestreamte Antworten puffert.
Einen selbst gehosteten MCP-Server überwachen, protokollieren und aktualisieren
Ein selbst gehosteter MCP-Server kann unbemerkt ausfallen: Der Agent verwendet das Tool dann einfach nicht mehr.
- Protokollierung: Erfasse Tool-Namen, Zeitstempel, Dauer, das verwendete Token und jeden 401-Fehler des Proxys. Protokolliere nie vollständige Argumente oder Tokens; laut Spezifikation können auf einem Server protokollierte Tokens gestohlen werden. Lies die Container-Ausgabe mit docker compose logs -f mcp.
- Benachrichtigungen: Der Healthcheck des Containers überwacht die Anwendung; ein externer Monitor am HTTPS-Endpunkt prüft zusätzlich DNS, Zertifikate und Proxy. Unsere Anleitung zu Uptime Kuma erklärt Uptime-Benachrichtigungen, während die Anleitung zu Prometheus und Grafana Metriken ergänzt.
- Updates: Fixiere Versionen, erstelle das Image mit docker compose build –pull neu und führe anschließend docker compose up -d aus. Behalte das vorherige Image für ein Rollback und lies vor jedem größeren Versionssprung das SDK-Changelog, da FastMCP mit Version 2.x umbenannt wurde.
Warum MCP-Server auf einem Contabo VPS hosten?
Ein Remote-MCP-Server benötigt eine dauerhaft verfügbare Maschine und kalkulierbare Kosten. Bei der Core-Reihe von Contabo liegt der Schwerpunkt auf viel RAM pro Euro. Ein Cloud VPS mit mindestens 8 GB RAM kann daher mehrere kleine MCP-Server hinter einer Caddy-Instanz betreiben und bietet noch Platz für eine Datenbank. Der monatliche Preis ist fest und passt damit zu einem Dienst, der rund um die Uhr läuft. Falls der Datenstandort für deine privaten Tools relevant ist, prüfe beim Bestellvorgang die verfügbaren Rechenzentrumsstandorte.
Laut dem Beitrag zur Einführung der Contabo Firewall ist bei jedem VPS und VDS eine Firewall enthalten. Sie ergänzt vor der Host-Firewall eine zweite Filterschicht. Weitere Hinweise zur Dimensionierung außerhalb von MCP findest du in unserer Anleitung zu VPS-Spezifikationen für KI-Agenten. Falls deine Tools ein lokales Modell aufrufen, beschreibt der Beitrag zur Einführung des GPU VPS die passende Hardware. Plannamen und Preise können sich ändern. Prüfe sie daher vor der Bestellung auf den aktuellen Contabo Seiten.
FAQ: Remote-MCP-Server
Was ist ein Remote-MCP-Server?
Ein Remote-MCP-Server ist ein Model-Context-Protocol-Server, der auf einem Netzwerkhost läuft und KI-Clients über HTTP mit dem Streamable-HTTP-Transport bedient. Anders als einen lokalen stdio-Server können viele Clients über eine URL erreichen. Deshalb benötigt er HTTPS und eine Authentifizierung.
Brauche ich einen VPS, um einen MCP-Server zu hosten?
Nein, du kannst ihn auch auf einem Laptop oder einer Serverless-Plattform betreiben. Ein VPS eignet sich, wenn du einen dauerhaft verfügbaren Endpunkt, feste monatliche Kosten und Kontrolle über deine Daten möchtest. Ein kleiner API-Wrapper-Server benötigt sehr wenig RAM, daher kann bereits ein VPS der Einstiegsklasse genügen.
Wie sichere ich einen Remote-MCP-Server ab?
Stelle ihn über HTTPS bereit, verlange bei jeder Anfrage einen Authorization-Header, binde den Container hinter einem Reverse Proxy an localhost und veröffentliche nur benötigte Tools. Verwende bei Mehrbenutzerumgebungen den OAuth-basierten Ablauf aus der Spezifikation. Das beseitigt keine Prompt-Injection-Risiken, daher sollten Tools nur minimale Rechte erhalten.
Kann ich einen MCP-Server in Docker ausführen?
Ja. Ein MCP-Server ist ein normaler Prozess und läuft daher gut in einem Container. Verwende ein schlankes Basis-Image, einen Benutzer ohne Root-Rechte, eine Neustartrichtlinie und einen Healthcheck. Veröffentliche den Port auf 127.0.0.1, damit ihn nur dein Reverse Proxy erreichen kann.
Was unterscheidet lokale und Remote-MCP-Server?
Ein lokaler MCP-Server läuft als Unterprozess eines Clients und kommuniziert über stdio. Deshalb kann ihn nur dieser Client verwenden. Ein Remote-MCP-Server läuft unabhängig hinter einem HTTP-Endpunkt und nutzt Streamable HTTP. So können ihn mehrere Clients gemeinsam verwenden, was zusätzlich HTTPS, Authentifizierung und Monitoring erfordert.
Hinweis: Die in diesem Artikel genannten Produktspezifikationen, Funktionen und Preise können sich ändern und je nach Region, Abrechnungszeitraum und laufender Aktion abweichen. Aktuelle Angaben, Preise und lokale Wechselkurse findest du auf der offiziellen Website des jeweiligen Anbieters oder der jeweiligen Marke.