2026 MCP-Server selbst hosten: Wie bereitstellen? Neue Zustandslosigkeit

Wenn Ihr MCP-Werkzeug nur auf Ihrem Rechner gebraucht wird, müssen Sie es nicht allein wegen der neuen Protokollfassung auf einen Server verschieben; für gemeinsam genutzte Werkzeuge ist Streamable HTTP meist die passendere Bereitstellungsform.

Diese Woche: Erfassen Sie zuerst, welche Clients den Dienst tatsächlich nutzen, prüfen Sie danach deren Protokoll- und SDK-Unterstützung und testen Sie eine neue Verbindung zunächst getrennt von der produktiven Konfiguration. Die Änderungen vom 28.07.2026 betreffen die Protokollebene, nicht automatisch Ihre fachlichen Daten oder Berechtigungen (MCP-Veröffentlichung zur Fassung vom 28.07.2026).

Für wen dieser Leitfaden gedacht ist:
Einzelentwickler erfahren, wann eine lokale MCP-Integration mit stdio sinnvoll bleibt.
Kleine Teams erhalten einen Ablauf für gemeinsam genutzte Werkzeuge über Streamable HTTP.
Technische Verantwortliche können Protokollwechsel, Client-Kompatibilität und Anwendungsstatus voneinander abgrenzen.

MCP-Server selbst hosten: Wählen Sie nach dem Zugriffsszenario

Die erste Entscheidung lautet nicht „lokaler Rechner oder Server?“, sondern: Wo läuft der Client, und welche Ressourcen muss das Werkzeug erreichen? Ein MCP-Server über stdio wird typischerweise vom Client als lokaler Unterprozess gestartet. Das passt, wenn ein einzelner Nutzer mit lokalen Dateien, Entwicklungswerkzeugen oder einer persönlichen Umgebung arbeitet. Der Prozess muss dann nicht als gemeinsam erreichbarer Dienst betrieben werden.

Streamable HTTP ist dagegen die passende Richtung, wenn verschiedene Clients denselben Werkzeugdienst erreichen sollen oder wenn Betrieb, Aktualisierung und Protokollierung zentral organisiert werden müssen. Die offizielle TypeScript-SDK-Dokumentation trennt den lokalen stdio-Betrieb vom entfernten HTTP-Betrieb; behandeln Sie diese Formen daher als unterschiedliche Bereitstellungsszenarien und nicht als austauschbare Schreibweisen derselben Verbindung (Dokumentation zur Bereitstellung über HTTP).

Ein entfernter Dienst muss dabei nicht zwangsläufig öffentlich aus dem Internet erreichbar sein. Entscheidend ist, dass vorgesehene Clients den Endpunkt über die gewählte Netzwerk- und Zugriffskonfiguration erreichen können. Für vertrauliche Werkzeuge sollten Sie vor dem Freischalten klären, wie Authentifizierung, Autorisierung, Transportverschlüsselung, Protokollierung und Netzwerkgrenzen umgesetzt werden. Ein MCP-Transport ersetzt keine Zugriffskontrolle.

Behalten Sie stdio bei, wenn das Werkzeug ausschließlich lokal benötigt wird, lokale Pfade zugreifen muss oder die Serverinstallation nur für einen Entwickler gedacht ist. Planen Sie Streamable HTTP, wenn mehrere Nutzer denselben Dienst aufrufen, wenn Sie Werkzeuge unabhängig von einzelnen Arbeitsplatzrechnern betreiben oder wenn eine zentrale Verwaltung Teil Ihrer Betriebsanforderungen ist. Ein Wechsel ist kein Selbstzweck: Er lohnt sich erst, wenn der gemeinsame Zugriff den zusätzlichen Aufwand für Netzwerkbetrieb und Absicherung rechtfertigt.

Erster Schritt: Klären Sie, was „zustandslos“ in der neuen Fassung bedeutet

Die Spezifikation vom 28.07.2026 beschreibt eine Änderung an der Protokollebene: Das bisherige initialize/initialized-Handshake entfällt, ebenso die Protokollverwaltung über Mcp-Session-Id. Maßgeblich sind die offizielle Veröffentlichungsnotiz und der Abschnitt zu den Transporten in der Spezifikation (Änderungsnotiz, Transportdefinition der Fassung vom 28.07.2026).

Daraus folgt nicht, dass jede Anwendung keine Zustände mehr speichern muss. Die Änderung betrifft die Frage, wie das MCP-Protokoll eine Verbindung beziehungsweise Sitzung behandelt. Sie entscheidet nicht, ob Ihr Werkzeug einen Datenbankeintrag, eine Anmeldung, einen Bearbeitungsfortschritt oder den Status eines externen Vorgangs dauerhaft speichern muss. Diese Aufgaben gehören weiterhin in die Anwendung und ihre angebundenen Dienste.

Das ist besonders wichtig, wenn Sie eine einfache API-artige Funktion bereitstellen. Ein Werkzeug, das Eingaben entgegennimmt und eine unabhängige Antwort zurückgibt, kann von einem zustandsärmeren Anfragefluss profitieren. Benötigt die Funktion dagegen einen mehrstufigen Ablauf, muss sie weiterhin nachvollziehbar festhalten, welcher Auftrag begonnen hat, welche Schritte bereits abgeschlossen sind und wie Fehler behandelt werden. „Kein Protokoll-Sitzungsbezeichner“ ist keine Zusage, dass Anfragen automatisch schneller werden oder dass ein Dienst beliebig horizontal skaliert.

Für mehrere Instanzen gilt deshalb: Prüfen Sie, ob jede Anfrage unabhängig verarbeitet werden kann, ob alle Instanzen benötigte fachliche Daten konsistent erreichen und wie Schreibvorgänge bei Wiederholung behandelt werden. Ein zustandsloser Protokollablauf kann die Bindung an eine vom Protokoll verwaltete Sitzung reduzieren; er beseitigt aber keine Datenbankabhängigkeiten, Sperren, Autorisierungsregeln oder Anforderungen an eine geordnete Verarbeitung.

Zweiter Schritt: Nutzen Sie stdio weiter, wenn der Arbeitsplatz der richtige Betriebsort ist

Für eine lokale Integration startet der Client den MCP-Prozess auf demselben Rechner und kommuniziert über Standardeingabe und Standardausgabe. Das ist praktisch, wenn der Server Zugriff auf lokale Projektdateien, Werkzeuge oder Konfigurationen benötigt, die nicht auf einen Teamserver übertragen werden sollen. Es vermeidet außerdem, für einen einzelnen Nutzer einen Netzwerkdienst und dessen Zugriffsschutz einzurichten.

Prüfen Sie vor dem Beibehalten dieser Architektur dennoch, ob die lokale Installation wartbar ist. Dokumentieren Sie, wie der Prozess gestartet wird, welche Umgebungsvariablen benötigt werden und wo Zugangsdaten abgelegt sind. Ein lokal gestarteter Prozess ist nicht automatisch sicher: Ein zu weit gefasster Dateizugriff oder ungeschützt gespeicherte Zugangsdaten können ebenso problematisch sein wie ein falsch abgesicherter entfernter Dienst.

Wenn mehrere Teammitglieder jeweils eigene lokale Instanzen einrichten, entstehen zusätzliche Betriebsaufgaben: Versionen können auseinanderlaufen, Konfigurationen können abweichen und Änderungen müssen an mehreren Arbeitsplätzen geprüft werden. Das ist kein Grund, lokale Prozesse grundsätzlich abzuschaffen. Es ist ein Signal, dass Sie den Nutzen gemeinsamer Wartung gegen den Aufwand zentraler Bereitstellung abwägen sollten.

Vermeiden Sie insbesondere eine Migration, die lediglich durch eine Versionsnummer ausgelöst wird. Wenn Ihr Client weiterhin lokal arbeitet und keine gemeinsam erreichbare Funktion benötigt, ändern sich durch die Protokollaktualisierung nicht automatisch die Anforderungen an Ihren Betriebsort. Übernehmen Sie Änderungen erst, wenn Sie den konkreten Nutzen, die SDK-Unterstützung und die Auswirkungen auf Ihre Nutzer geprüft haben.

Dritter Schritt: Stellen Sie gemeinsame Werkzeuge kontrolliert über HTTP bereit

Beginnen Sie mit einem klar abgegrenzten Werkzeugdienst. Legen Sie fest, welche Clients zugreifen dürfen, welche Werkzeuge verfügbar sind und welche Daten der Dienst lesen oder verändern kann. Trennen Sie die Berechtigung für den Aufruf eines Werkzeugs von der Berechtigung für die dahinterliegende Ressource. Ein gemeinsamer MCP-Endpunkt sollte nicht mehr Zugriff erhalten, als seine Aufgaben benötigen.

Prüfen Sie anschließend die vom eingesetzten SDK dokumentierte HTTP-Bereitstellung. Die offizielle TypeScript-SDK-Dokumentation beschreibt den entfernten Betrieb und die dafür relevanten Serverkonzepte; übernehmen Sie Konfigurationen nicht aus einem Beispiel, bevor Sie kontrolliert haben, ob es zur verwendeten SDK-Fassung passt (HTTP-Bereitstellung im SDK). Da sich Implementierungen weiterentwickeln können, sollten Sie die dort beschriebene stabile Dokumentation und die tatsächlich installierte Version gemeinsam betrachten.

Planen Sie den Dienst außerdem als reguläre Anwendung: Legen Sie fest, wie er gestartet und aktualisiert wird, wie Fehler sichtbar werden und wie Zugangsdaten verwaltet werden. Entscheiden Sie vor dem produktiven Einsatz, ob der Endpunkt nur innerhalb eines privaten Netzes, über eine kontrollierte Vermittlung oder auf einem anderen von Ihnen abgesicherten Weg erreichbar sein soll. Die öffentliche Erreichbarkeit ist keine Voraussetzung für „Remote“; nötig ist nur ein passender Netzwerkpfad zwischen zugelassenem Client und Dienst.

Bei personenbezogenen oder vertraulichen Unternehmensdaten müssen Sie zusätzlich bewerten, welche Daten der MCP-Dienst verarbeitet, welche Protokolleinträge entstehen und wie lange diese aufbewahrt werden. Für eine DSGVO-konforme Umsetzung gibt es keine pauschale MCP-Einstellung: Sie müssen Datenflüsse, Zuständigkeiten, Zugriff und Aufbewahrung für Ihren konkreten Dienst prüfen. Die Hinweise von OVN Cloud zur Datenverarbeitung können Sie als ergänzenden Ausgangspunkt für die eigene Prüfung heranziehen; sie ersetzen keine rechtliche Bewertung Ihres konkreten Einsatzes.

Vierter Schritt: Migrieren Sie alte Clients mit einem überprüfbaren Rückweg

Die Frage, ob ein älterer Client mit einem neuen Server funktioniert, lässt sich ohne Versionsprüfung nicht verlässlich mit Ja oder Nein beantworten. Berücksichtigen Sie mindestens den Client, die verwendete SDK-Fassung, den Transport und den Server. Die offizielle TypeScript-SDK-Migrationsdokumentation beschreibt die Unterstützung der Fassung vom 28.07.2026; prüfen Sie sie zusammen mit den Hinweisen der jeweiligen Client-Implementierung (SDK-Kompatibilitäts- und Migrationshinweise).

Arbeiten Sie in einer kontrollierten Reihenfolge:

1. Bestandsaufnahme erstellen. Notieren Sie, welche Clients den Dienst nutzen, welchen Transport sie verwenden und welche SDK- oder Protokollfassungen in Ihren Umgebungen tatsächlich installiert sind. Unterscheiden Sie zwischen lokalem stdio-Betrieb und entfernten HTTP-Verbindungen.
2. Offizielle Unterstützung nachsehen. Vergleichen Sie die Client- und SDK-Angaben mit der aktuellen Spezifikation und der Migrationsdokumentation. Wenn eine Angabe fehlt, behandeln Sie sie als ungeklärt und nicht als stillschweigende Unterstützung.
3. Testverbindung isolieren. Richten Sie eine Testumgebung oder einen getrennten Endpunkt ein. Verwenden Sie dabei dieselben wesentlichen Berechtigungen und Anwendungsschritte wie im späteren Einsatz, aber vermeiden Sie zunächst produktive Schreibvorgänge.
4. Verbindungsablauf prüfen. Kontrollieren Sie, ob der Client den Dienst erreicht, Werkzeuge auflistet und Aufrufe korrekt verarbeitet. Bei älteren Implementierungen testen Sie ausdrücklich, ob sie ein früheres Handshake- oder Sitzungsverhalten erwarten.
5. Fehlerfälle und Wiederholungen testen. Prüfen Sie, was bei einem unterbrochenen Aufruf, einer erneuten Anfrage oder einem nicht verfügbaren abhängigen Dienst geschieht. Ein erfolgreicher einfacher Aufruf beweist noch nicht, dass Schreibvorgänge sicher wiederholt werden können.
6. Schrittweise umstellen und Rückweg dokumentieren. Wechseln Sie nicht alle Nutzer gleichzeitig, wenn Sie dadurch keine Fehler eingrenzen können. Halten Sie fest, wie Sie auf die vorherige Verbindung oder Serverkonfiguration zurückschalten, und entfernen Sie den Rückweg erst, wenn die Kompatibilität im vorgesehenen Betrieb bestätigt ist.

Für die Verbindung zu einem entfernten Server müssen Sie auch den administrativen Zugang zur Maschine und den Netzwerkzugriff getrennt planen. Die Anleitung zum SSH-Zugang bei OVN Cloud behandelt den Serverzugang; SSH-Zugang ist jedoch nicht gleichbedeutend mit dem Zugriffsschutz für Ihren MCP-Endpunkt. Verwechseln Sie diese Ebenen nicht.

Fünfter Schritt: Halten Sie lang laufende und schreibende Abläufe in der Anwendung nach

Ein Aufruf, der nur eine kurze, unabhängige Antwort erzeugt, hat andere Wiederherstellungsanforderungen als ein Werkzeug, das einen länger laufenden Geschäftsprozess anstößt. Bei längeren Vorgängen sollte Ihre Anwendung einen nachvollziehbaren Auftrag oder Prozessstatus speichern, statt darauf zu vertrauen, dass eine einzelne Protokollverbindung den gesamten Ablauf abbildet.

Für schreibende Werkzeuge ist Idempotenz besonders wichtig. Wenn ein Client nach einem Zeitüberschreiten nicht weiß, ob eine Änderung ausgeführt wurde, kann eine automatische Wiederholung denselben Vorgang doppelt auslösen. Legen Sie deshalb fest, wie Ihre Anwendung Wiederholungen erkennt, wie sie den aktuellen Status zurückliefert und wie sie Fehler nach einem teilweise abgeschlossenen Ablauf behandelt. Diese Regeln müssen zum jeweiligen Fachvorgang passen; MCP selbst liefert keine allgemeine Garantie, dass jede Operation gefahrlos erneut ausgeführt werden kann.

Prüfen Sie nach der Bereitstellung anhand einer kleinen, dokumentierten Testreihe:

• Ein berechtigter Client kann den erwarteten Endpunkt erreichen; ein nicht berechtigter Client erhält keinen unbeabsichtigten Zugriff.
• Ein Werkzeugaufruf liefert eine nachvollziehbare Antwort oder einen verständlichen Fehler.
• Protokolle enthalten genug Informationen zur Fehlersuche, aber keine unnötigen Zugangsdaten oder vertraulichen Nutzdaten.
• Ein fehlgeschlagener oder unterbrochener Auftrag lässt sich anhand des fachlichen Status beurteilen.
• Eine Wiederholung führt nicht unbeabsichtigt zu doppelten Schreibvorgängen.
• Nach einem Neustart sind dauerhaft benötigte Geschäfts- und Auftragsdaten weiterhin verfügbar, soweit Ihre Anwendung dies verlangt.
• Eine Änderung an SDK oder Client kann in der Testumgebung geprüft und bei Problemen zurückgenommen werden.

Die Protokolländerung vom 28.07.2026 kann die Behandlung der Protokollsitzung vereinfachen, aber nicht die Prüfung dieser Anwendungseigenschaften ersetzen. Wer den Zustand fälschlich vollständig aus dem System entfernt, verliert möglicherweise gerade die Informationen, die bei Wiederholungen, Fehlern und Wiederherstellung benötigt werden.

Entscheidungshilfe: Ordnen Sie Transport und Einsatz nach Ihren Anforderungen

Die folgende Gegenüberstellung hilft bei der Auswahl des Betriebsmodells. Sie ersetzt nicht die Versionsprüfung: Selbst wenn ein Transport zum Szenario passt, müssen Client, SDK und Server ihn unterstützen.

Vor dem Wechsel: Prüfen Sie Versionen und Betriebsfolgen gemeinsam

Nutzen Sie diese Checkliste, bevor Sie den bisherigen Betrieb ändern. Arbeiten Sie die Punkte einzeln ab und dokumentieren Sie offene Fragen, statt Kompatibilität aus dem Umstand abzuleiten, dass ein Testaufruf funktioniert hat.

• [ ] Ist klar, ob der Dienst lokal über stdio oder gemeinsam über Streamable HTTP genutzt werden soll?
• [ ] Sind Clients, SDK-Fassungen und Serverversionen für den tatsächlichen Einsatz erfasst?
• [ ] Wurden die Protokolländerungen und die offizielle SDK-Unterstützung anhand aktueller Dokumentation geprüft?
• [ ] Ist festgelegt, ob der HTTP-Endpunkt öffentlich, intern oder nur über einen kontrollierten Netzwerkpfad erreichbar sein soll?
• [ ] Sind Authentifizierung, Berechtigungen, Protokollierung und Umgang mit vertraulichen Daten geprüft?
• [ ] Sind fachliche Daten, Zugangsdaten und Langzeitstatus von der Protokollsitzung getrennt behandelt?
• [ ] Wurden Wiederholungen und Fehler bei schreibenden oder länger laufenden Werkzeugen getestet?
• [ ] Gibt es einen dokumentierten Rückweg, falls ein älterer Client den neuen Ablauf nicht unterstützt?

Ein Server lohnt sich vor allem dann, wenn Werkzeuge teamweit verfügbar sein sollen, wenn mehrere Dienste dauerhaft zusammenarbeiten oder wenn Sie Betrieb und Änderungen zentral verantworten müssen. Ein einzelner Entwickler mit lokalem Werkzeugzugriff kann mit stdio oft einfacher arbeiten. Für eine einzelne kurze Aufgabe oder sehr geringe, wechselnde Nutzung ist eine dauerhaft gemietete Maschine dagegen nicht automatisch wirtschaftlicher; vergleichen Sie den tatsächlichen Betriebsaufwand und die Laufzeit.

Wenn Sie von gemeinsam genutzten Cloud-Instanzen oder VPS zu einer eigenen physischen Maschine wechseln, prüfen Sie die konkreten Nachteile Ihres bisherigen Angebots: gemeinsam genutzte Ressourcen können zu schwankender Leistung führen, CPU-Zuteilung und Datenverkehr können je nach Tarif Einschränkungen oder schwer vergleichbare Kosten verursachen, und Betriebssystem- oder Datenträgeroptionen sind nicht immer frei wählbar. Das trifft nicht pauschal auf jeden Anbieter zu; entscheidend sind Ihre Vertragsbedingungen und Ihr gemessenes Lastprofil.

Für dauerhaft betriebene MCP-Werkzeuge und weitere Container kann ein dedizierter AMD-Server von OVN Cloud passend sein, wenn Sie eine Maschine exklusiv nutzen möchten und die konkrete Konfiguration zu Ihrer Anwendung passt. Prüfen Sie vor der Entscheidung die verfügbaren Serverkonfigurationen und Systemoptionen, statt Speicherbedarf oder Parallelität aus allgemeinen MCP-Anforderungen abzuleiten. Der technische Nutzen entsteht nicht aus dem Protokollwechsel allein, sondern daraus, dass Transport, Zugriffsschutz, Anwendungszustand und reale Serverauslastung zusammenpassen.