MCP-Server hosten: gehostet, selbst gehostet oder serverless

Nimm gehostet, wenn dein Agent OAuth, Token-Refresh und eine Verfügbarkeit braucht, die du nicht selbst tragen willst. Nimm selbst gehostet, wenn die Daten dein Netzwerk nicht verlassen dürfen. Serverless liegt dazwischen und ist 2026 einfacher geworden: die Spec-Revision vom 28. Juli hat Sessions auf Protokollebene entfernt, ein Remote-MCP-Server kann also jetzt zustandslos sein.

Was MCP-Server-Hosting nach der Spec 2026-07-28 bedeutet

Ein MCP-Server antwortet per JSON-RPC über eines von zwei Bindings. Bei stdio startet dein Client ihn als Subprozess auf derselben Maschine. Bei Streamable HTTP ist er ein Webservice mit einem einzigen POST-Endpoint. Hosting ist nur beim zweiten eine Frage.

Revision 2026-07-28 hat geändert, was dieser Service im Speicher halten muss. Sie hat Sessions auf Protokollebene und den eigenständigen GET-Stream entfernt und die Protokollversion sowie die Client-Capabilities in _meta-Felder pro Anfrage verschoben, die der Transport in HTTP-Header spiegelt. Frühere Revisionen, 2025-03-26 bis 2025-11-25, machten es umgekehrt: der Server konnte eine Mcp-Session-Id ausstellen, der Client konnte mit GET einen langlebigen Stream wieder öffnen, und Streams waren wiederaufnehmbar mit Last-Event-ID. Keiner dieser Mechanismen existiert in der aktuellen Revision, und ein Server, der nur sie spricht, sollte GET oder DELETE auf dem MCP-Endpoint mit einem 405 Method Not Allowed beantworten.

Diese einzige Änderung ist der größte Teil der Hosting-Geschichte. Ein Server ohne Session-State ist ein gewöhnlicher zustandsloser HTTP-Service: lass vier Replicas hinter einem Load Balancer laufen, deploye mitten im Gespräch, verliere eine Instanz, und kein Client muss sich neu verbinden. Ein Server, der noch die 2025er Revisionen spricht, muss jede Anfrage zurück an die Instanz mit dieser Session routen, und deshalb waren so viele frühe Remote-Deployments eine Kiste mit Sticky Sessions und einem nervösen Besitzer.

Zwei Vorbehalte, die du vor der Kapazitätsplanung kennen solltest. Streams sind nicht mehr wiederaufnehmbar, eine abgebrochene Verbindung heißt also, dass der Client die Anfrage neu stellt, statt dort weiterzumachen, wo er war. Und langlebige Änderungsbenachrichtigungen laufen jetzt über den Antwort-Stream einer subscriptions/listen-Anfrage, und das ist ein Stream, den du offen halten musst, mit Keep-alive-Kommentaren, so lange der Client zuhört.

Remote-MCP-Server oder lokal: was sich wirklich ändert

Ein lokaler stdio-Server erbt deine Maschine: dein Dateisystem, deine Umgebungsvariablen, dein Netzwerk. Credentials kommen aus der Umgebung, und die Spec sagt ausdrücklich, dass stdio-Implementierungen dem OAuth-Flow nicht folgen sollen. Deshalb ist ein lokaler Server schnell gebaut und unmöglich zu teilen.

Sobald der Server remote ist, landen vier Dinge bei dem, der ihn betreibt:

• Identität. Server über HTTP sind OAuth 2.1 Resource Server. Sie müssen Protected Resource Metadata (RFC 9728) implementieren, prüfen, dass jeder Token für sie als Audience ausgestellt wurde, gemäß der Autorisierungs-Spec, und 401 mit einem WWW-Authenticate-Header zurückgeben, der die resource_metadata-URL und den erforderlichen scope trägt.
• Plattform-Tokens. Der Token des Agenten bringt ihn in deinen Server. Dein Server braucht trotzdem eigene Credentials für alles, womit er spricht, und die laufen nach dem Kalender anderer Leute ab.
• Logs. Ein Tool-Aufruf, der etwas veröffentlicht hat, ist eine Handlung in der Welt. Ohne Protokoll pro Aufruf kannst du nicht sagen, was der Agent um 3 Uhr nachts getan hat.
• Verfügbarkeit. Ein Agent, der den Server nicht erreicht, degradiert nicht sanft, er meldet, dass das Tool nicht existiert.

Die Arbeit, die bei einem gehosteten MCP-Server niemand einrechnet

Der OAuth-Tanz ist der Teil, den Leute schätzen, und er ist nicht der teure Teil. Die teuren Teile sind die ohne Enddatum.

Token-Refresh ist das Erste. Jede Plattform, die du verbindest, gibt dir ein Credential mit eigener Lebensdauer und eigenem Erneuerungsritual zurück, und ein stilles Ablaufen sieht genau wie ein Bug in deinem Agenten aus. Die WhatsApp-Docs von PlugKit sagen es konkret: verbinde eine echte Nummer, denn eine Meta-Testnummer bringt einen 24-Stunden-Token mit und funktioniert am nächsten Tag nicht mehr.

Das Zweite ist die Consent-Schleife. Tokens laufen ab, Leute entziehen Apps die Rechte, und Scopes erweisen sich als zu eng. Die Spec hat für den letzten Fall einen Weg: der Server antwortet mit 403 und error="insufficient_scope" und den nötigen Scopes, und der Client fährt einen Step-up-Flow, der die Vereinigung aus dem Bisherigen und dem gerade Verlangten anfragt. Implementiere das schlecht, und deine Nutzer leben in einer Redirect-Schleife.

Das Dritte ist einfach erreichbar sein. Agenten wiederholen Anfragen, und ein Agent, der ein Publishing-Tool wiederholt, ist kein idempotentes Ereignis.

Gehostet, selbst gehostet oder serverless

Serverless liest sich am günstigsten und ist es oft auch, für einen Read-only-Server über einer öffentlichen API ohne Credentials, die man halten muss. Füge OAuth und erneuerbare Plattform-Tokens hinzu, und du hast eine Datenbank, einen Scheduler und einen Secret-Store wieder eingeführt, also genau die Infrastruktur, die du vermeiden wolltest. Füge einen offenen Benachrichtigungsstream hinzu, und du läufst in Laufzeitlimits.

Selbst hosten gewinnt mit zwei Argumenten, und es sind gute: die Daten dürfen dein Netzwerk wirklich nicht verlassen, oder die Tools, die du bereitstellst, sind deine und niemand verkauft sie. Wenn eines davon zutrifft, hoste selbst und plane die OAuth-Arbeit als echte Arbeit ein.

Wo PlugKit steht, und wann es die falsche Antwort ist

PlugKit ist der gehostete Fall für eine enge Aufgabe: einem Agenten deine Social-Accounts zu geben. Der Server liegt unter https://api.plugkit.co/mcp, spricht Streamable HTTP, ist zustandslos und stellt 103 Tools plus drei vorgefertigte Workflows bereit, geprüft auf docs.plugkit.co am 21. Oktober 2026. Die Authentifizierung ist OAuth 2.1 mit PKCE und ohne Client Secret, mit zwei Scopes: mcp:read für Profile, Accounts, Posts, Konversationen und Analytics, mcp:write zusätzlich für Veröffentlichen, Nachrichten, Kommentarantworten und das Verbinden von Accounts. Clients ohne OAuth senden einen API-Key als Bearer-Token, der Vollzugriff und keine Scopes hat.

Ihn zu Claude Code hinzuzufügen ist eine Zeile:

claude mcp add -t http plugkit https://api.plugkit.co/mcp

Es kostet $49 pro Monat für 5 verbundene Accounts oder $97 für 30, jederzeit kündbar, nach 7 Tagen gratis ohne Karte, mit einem verbundenen Account während der Testphase. Ein ehrlicher Vorbehalt aus denselben Docs: der Server bittet das Modell, vor einem öffentlichen Schreibvorgang deine Zustimmung einzuholen, und das ist eine Anweisung auf Prompt-Ebene, keine erzwungene Kontrolle. Wenn dir das wichtig ist, gib mcp:read und halte Schreibvorgänge hinter deinem eigenen Code.

PlugKit ist die falsche Antwort, wenn die Tools, die du willst, keine Social-Accounts sind, wenn deine Compliance-Regeln sagen, dass die Tokens in deiner VPC bleiben, oder wenn du deterministisches Veröffentlichen ohne Modell in der Schleife willst. Der letzte Fall ist ein REST-Aufruf, gar kein MCP-Server, und der Kompromiss steht in MCP oder REST-API für deinen Agenten. Für die Authentifizierungsmechanik im Detail lies MCP-Server-OAuth. Wie ein gehosteter Server für eine einzige Plattform in der Praxis aussieht, zeigt der Instagram-MCP-Server, und wer sonst einen anbietet, Social-Media-MCP-Server im Vergleich.

FAQ

Muss ich überhaupt einen MCP-Server hosten?

Nicht, wenn er auf deiner eigenen Maschine für deinen eigenen Gebrauch läuft. Ein stdio-Server, den dein Client startet, braucht kein Hosting und kein OAuth, und er liest Credentials aus der Umgebung. Hosting brauchst du in dem Moment, in dem eine zweite Person, ein Telefon oder ein Cloud-Agent dieselben Tools erreichen muss.

Kann ein MCP-Server zustandslos sein?

Seit Revision 2026-07-28, ja. Diese Revision hat Sessions auf Protokollebene und den GET-Stream entfernt, also trägt jeder POST seine eigenen Metadaten und jede Instanz kann ihn beantworten. Server, die die 2025er Revisionen weiter unterstützen, halten Session-State und brauchen Sticky Routing.

Was macht ein gehosteter MCP-Server wirklich, das ich sonst selbst bauen müsste?

Der OAuth 2.1 Resource Server mit Protected Resource Metadata und Audience-Prüfung, die Refresh-Schleife für jeden Plattform-Token, das Audit-Log pro Aufruf, der Step-up-Flow, wenn ein Scope fehlt, und die Verfügbarkeit. Das Erste ist ein Sprint; der Rest hört nie auf.

Passt serverless zu MCP?

Für einen Read-only-Server ohne gespeicherte Credentials ja. Sobald du OAuth, erneuerbare Tokens oder einen offenen subscriptions/listen-Stream brauchst, brauchst du dauerhaften State und lange Verbindungen, und am Ende baust du einen Server mit Zusatzschritten nach.

Wie richte ich einen Client auf einen Remote-MCP-Server aus?

Gib ihm die Endpoint-URL. In Claude Code claude mcp add -t http <name> <url>. In den Claude-Apps: Customize, dann Connectors, dann ein eigener Connector. In Cursor oder VS Code ein Ein-Klick-Installationslink oder drei Zeilen JSON. Der Client findet den Authorization Server über den 401, den der Endpoint zurückgibt.

AB

Antoine BlancoGründer von PlugKit. Betreibt seine eigenen Instagram-, YouTube- und X-Accounts über die hier beschriebene API und den MCP-Server.