Brauche ich eine dedizierte IP, um einen MCP-Server zu hosten?

Für einen öffentlichen HTTPS-Endpunkt ja. NAT-Pläne leiten einen einzelnen SSH-Port weiter und legen Port 443 nicht ins Internet offen. Ein Plan mit dedizierter IP gibt dir jeden Port und eine Domain, die du direkt auf die Maschine verweisen kannst.

stdio oder HTTP — welchen Transport hoste ich?

HTTP (SSE oder das neuere streamable-HTTP). Ein stdio-Server spricht nur mit einem Client auf derselben Maschine; alles, was über das Netzwerk erreichbar sein soll, muss HTTP hinter einer URL sprechen.

Kann ein VPS mehrere MCP-Server betreiben?

Ja. Binde jeden Server an einen anderen lokalen Port und gib jedem seine eigene Subdomain im Reverse-Proxy. RAM ist die praktische Grenze, und Tool-Server nutzen sehr wenig davon.

Wie viel RAM braucht ein MCP-Server?

Meist wenig. Ein Tool-Server ist I/O-gebunden — er wartet auf APIs und Datenbanken, statt Zahlen zu mahlen, also bewältigen 1–2 GB die meisten. Ein Modell zu betreiben, um die Antworten zu generieren, ist ein separater, viel schwererer Job.

Hoste deinen eigenen MCP-Server auf einem VPS

Du hast einen MCP-Server geschrieben. Lokal funktioniert er gut — dein Agent ruft ihn auf, die Tools feuern, alles ist verkabelt. Dann schließt du deinen Laptop und er ist weg. Wenn du diesen Server erreichbar haben willst, wann immer dein Agent ihn braucht — von einer anderen Maschine, vom Setup eines Teamkollegen, von einem geplanten Job um 3 Uhr — muss er irgendwo leben, das immer an ist, mit einer stabilen Adresse und HTTPS. Dafür ist ein VPS da.

So verschiebst du deinen MCP-Server von deinem Laptop auf eine Maschine, die du tatsächlich kontrollierst, mit ehrlichen Hinweisen, wohin der Aufwand geht.

Lokal vs remote: was „hosten“ wirklich bedeutet

MCP-Server gibt es in zwei Formen.

Ein stdio-Server läuft als lokaler Prozess und spricht mit einem Client auf derselben Maschine über Standard-Eingabe/-Ausgabe. Er ist perfekt, während du baust — aber er kann von nichts über das Netzwerk erreicht werden.

Ein Remote-Server spricht HTTP (Server-Sent Events oder den neueren streamable-HTTP-Transport) über eine URL. Jeder Client, der die URL kennt und die richtigen Zugangsdaten hält, kann ihn aufrufen. Deinen eigenen MCP-Server zu hosten bedeutet, die Remote-Art irgendwo Öffentlichem und Stabilem zu betreiben.

Warum nicht einfach deinen Laptop tunneln

Du kannst eine Heim-Maschine technisch mit einem Tunnel offenlegen, und für eine schnelle Demo ist das okay. Für alles, worauf du dich verlässt, erbst du die Probleme der Maschine: sie geht in den Ruhezustand, dein ISP rotiert deine IP, dein Upload ist langsam, und jetzt sitzt ein Dienst voller echter Tools in deinem Heimnetzwerk neben allem anderen. Ein VPS gibt dir eine feste öffentliche IP, eine echte Domain, ordentliche Verfügbarkeit und Isolation. Für ein paar Dollar im Monat löscht er eine ganze Kategorie von „warum hat mein Agent die Verbindung verloren“-Fragen.

Die Stack, konkret

Wähle eine kleine Maschine. Ein MCP-Tool-Server ist meist I/O — er wartet auf APIs, Dateien und Datenbanken; er macht keine schwere Mathematik. 1–2 GB RAM sind für die meisten reichlich. (Ein Modell inline zu betreiben, um zu antworten, ist eine andere Geschichte — siehe einen LLM mit Ollama selbst hosten.)

Betreibe deinen Server an localhost gebunden, sagen wir Node oder Python, das auf 127.0.0.1:3100 lauscht. Halte ihn direkt von der öffentlichen Schnittstelle fern — der Proxy erledigt das.

Setze einen Reverse-Proxy davor, um TLS auf deiner Domain zu terminieren. Caddy macht es in etwa vier Zeilen und holt automatisch ein kostenloses Zertifikat:

mcp.yourdomain.com {
    reverse_proxy 127.0.0.1:3100
}

Verweise mcp.yourdomain.com auf deine VPS-IP, lade Caddy neu, und dein Server ist live unter https://mcp.yourdomain.com über streamable-HTTP.

Halte ihn immer an

Ein Server, der beim ersten Absturz oder Neustart stirbt, ist nicht „gehostet“ — er „läuft vorerst“. Verpack ihn in eine systemd-Unit, damit er bei einem Absturz neu startet und nach einem Neustart zurückkommt:

[Unit]
Description=My MCP server
After=network.target

[Service]
ExecStart=/usr/bin/node /opt/mcp/server.js
Restart=always
RestartSec=2

[Install]
WantedBy=multi-user.target

systemctl enable --now my-mcp und er ist wirklich immer an. (Dasselbe Muster hält jeden Agenten oder Bot 24/7 am Leben.)

Der Teil, den Leute übersehen: du brauchst einen erreichbaren Port

Ein öffentlicher MCP-Endpunkt braucht einen eingehenden Port — 443 — vom Internet erreichbar. Bei einem NAT-Plan bekommst du genau einen weitergeleiteten Port für SSH und sonst nichts; du kannst 443 nicht zur Welt öffnen. Um einen öffentlichen HTTPS-MCP-Server zu hosten, willst du einen Plan mit dedizierter IP, bei dem jeder Port dir gehört und du eine Domain direkt auf die Maschine verweisen kannst. Das ist der Unterschied zwischen „mein Agent auf demselben Laptop kann ihn erreichen“ und „jeder Client überall kann es“.

Riegle ihn ab — es ist eine API mit Privilegien

Ein MCP-Server stellt meist Tools bereit, die Dinge tun: Dateien lesen, bezahlte APIs ansprechen, Geld bewegen. Stell das nicht nackt ins offene Internet.

Verlange bei jedem Aufruf ein Token. Weise anonyme Anfragen ab; prüfe ein Bearer-Token oder einen API-Schlüssel, bevor ein Tool läuft.
Firewall auf alles außer 443 und deinem SSH-Port.
Nur-Schlüssel-SSH, kein Passwort-Login. (Hier ist die Zehn-Minuten-Checkliste.)

Behandle den Endpunkt als das, was er ist — eine API mit echter Autorität — und das meiste Risiko verschwindet.

Die ehrlichen Grenzen

Die Ops gehört jetzt dir. OS-Updates, den Prozess gesund halten, Logs beobachten. Caddy erneuert das Zertifikat für dich, aber der Rest gehört dir. Eine verwaltete Cloud-Funktion versteckt das; ein VPS gibt es dir im Tausch gegen Kontrolle und eine viel niedrigere Rechnung.
Die MCP-Spezifikation bewegt sich noch. Transporte und Auth-Muster ändern sich von Release zu Release. Pinne deine SDK-Version und rechne damit, sie hin und wieder zu aktualisieren.
Eine CPU-Maschine ist richtig für Tool-Server, nicht dafür, Antworten mit einem lokalen Modell zu generieren. Wenn dein Server ein LLM betreibt, um zu antworten, ist das eine separate, schwerere Maschine — siehe den Ollama-Leitfaden.
Lege destruktive Tools nie ohne Auth und einen Bestätigungsschritt offen. Ein offenes Tool, das Dinge löscht, wird irgendwann auf einen Bot treffen, der alles scannt.

Das Bezahlen

Registriere dich mit einer E-Mail und zahle in USDC oder USDT — keine Karte, kein Ausweis. Und wenn du das für einen Agenten verkabelst, kann dieselbe Art Maschine programmatisch über unseren eigenen MCP-Server bestellt und bezahlt werden — der Agent registriert sich, lädt ein Guthaben auf und bestellt selbst.

Hoste den Server einmal, und deine Tools sind da, wann immer der Agent nach ihnen greift.

Fertiges Setup: siehe VPS für MCP-Server — der empfohlene Plan und ein Krypto-Deploy in einer Minute.