MCP-Server-Hosting: Wo Sie Ihre MCP-Server tatsächlich ausführen sollten

Was „Hosting eines MCP-Servers“ tatsächlich bedeutet

Ein MCP-Server ist ein Prozess. Das ist schon alles. Model Context Protocol definiert, wie ein Client Tools auf diesem Prozess entdeckt und aufruft, sagt aber nichts darüber aus, wo er lebt oder wer ihn am Laufen hält. Das hinterlässt eine einfache Infrastrukturfrage, die sich am Transportweg spaltet.

Stdio-Server sprechen MCP über Standard-Eingabe und Standard-Ausgabe. Es handelt sich um Programme im CLI-Stil, die normalerweise vom Client selbst mit npx oder uvx gestartet werden. Kein Port, keine URL, kein Netzwerk-Listener — der Client erzeugt einen Kindprozess auf derselben Maschine und kommuniziert mit ihm über Pipes.

HTTP/SSE-Server stellen HTTP-Endpunkte direkt bereit. Sie lauschen an einem Port und verhalten sich wie jeder andere Webdienst, den Sie bereits zu betreiben wissen.

Die TrueFoundry-Dokumentation zieht dieselbe Linie mit einer Konsequenz: HTTP-Server lassen sich ohne zusätzliche Wrapper bereitstellen, während stdio-Server mit mcp-proxy umschlossen werden müssen, um stdio in HTTP umzuwandeln. Die Dokumentation ist auch deutlich darüber, was Sie schreiben sollten, wenn Sie neu anfangen — HTTP-basierte Server werden als sicherer und einfacher bereitzustellen empfohlen.

Die drei Hosting-Optionen im Detail

Option 1 — Lokales stdio auf einem Laptop

Wo fast jeder anfängt und was für eine einzelne Person richtig ist. Sie fügen einen Block in Ihre Cursor- oder Claude-Konfiguration ein, der Client startet bei Bedarf npx -y @some/mcp-server, und der API-Schlüssel befindet sich in einer env-Map darunter.

Das funktioniert gut. Es übersteht jedoch nicht den Kontakt mit einem Team. Es gibt keine URL zum Teilen. Anmeldeinformationen werden per Copy-Paste verteilt. Jeder Entwickler führt seine eigene Kopie aus, sodass jede eine separate Installation ist, die auf eine andere Version abweichen kann. Und nichts zeichnet zentral auf, welches Tool von wem aufgerufen wurde, da der Aufruf nie eine von Ihnen kontrollierte Netzwerkgrenze überschritten hat. Lokales stdio ist ein Entwicklungsmodus, keine Hosting-Strategie.

Option 2 — Verwaltete Cloud eines Anbieters

Einige MCP-Server werden von ihren Betreibern als gehostete Endpunkte angeboten, und einige Gateway-Anbieter führen Server in Ihrem Namen in ihrer eigenen Cloud aus. Sie erhalten eine URL und sparen sich die Infrastruktur.

Dies ist der schnellste Weg und für öffentliche, schreibgeschützte Server mit geringer Sensibilität meist der richtige. Der Kompromiss liegt darin, wo der Prozess läuft. Ein gehosteter Server, der Ihre internen Systeme abfragt, bedeutet entweder, dass Sie diese Systeme für die Egress-Bereiche eines Anbieters öffnen oder Anmeldeinformationen auf eine Infrastruktur übertragen müssen, die Sie nicht kontrollieren. Für alles, was eine Produktionsdatenbank liest, ist das oft das Ende des Gesprächs.

Option 3 — Self-Hosting auf der eigenen Infrastruktur

Sie führen den Prozess auf Ihrem eigenen Kubernetes-Cluster, in Ihrer eigenen VPC und hinter Ihrer eigenen Netzwerk-Policy aus. Das ist es, worauf Teams zurückgreifen, sobald der Server etwas Internes berührt.

Self-Hosting ist nicht so schwer, wie die Leute erwarten. Ein MCP-Server ist ein kleiner zustandsloser HTTP-Dienst, und jedes Plattform-Team weiß bereits, wie man solche betreibt. Die Arbeit, die anfällt, betrifft die umgebende Schicht: eine stabile URL, die Entscheidung, wer ihn aufrufen darf, das Injizieren von Anmeldeinformationen, ohne sie in ein Image einzubrennen, und das Aufzeichnen von Vorgängen.

Was sich ändert, sobald es nicht mehr lokal ist

Das Verlagern eines Servers von einem Laptop ist kein einfaches Lift-and-Shift. Vier Dinge tauchen auf, die der Laptop nie brauchte – abgesehen von der offensichtlichen stabilen URL.

Bind-Adresse. Ein stdio-Server bindet niemals etwas. Ein HTTP-Server muss 0.0.0.0 binden, nicht localhost, da er sonst sauber in seinem Container startet, aber vom Rest des Clusters aus unerreichbar ist. Die Dokumentation enthält dazu eine Warnung, was zeigt, wie oft dieser Fehler passiert.

Auth in zwei Richtungen. Lokal gab es eine Anmeldeinformation — Ihren Schlüssel in Ihrer Konfiguration. Remote gilt: Wie weist sich ein Aufrufer gegenüber dem Server aus und wie weist sich der Server gegenüber dem aus, was er nachgelagert aufruft? Separate Probleme, separate Antworten.

Nebenläufigkeit und Ressourcen. Ein Prozess bediente einen Client. Jetzt bedient er ein Team, und Sie legen CPU- und Speicheranforderungen, Limits und Replica-Zahlen wie bei jedem anderen Dienst fest.

Egress. Der Server tätigt nun ausgehende Aufrufe aus Ihrem Netzwerk heraus und nicht mehr von einem Laptop im Büro-WLAN. Das ist normalerweise der Sinn der Sache, macht aber die Netzwerkposition des Servers zu einer Sicherheitsentscheidung statt zu einem Zufall.

Wo Teams beim MCP-Server-Hosting Fehler machen

Jeder Entwickler führt weiterhin seine eigene Kopie aus. Der häufigste Misserfolg ist kein technischer. Die lokale Konfiguration wird nie entfernt, sodass die Hälfte des Teams die Gateway-URL nutzt und die andere Hälfte weiterhin npx lokal mit einem persönlichen Token ausführt. Das ist keine Zentralisierung; es ist ein zweiter Pfad.

Tokens in args statt env. Wenn man einen stdio-Befehl in ein Manifest verschiebt, ist man versucht, das Token dort inline einzufügen, wo es im CLI-Aufruf stand. Die Dokumentation ist eindeutig: Fügen Sie Tokens niemals in args ein, da Argumente im Klartext im Manifest gespeichert werden und in Prozesslisten erscheinen können. Anmeldeinformationen gehören in Umgebungsvariablen, die durch einen Secret Store abgesichert sind.

Ungepinnte Pakete. npx -y some-package löst beim Container-Start auf die neueste Version auf, sodass zwei Replicas, die im Abstand von einer Woche gestartet wurden, unterschiedliche Toolsets ausführen können. Pinnen Sie explizite Versionen in args.

Die URL als Zielstrich betrachten. Ein bereitgestellter Server ohne Zugriffskontrolle ist ein Tool-Endpunkt, den jeder innerhalb des Netzwerks aufrufen kann. Hosting hat die Erreichbarkeit gelöst, nicht wer ihn erreichen darf — was die schwierigere Hälfte ist.

Sparen Sie sich den Aufwand.

Stellen Sie einen MCP-Server auf Ihrem eigenen Cluster bereit und schalten Sie in einer einzigen Sitzung eine verwaltete URL davor.

Kostenlos starten

Wie MCP-Server-Hosting auf TrueFoundry funktioniert

Die Position von TrueFoundry ist, dass Hosting und Governance ein einziges System sein sollten und nicht zwei. Der Server wird als gewöhnlicher Service auf Ihrem eigenen Kubernetes-Cluster bereitgestellt — dieselben Workspaces, Secrets, Autoscaling und Logs wie bei jeder anderen Workload — und registriert sich dann hinter dem MCP Gateway, das die URL, die Authentifizierung und das Zugriffsmodell besitzt. Drei Wege stehen zur Auswahl, je nachdem, wo Sie starten.

Weg 1 — Aus Quellcode

Verwenden Sie dies, wenn Sie den Server selbst geschrieben haben oder aus einem Repository bereitstellen, das Sie bauen können.

Es handelt sich um eine Standard-Service-Bereitstellung: Deployments → New Deployment → Service, wählen Sie Ihren Workspace und dann Git Repo oder Code From Laptop als Quelle. Für einen Python-HTTP-Server, der mit FastMCP und ohne Dockerfile gebaut wurde, besteht die Konfiguration aus einem Build-Kontextpfad, einem requirements.txt-Pfad, einer Python-Version, dem Befehl (python server.py) und Port 8000.

Wenn Ihre Quelle ein stdio-Server ist, umschließen Sie ihn. Der empfohlene Weg ist ein Dockerfile, das mcp-proxy installiert und ein CMD festlegt wie mcp-proxy --port 8000 --host 0.0.0.0 --server stream python server.py. Um das Dockerfile zu überspringen, verwenden Sie die Option Python Build, deklarieren mcp-proxy als Abhängigkeit und legen denselben Befehl direkt fest:

Die Port-Konfiguration ist in beiden Fällen gleich: Port 8000, Protokoll TCP, App-Protokoll http, expose auf false gesetzt, wenn der Dienst nur innerhalb des Clusters erreichbar sein soll. Sensible Werte gehören in TrueFoundry Secrets, referenziert als tfy-secret://your-workspace:your-secret-group:API_KEY.

Weg 2 — Aus einem npx- oder uvx-Paket

Verwenden Sie dies, wenn der Server als veröffentlichtes Paket existiert und Sie keinen Grund haben, ihn zu ändern — die direkte Übersetzung des Blocks, der heute in Ihrer Cursor-Konfiguration sitzt. Beide Varianten werden aus einem Docker-Image bereitgestellt, wobei der Befehl die Arbeit erledigt.

Für npm-Pakete ist das Basis-Image node:24 und der Befehl lautet:

npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y <package-name>

Das erste npx -y mcp-proxy installiert und führt den Proxy aus; das zweite führt Ihr Server-Paket aus. Ein Notion-Server wird so zu npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server.

Für Python-Pakete ist das Basis-Image public.ecr.aws/docker/library/python:3.11-slim und der Befehl installiert zuerst die Werkzeuge:

sh -c "pip install uv mcp-proxy && mcp-proxy --host=0.0.0.0 --port=8000 uvx <package-name>"

Deploy from Docker Image Formular mit python:3.11-slim Basis-Image und mcp-proxy, das ein uvx MCP-Paket umschließt

Umgebungsvariablen werden unverändert aus Ihrer lokalen Konfiguration übernommen — NOTION_API_KEY, GITHUB_TOKEN — wobei sensible Variablen in Secrets verschoben werden. Eine Erwartung sollte man berücksichtigen: Der erste Start ist langsam, während npx oder uvx das Paket herunterlädt. Wenn Kaltstarts eine Rolle spielen, installieren Sie es in einem benutzerdefinierten Image vor.

Weg 3 — Gehostetes stdio, ausgeführt durch das Gateway

Ein dritter Weg überspringt die Service-Bereitstellung vollständig: Anstatt dass Sie einen stdio-Server umschließen und bereitstellen, führt das Gateway den Prozess aus und stellt ihn unter derselben URL bereit, die es für Remote-Server verwendet. Wählen Sie unter MCP Servers → Add Server die Option Hosted Stdio-based MCP Server:

Sie geben einen command, arguments und environment variables an oder fügen JSON im Editor-Stil ein — dieselbe mcpServers-Struktur mit einem einzelnen Eintrag aus Cursor oder VS Code — und das Formular füllt sich von selbst aus. Der Filesystem-Referenzserver hat die Konfiguration command: npx mit args -y, @modelcontextprotocol/server-filesystem, /tmp.

Das Gateway führt ihn über die mcp-proxy-Bibliothek in einer Sandbox-Umgebung im zustandslosen Modus aus, und Clients verbinden sich über streamable HTTP POST. Umgebungsvariablen können global sein (alle teilen sich die nachgelagerte Anmeldeinformation) oder per-user, wobei ein Wert genau einen mit Platzhaltern versehenen Wert enthält, der aus den Auth Overrides dieses Aufrufers aufgelöst wird. Eine Einschränkung: Die Dokumentation empfiehlt diesen Weg für die lokale Entwicklung in IDEs — der schnellste Weg zu einer gemeinsam genutzten, verwalteten URL über einem Server im CLI-Stil, aber nicht das Muster für eine hochvolumige Produktions-Workload.

Anschließend hinter dem Gateway registrieren

Egal, wie der Server bereitgestellt wurde, der letzte Schritt ist derselbe. Nehmen Sie die Dienst-Endpunkt-URL, gehen Sie zu Add Server → Connect any Remote MCP Server und geben Sie Name, Beschreibung, URL, Collaborators und Auth-Daten an.

Die Inbound-Zugriffskontrolle wird hier angehängt. Collaborators sind Benutzer oder Teams, mit MCP Server Manager für vollständige Konfigurationsrechte und MCP Server User zum Aufrufen von Tools ohne Ändern von Einstellungen:

Outbound-Auth — wie sich das Gateway gegenüber dem von Ihnen bereitgestellten Server ausweist — ist eine der Optionen API Key, OAuth2, AWS SigV4 oder Token Passthrough. API Key unterteilt sich in Shared Credentials, wo ein Schlüssel für alle gilt, und Individual Credentials, wo der Header-Wert einen Platzhalter wie Bearer {{API_KEY}} enthält und jeder Benutzer seinen eigenen über Auth Overrides bereitstellt:

Für einen Server, den Sie selbst hosten, sind gemeinsam genutzte Anmeldeinformationen oft ausreichend — die Zugriffsentscheidung hat bereits am Gateway stattgefunden. Für alles, was benutzerspezifische Daten verarbeitet, ist OAuth2 die dokumentierte Empfehlung für die Produktion: Es unterstützt Scopes, Benutzer können ihre eigene Autorisierung widerrufen und der Zugriff ist auf das beschränkt, was jeder Benutzer sehen darf.

OAuth2-Konfiguration für einen MCP-Server mit den Grant-Typen Authorization Code und Client Credentials

Nach der Registrierung erscheinen die Tools und können aus dem Playground aufgerufen werden:

Ein praktisches Beispiel: Ablösung der Laptop-Kopien

Acht Entwickler haben jeweils den Notion-npx-Block in ihrer Cursor-Konfiguration, jeder mit einem persönlichen Notion-Schlüssel. Sie möchten eine gehostete Kopie.

Schritt 1 — Bereitstellen. New Deployment → Service → Deploy from Docker Image, Basis-Image node:24, Befehl npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server, Port 8000, Protokoll TCP, App-Protokoll http. Pinnen Sie die Paketversion. Lagen Sie NOTION_API_KEY in Secrets ab, nicht im env-Feld als Klartext.

Schritt 2 — Überprüfen. Warten Sie auf DEPLOY_SUCCESS, notieren Sie dann die Dienst-Endpunkt-URL und führen Sie einen curl-Befehl aus. Er sollte mit MCP-Protokollnachrichten über HTTP antworten. Dies zu tun, bevor Sie irgendetwas registrieren, trennt „der Container startet nicht“ von „das Gateway kann ihn nicht erreichen“, was sehr unterschiedliche Ursachen sind.

Schritt 3 — Registrieren. Add Server → Connect any Remote MCP Server, fügen Sie die Endpunkt-URL ein, benennen Sie ihn, fügen Sie das Engineering-Team als MCP Server User und sich selbst als MCP Server Manager hinzu und konfigurieren Sie dann die Auth-Daten.

Schritt 4 — Gateway-URL verteilen. Der Tab How To Use enthält mandantenspezifische Verbindungs-Snippets für Cursor, VS Code, Claude Code, Windsurf, Codex sowie die Python- und TypeScript-SDKs plus einen Button Add MCP to Cursor, der die Konfiguration für den Entwickler schreibt.

Schritt 5 — Lokale Blöcke löschen. Der Schritt, den Teams gerne überspringen, und derjenige, der die anderen vier erst wertvoll macht. Bis die npx-Einträge aus der Konfiguration aller Personen verschwunden sind, betreiben Sie neun Kopien, nicht eine.

Was Sie erhalten: eine Version des Servers, Anmeldeinformationen in einem Secret Store anstelle von acht Laptops, Transparenz pro Tool und die Möglichkeit, Tools zentral zu deaktivieren, anstatt die Leute höflich darum zu bitten.

Bereit, Ihren ersten Server zu hosten?

Stellen Sie aus einem Repo, einem npx-Paket oder einem stdio-Befehl bereit und schalten Sie eine verwaltete URL davor.

Kostenlos starten auf TrueFoundry

Fallstricke, die man kennen sollte

Eine hängende Installation sieht aus wie ein hängender Server. Bei gehosteten stdio-Servern wird eine fehlgeschlagene Paketinstallation nicht als Fehler dargestellt — der Server verbleibt auf unbestimmte Zeit in mcp_server_starting, weil der Paketmanager nie an den MCP-Prozess übergibt. Häufige Ursachen: eine Git-URL ohne gepinnte Ref, in eine npm-Paket-URL eingebettete Anmeldeinformationen (npm normalisiert diese weg) oder ein unvollständiger Download, der den npx-Cache nach einem abgebrochenen ersten Lauf verunreinigt. Das Ändern von etwas in args erstellt die Sandbox neu und startet sauber.

Benachrichtigungen außerhalb eines Antwort-Streams werden verworfen. Das Gateway führt stdio-Server im zustandslosen Modus aus, sodass eigenständige, vom Server initiierte Benachrichtigungen außerhalb des Antwort-Streams einer Anfrage nicht zugestellt werden. Überprüfen Sie die Protokoll-Supportmatrix, bevor Sie einen Server portieren, der unaufgeforderte Nachrichten sendet.

Die Bind-Adresse wird Sie einmal erwischen. Das Binden an localhost erzeugt einen Container, der startet, seinen eigenen Health-Check besteht und für den Cluster unsichtbar ist. Jeder stdio-Wrap-Befehl in der Dokumentation enthält genau aus diesem Grund --host 0.0.0.0.

Kaltstarts sind bei npx/uvx spürbar. Das Paket wird beim Container-Start heruntergeladen — fein für einen entwicklungsbezogenen Server, störend für alles, was latenzempfindlich ist.

Weiterführende Lektüre

• What Is an MCP Gateway — die Schicht vor allem, was Sie hosten
• Slack MCP Server — ein Drittanbieter-Server und wie er verwaltet wird
• Datadog MCP Server — das Muster angewendet auf Observability-Tools
• Snowflake MCP Server — wo private Daten Self-Hosting zum Standard machen
• Virtual MCP Server Explained — Bündelung von Tools mehrerer gehosteter Server in einem Endpunkt

Fazit

MCP-Server-Hosting ist kein exotisches Problem. Es ist die vertraute Aufgabe, einen Prozess, der auf einem Laptop funktioniert, in einen Dienst zu verwandeln, auf den sich ein Team verlassen kann — eine URL, eine Identität, Ressourcenlimits, Secrets und eine Aufzeichnung der Vorgänge.

Was es wertvoll macht, es sorgfältig anzugehen, ist, dass ein MCP-Server ein Tool-Endpunkt ist. Erreichbarkeit ohne Zugriffskontrolle ist kein Meilenstein; es ist ein Sicherheitsrisiko. Die Bereitstellung auf Ihrem eigenen Kubernetes und die Registrierung hinter einem Gateway auf derselben Plattform fasst die zwei Hälften in eine Aufgabe zusammen: Der Prozess läuft dort, wo Ihre Netzwerk-Policy bereits gilt, und die vorgeschaltete URL weiß bereits, wer anruft.

Stellen Sie Ihren ersten MCP-Server auf TrueFoundry bereit und verwalten Sie ihn

Kostenlos starten