Remote- vs. lokale MCP-Server: Was solltest du nutzen?
Die kurze Antwort: Betreib einen lokalen MCP-Server über stdio, wenn das Tool deine Maschine braucht (deine Dateien, deine Shell, deine lokalen Repos), und einen Remote-MCP-Server über Streamable HTTP, wenn das Tool ohnehin in der Cloud lebt oder mehr als eine Person es nutzt. Die meisten funktionierenden Setups landen bei ein paar von beidem, aber der Zug geht klar Richtung Remote, und die MCP-v2-Spezifikation verstärkt das.
Falls dir die Grundlagen noch unscharf sind, lies zuerst [was ein MCP-Server eigentlich ist](/de/blog/what-is-an-mcp-server). Dieser Beitrag setzt das Client-Server-Bild voraus und hilft bei der Frage, wo der Server leben soll.
Was lokal und remote konkret heißt
Ein lokaler MCP-Server ist ein Prozess, den dein MCP-Client auf deinem eigenen Rechner startet und mit dem er über stdin und stdout spricht. Das ist der stdio-Transport. Kein Netzwerk-Hop, kein Port, kein Login-Handshake. Beendet sich der Client, endet der Server mit ihm.
Ein Remote-MCP-Server läuft woanders, meist auf der Infrastruktur des Anbieters, und dein Client spricht mit ihm über Streamable HTTP unter einer normalen URL. Authentifizierung läuft typischerweise über OAuth, und der Server läuft weiter, egal ob dein Client offen ist.
Gleiches Protokoll, gleiche Tool-Liste, gleiche Aufruf-Semantik. Der einzige Unterschied ist, wo der Prozess lebt, und dieser eine Unterschied treibt alles Folgende.
Wo ein lokaler MCP-Server gewinnt
- Dein Dateisystem. Dateien auf deinem Laptop lesen und schreiben ist der klassische stdio-Job. Ein Remote-Server sieht deine Platte nicht, und das willst du auch nicht.
- Dev-Tools. Git, Testrunner, Linter, lokale Datenbanken, Build-Skripte. Die leben auf deiner Maschine, also sollte der Server, der sie steuert, das auch.
- Privatsphäre und Latenz. Daten verlassen die Maschine nie, und kein Aufruf macht eine Netzwerk-Runde.
- Offline-Arbeit. Einem stdio-Server ist deine Internetverbindung egal.
Die Kosten sind operativ. Du installierst den Server auf jeder Maschine, hältst eine Node- oder Python-Laufzeit auf der richtigen Version, deine JSON-Konfiguration driftet zwischen Laptop und Desktop auseinander, und Updates sind dein Problem. Schlimmer: API-Keys für stdio-Server landen meist im Klartext in Konfigurationsdateien.
Wo ein Remote-MCP-Server gewinnt
- SaaS-Tools. Dein CRM, Helpdesk oder Issue-Tracker lebt schon in der Cloud. Ein Remote-Server sitzt neben den Daten, statt sie durch deinen Laptop zu schleusen.
- Null Installation. Du fügst eine URL in deinen Client ein. Keine Laufzeit, kein npm, kein Versions-Chaos.
- Eine Version für alle. Der Anbieter betreibt den Server, und alle Nutzer verbinden sich mit demselben aktuellen Stand.
- Echte Auth. OAuth-Login mit begrenzten, widerrufbaren Tokens statt eines Keys in der Konfigdatei.
- Clients, die keine Prozesse starten können. Web- und Mobile-Agenten können keinen Subprozess starten. Remote ist ihre einzige Option.
Die Kosten: Du brauchst eine Netzwerkverbindung, du vertraust dem Betreiber des Servers, und ein schlecht betriebener Remote-Endpunkt ist eine Angriffsfläche, die ein lokaler Prozess nicht ist.
Remote vs. lokal: die Entscheidungstabelle
| Deine Situation | Nimm | Warum |
|---|---|---|
| Dateien auf deiner eigenen Maschine | Lokal (stdio) | Nur ein lokaler Prozess sieht deine Platte |
| Git, Tests, Builds, lokale Datenbanken | Lokal (stdio) | Die Tools selbst sind lokal |
| Ein SaaS-Tool (CRM, Helpdesk, Tracker) | Remote (Streamable HTTP) | Die Daten sind schon remote, OAuth schlägt eingeklebte Keys |
| Ein ganzes Team auf denselben Tools | Remote | Eine URL, eine Version, Login pro Nutzer |
| Ein Web- oder Mobile-Agent | Remote | Er kann keine Subprozesse starten |
| Offline- oder Air-Gap-Arbeit | Lokal (stdio) | Kein Netzwerk nötig |
| Keine Lust auf Laufzeit-Pflege | Remote | Nichts zu installieren oder zu aktualisieren |
Oder als Einzeiler: lokal für das, was auf der Maschine ist, remote für alles andere.
Das Ökosystem zieht Richtung Remote
Zwei Signale stechen heraus. Erstens liefern Anbieter zunehmend einen gehosteten MCP-Endpunkt statt eines npm-Pakets zum Selberbetreiben, weil eine URL leichter zu supporten ist als tausend leicht unterschiedliche lokale Installationen. Zweitens die Spezifikation selbst: Streamable HTTP hat den älteren SSE-basierten Remote-Transport abgelöst, und MCP v2, final seit dem 28. Juli 2026, ist stateless-first. Requests tragen, was sie brauchen, sodass Server auf Serverless-Infrastruktur laufen und horizontal skalieren können, ohne klebrige Sessions. Das ist eine Spezifikation, die mit Blick auf Remote-Deployment geschrieben wurde. [Was sich mit MCP v2 ändert](/de/blog/what-is-mcp-v2) steht im Detail-Beitrag.
Lokal verschwindet nicht. Dateien und Dev-Tools sind von Natur aus lokal, und stdio bleibt in der Spezifikation. Aber der Default für alles SaaS-Förmige ist jetzt eine URL, keine Installation.
Wenn du sofort einen Remote-Server ausprobieren willst: Unser Verzeichnis-Server auf https://mcp.tulimoa.com/mcp spricht Streamable HTTP mit Lesezugriff ohne Login. Eine Zeile, claude mcp add --transport http tulimoa https://mcp.tulimoa.com/mcp, und dein Agent durchsucht den ganzen Katalog ohne Account. Die [MCP-Seite](/de/mcp) dokumentiert alle fünf Tools.
Eine Warnung, bevor du URLs sammelst: Jeder Server, den du hinzufügst, schiebt seine Tool-Schemas in den Kontext deines Agenten, und zehn Remote-Server verbinden sich so leicht wie einer. Genau so blähen sich Tool-Kataloge auf. Für den Fall haben wir [Wie viele MCP-Server sind zu viele?](/de/blog/how-many-mcp-servers-is-too-many) geschrieben.
Häufige Fragen
Ist stdio in MCP v2 veraltet?
Nein. stdio ist weiter Teil der Spezifikation, und lokale Server sprechen es weiterhin. Die Stateless-first-Änderungen in v2 machen Remote-Server leichter zu bauen und zu skalieren; lokale schaffen sie nicht ab.
Was ist Streamable HTTP bei MCP?
Der aktuelle Transport für Remote-MCP-Server. Der Client schickt JSON-RPC über gewöhnliche HTTP-POSTs an einen einzelnen Endpunkt, und der Server kann eine Antwort streamen, wenn ein Aufruf dauert. Er hat die frühere Kombination aus HTTP plus SSE ersetzt, die einen separaten, langlebigen Event-Stream brauchte.
Kann ich lokale und Remote-MCP-Server gleichzeitig nutzen?
Ja, und die meisten echten Setups sollten das. Clients behandeln jeden verbundenen Server gleich, unabhängig vom Transport. Ein Dateisystem-Server über stdio und ein CRM-Server über Streamable HTTP stehen nebeneinander in einer Tool-Liste.
Brauchen Remote-MCP-Server immer einen Login?
Nein. Auth wird pro Server entschieden, manchmal pro Tool. Tulimoas Verzeichnis-Server zum Beispiel beantwortet seine drei Lese-Tools ganz ohne Account und verlangt OAuth nur für die beiden Schreib-Tools.