27.04.2025 AI Engineering 5 Minuten Lesezeit

Remote-MCP-Server: Von stdio zu authentifizierten Endpunkten

Die MCP-Spezifikationsrevision 2025-03-26 ersetzte den HTTP+SSE-Transport durch Streamable HTTP und ergänzte ein Autorisierungsframework auf Basis von OAuth 2.1. Wir zeichnen den Weg von lokalen stdio-Servern zu authentifizierten Remote-Endpunkten nach, betrachten die ersten Angebote von Cloudflare, GitHub und Stripe und beschreiben Integrationsmuster sowie offene Lücken für den Unternehmenseinsatz.

Warum lokale MCP-Server nicht skalieren

Anthropic hat das Model Context Protocol (MCP) am 25. November 2024 als offenen Standard veröffentlicht. Die erste Spezifikationsrevision 2024-11-05 definiert die Anbindung externer Werkzeuge so: Der Client startet den Server als Kindprozess und tauscht JSON-RPC-2.0-Nachrichten über stdin und stdout aus. Dieses Design ist bewusst gewählt. Es braucht weder Netzwerkstack noch TLS noch Authentifizierung. Es bedeutet aber auch: Jeder Server läuft auf dem Rechner der Person, die ihn nutzt.

Diese Einschränkung übersteht den Kontakt mit einer Organisation nicht. Jeder Entwickler installiert Server einzeln per npx oder Docker. API-Schlüssel liegen im Klartext in JSON-Konfigurationsdateien im Home-Verzeichnis. Es gibt kein zentrales Inventar darüber, welche Server wo laufen, keine Richtliniendurchsetzung, keine Versionskontrolle und keinen Audit-Trail. Support-Tickets ersetzen Deployment-Pipelines. Ein Protokoll für den einzelnen Desktop muss erst ein Protokoll für Netzwerke werden, bevor Unternehmen es in der Breite einsetzen können.

Ein Agent erreicht seine Tools über MCP — eine Standard-Schnittstelle. 1/4

Streamable HTTP ersetzt den doppelten Endpunkt

Die Revision 2024-11-05 enthielt bereits eine Remote-Option namens HTTP+SSE. Sie verlangte zwei Endpunkte: einen langlebigen Server-Sent-Events-Stream für Nachrichten vom Server zum Client und einen separaten POST-Endpunkt für die Gegenrichtung. In der Praxis brach die persistente SSE-Verbindung hinter Proxys und Load-Balancern an Puffern und Idle-Timeouts ab; zustandsloses Deployment auf Serverless-Plattformen war damit unmöglich.

Die Revision vom 26. März 2025 ersetzte dieses Modell durch Streamable HTTP (PR #206). Ein einziger Endpunkt nimmt JSON-RPC per POST entgegen; der Server antwortet mit einer einfachen JSON-Antwort oder eskaliert auf einen SSE-Stream, wenn er mehrere Nachrichten senden muss. Sitzungen identifiziert der Header Mcp-Session-Id. Server können jetzt vollständig zustandslos sein — aber nur, wenn sie es wollen. Langlaufende Werkzeuge und wiederaufnehmbare Streams erfordern weiterhin serverseitigen Zustand.

OAuth 2.1 wird Teil des Protokolls

Dieselbe Revision ergänzte ein Autorisierungsframework auf Basis von OAuth 2.1 (PR #133). Clients entdecken die Autorisierungsendpunkte über Server-Metadaten (RFC 8414), registrieren sich per Dynamic Client Registration (RFC 7591) und erhalten Tokens über einen Authorization-Code-Flow mit verpflichtendem PKCE. Erstmals kann ein MCP-Client damit Zugriff auf einen ihm bislang unbekannten Server aushandeln, ohne dass jemand Schlüssel manuell austauschen muss.

Das Framework hat eine bekannte Schwäche. Laut Spezifikation ist der MCP-Server zugleich Resource Server und Authorization Server. Unternehmen wollen aber keinen Tool-Endpunkt, der Tokens ausstellt; sie wollen an einen bestehenden Identity Provider delegieren. Aaron Parecki veröffentlichte am 3. April 2025 einen viel diskutierten Vorschlag zur Trennung beider Rollen. Zum Zeitpunkt dieses Artikels hat die Spezifikation ihn nicht übernommen.

Die ersten herstellergehosteten Server

Cloudflare lieferte am 25. März 2025 das erste Hosting-Substrat. workers-oauth-provider macht einen Worker zum spezifikationskonformen OAuth-2.1-Provider inklusive Registrierung nach RFC 7591. McpAgent übernimmt den Remote-Transport auf Durable Objects und soll den Wechsel zu Streamable HTTP nachvollziehen. mcp-remote überbrückt Clients, die nur stdio sprechen; der Workers-AI-Playground dient als fertiger Remote-Client. Auch GitHub und Stripe liefern offizielle Server — beachten Sie die Statusspalte: Beide laufen zu diesem Datum noch lokal.

Das Muster ist dennoch erkennbar: Anbieter übernehmen die Verantwortung für ihre Integrationen — GitHub hat den Referenzserver gemeinsam mit Anthropic in Go neu geschrieben — während Plattformen das Hosting übernehmen. Vom Anbieter gebaut heißt noch nicht vom Anbieter gehostet. Wir erwarten, dass die Statusspalte dieser Tabelle in wenigen Monaten anders aussieht.

Anbieter	Server	Transport	Authentifizierung	Status (April 2025)
Cloudflare	McpAgent + workers-oauth-provider	SSE (Streamable HTTP angekündigt)	OAuth-2.1-Provider mit Registrierung nach RFC 7591	Auf Workers verfügbar seit 25.03.2025
GitHub	github-mcp-server (Go)	stdio via Docker	Personal Access Token	Public Preview seit 04.04.2025
Stripe	@stripe/mcp (Agent Toolkit)	stdio via npx	Eingeschränkter API-Schlüssel	Auf npm seit 19.02.2025

Integrationsmuster für Unternehmen

Das dominierende Muster für authentifizierte Endpunkte ist die OAuth-Fassade. Der MCP-Server agiert gegenüber MCP-Clients als OAuth-Provider und gegenüber dem vorgelagerten System — GitHub, Google oder ein firmeneigener Identity Provider — als OAuth-Client. An Clients ausgestellte Tokens sind auf MCP-Werkzeuge beschränkt; Upstream-Credentials verlassen den Server nie. workers-oauth-provider implementiert genau diese Doppelrolle.

Für interne Rollouts empfehlen wir ein zweites Muster: ein einzelnes MCP-Gateway als einzigen Egress-Punkt. Es terminiert OAuth, erzwingt eine Server-Allowlist, protokolliert jeden Tool-Aufruf und überbrückt stdio-Clients während der Übergangszeit per mcp-remote. Kombinieren Sie das mit minimalen Rechten: eingeschränkte API-Schlüssel statt kontoweiter Secrets sowie die Tool-Annotationen der Revision 2025-03-26 — readOnlyHint, destructiveHint — sichtbar zur Bestätigung durch die Nutzer.

Entscheiden Sie früh, wessen Identität ein Tool-Aufruf trägt. Ein OAuth-Flow pro Nutzer liefert feingranulare Nachvollziehbarkeit, multipliziert aber die Consent-Dialoge; eine Service-Identität vereinfacht den Rollout, verwischt jedoch den Audit-Trail. Mischmodelle sind legitim: Nutzeridentität für destruktive Operationen, Service-Identität für lesende Zugriffe. Das Protokoll nimmt Ihnen diese Entscheidung nicht ab.

Was Remote MCP nicht löst

OAuth authentifiziert den Client. Es macht Tool-Ausgaben nicht vertrauenswürdig. Tool-Beschreibungen sind Modell-Input, und Anfang April 2025 demonstrierten Sicherheitsforscher Tool-Poisoning-Angriffe, bei denen ein bösartiger Server das Modell über seine eigenen Metadaten manipuliert. Remote-Deployment vergrößert diese Angriffsfläche: Ein Server kann seine Tool-Definitionen nach der Freigabe ändern. Pinning und Review von Serverversionen bleiben Aufgabe des Betreibers.

Zwei weitere Lücken sind operativer Natur. Das Protokoll definiert kein Audit- oder Logging-Format; Nachvollziehbarkeit ist das, was das Gateway aufzeichnet. Die Client-Unterstützung ist fragmentiert: Im April 2025 sprechen die meisten Clients noch den Transport von 2024-11-05, weshalb ernstzunehmende Server beide Transporte parallel anbieten. Und Dynamic Client Registration — auf die sich die Spezifikation stützt — ist in Unternehmens-Identity-Providern selten aktiviert; das manuelle Client-Onboarding kehrt durch die Hintertür zurück.

Ausblick vom April 2025

Die Richtung ist eindeutig. OpenAI kündigte am 26. März 2025 MCP-Unterstützung im Agents SDK an; Google DeepMind bestätigte am 9. April 2025 MCP-Unterstützung für Gemini. Ein einheitliches Drahtformat für Werkzeugzugriff über Herstellergrenzen hinweg ist keine Hypothese mehr. Wir erwarten drei Entwicklungen: Die Autorisierungsspezifikation wird Resource Server und Authorization Server trennen. Große SaaS-Anbieter werden eigene Endpunkte hosten. Clients werden Remote-Verbindungen mit OAuth nativ beherrschen — und mcp-remote verschwindet.

Unser Rat mit Stand heute: Behandeln Sie einen MCP-Endpunkt wie jedes andere API-Produkt. Geben Sie ihm einen Owner, eine Identitätsgrenze, Scopes, Monitoring und eine Deprecation-Policy. Das Protokoll wird sich weiter ändern — die Revision 2025-03-26 ist fünf Wochen alt. Diese Betriebsdisziplinen ändern sich nicht.