Die Wörter lokal und Cloud werden bei MCP-Servern so verwendet, als wäre damit die Frage nach dem Datenschutz erledigt. Ist sie nicht. Sie beantworten genau eine Frage — wo der Serverprozess läuft — und lassen die Frage unberührt, auf die es den meisten wirklich ankommt: wer am Ende Ihre Daten lesen kann.
Kurz gefasst: Ein lokaler MCP-Server hält Ihre Daten von der Infrastruktur des Anbieters fern; aus dem Gespräch hält er sie nicht heraus. Was Ihr Assistent über einen MCP-Server liest, ob lokal oder in der Cloud, geht an das Modell, mit dem Sie gerade schreiben. Lokal ändert, wer Ihre Daten speichert und wer an sie herankommt. Was das Modell sieht, ändert es nicht.
Dieser Artikel trennt diese beiden Dinge. Wenn Ihnen das Protokoll selbst neu ist, klärt was ein MCP-Server ist zuerst die Grundlagen.
Die MCP-Spezifikation in der Revision 2026-07-28 definiert genau zwei Standardtransporte, und sie entsprechen sauber den beiden Wörtern.
stdio — der lokale Transport. Der Client startet den MCP-Server als Unterprozess, und beide sprechen über dessen Standardein- und -ausgabe, eine JSON-RPC-Nachricht pro Zeile, getrennt durch Zeilenumbrüche. Es gibt keine Netzwerkverbindung und keinen Port. Beendet sich der Client, schließt er den Eingabestrom des Servers, und der Prozess fährt herunter. Das ist es, was „läuft auf Ihrem Rechner“ konkret bedeutet.
Streamable HTTP — der Cloud-Transport. Der Server ist ein eigenständiger
Prozess mit einem einzigen HTTP-Endpunkt, und jede Nachricht ist ein HTTP-POST
dorthin. Der Client erreicht ihn über das Netz unter einer URL wie
https://mcp.example.com/mcp. Das ist der Transport hinter jedem
„Konto verbinden“-Button.
Der Unterschied ist eine Frage des Betriebs, nicht der Fähigkeiten. Die Spezifikation stellt ausdrücklich klar, dass die Protokollsemantik auf jedem Transport identisch ist: Ein Transport legt fest, wie Nachrichten verpackt und zugestellt werden, nicht was sie bedeuten. Ein Tool, das Ihre Meeting-Transkripte liest, tut so oder so dasselbe.
Das ist die Frage, für die die beiden Wörter meist stellvertretend stehen, und sie hat mehr als zwei Antworten. Vier Parteien können potenziell lesen, was durch eine MCP-Verbindung fließt.
| Wer | Lokaler Server (stdio) | Cloud-Server (HTTPS) |
|---|---|---|
| Der MCP-Anbieter | Bekommt die Daten nicht | Speichert sie und bedient jede Anfrage |
| Ihr Modellanbieter | Sieht alles, was der Assistent liest | Sieht alles, was der Assistent liest |
| Ihre KI-Client-App | Liest sie lokal, um den Prompt zu bauen | Ebenso |
| Wer das Token hält | Es gibt kein Token zu stehlen | Kommt an dieselben Daten, bis es widerrufen wird |
Die mittlere Zeile ist die, die überrascht, und sie ist in beiden Spalten gleich. Ein MCP-Server gibt dem Modell keinen privaten Seitenkanal. Er holt Text und reicht ihn an den Client weiter, der ihn in den Prompt setzt. Ab da haben die Daten Ihren Rechner verlassen, ganz gleich, wo der Server lief.
Die erste und die letzte Zeile sind die Stellen, an denen lokal wirklich gewinnt. Bei stdio gibt es kein Konto, keine gespeicherte Kopie auf fremder Festplatte und keine Zugangsdaten, die bei einem Leck gestohlen werden könnten — weil es nichts zu autorisieren gibt.
Es gibt hier drei Formen, nicht zwei, und Anbieter trennen die mittlere selten heraus.
Cloud-Server, Cloud-Daten. Der Anbieter hostet den Server, Sie autorisieren ihn per OAuth im Browser, und Ihr Client ruft über HTTPS auf, sobald er etwas braucht. Die natürliche Form, wenn Ihre Daten ohnehin in der Cloud dieses Anbieters liegen.
Lokaler Prozess, Cloud-Daten. Der Anbieter liefert einen Server, den Sie
selbst betreiben — ein npx-, uvx- oder docker-Befehl, gestartet von Ihrem
KI-Client, der einen API-Schlüssel hält. Lokal werden die Daten dadurch nicht.
Der Prozess läuft auf Ihrem Laptop und ruft dann für jede Anfrage die API des
Anbieters über das Netz auf. Das ist der Fall, den es auszuschließen lohnt, wenn
jemand sagt, sein MCP-Server sei lokal.
Lokaler Prozess, lokale Daten. Die Daten liegen ohnehin auf dem Rechner, der Server liest sie also ganz ohne Netzwerkaufruf. Das ist die einzige Form, in der „lokal“ die Daten beschreibt und nicht nur den Prozess.
Verräterisch sind die Zugangsdaten, nicht der Befehl. Eine Anmeldung im Browser heißt, dass die Daten dem Anbieter gehören und Sie den Zugriff freigeben. Ein API-Schlüssel in einer Konfigurationsdatei heißt, dass ein lokaler Prozess dessen API in Ihrem Namen aufruft. Lokale Daten sind beides nicht.
Wenn Sie sich für einen Cloud-MCP-Server durch einen OAuth-Dialog klicken, stellen Sie Zugangsdaten für Ihr Konto aus, und es lohnt sich zu wissen, was die können.
Die MCP-Spezifikation baut das auf OAuth 2.1 auf. Clients müssen den
resource-Parameter aus RFC 8707
senden, damit das Token an genau einen Server gebunden ist, und Server müssen
prüfen, dass ein Token für sie ausgestellt wurde, und dürfen nichts anderes
annehmen oder weiterreichen. Diese Mechanik verhindert, dass ein für einen
Dienst ausgestelltes Token gegen einen anderen wiederverwendet wird.
Drei praktische Folgen:
Für stdio gilt davon nichts. Die Autorisierungsspezifikation stellt klar, dass sie HTTP-basierte Transporte abdeckt und dass Implementierungen mit stdio ihr nicht folgen sollen, sondern Zugangsdaten aus der Umgebung beziehen.
Lokal ist kein Synonym für sicher, und die ehrliche Fassung dieses Arguments muss sagen, was man dafür aufgibt.
Meist gibt es keine Berechtigungsebene. Weil die Autorisierungsspezifikation nicht gilt, kennt ein stdio-Server in der Regel weder Nutzer noch Scopes. Alles, was unter Ihrem Benutzerkonto läuft, kann ihn üblicherweise starten und seine Tools aufrufen. Auf einem geteilten oder verwalteten Rechner zählt das.
Ein lokaler Server auf einem Port ist etwas anderes. Manche als lokal
beschriebenen Server lauschen tatsächlich auf HTTP. Die Spezifikation geht
direkt darauf ein: Server müssen den Origin-Header prüfen, um
DNS-Rebinding-Angriffe zu verhindern, und sollten sich lokal nur an 127.0.0.1
binden statt an 0.0.0.0. Ohne diese Schutzmaßnahmen, warnt die Spezifikation,
könnten Angreifer per DNS-Rebinding von entfernten Webseiten aus mit lokalen
MCP-Servern interagieren.
Sie erben die Lieferkette. Ein mit npx gestarteter Server lädt Code
herunter und führt ihn mit Ihren Rechten auf Ihrem Rechner aus. Die
OWASP MCP Top 10, Stand 2026 noch
in der Beta, führen unter ihren zehn Kategorien Angriffe auf die Lieferkette und
manipulierte Abhängigkeiten (MCP04:2025) sowie Tool Poisoning (MCP03:2025) —
Risiken, die eine lokale Installation mitbringt und ein gehosteter Endpunkt
nicht. Beim allgemeinen Fall wird die Spezifikation deutlich: Tools bedeuten die
Ausführung beliebigen Codes, und Beschreibungen des Tool-Verhaltens sollten als
nicht vertrauenswürdig gelten, sofern sie nicht von einem vertrauenswürdigen
Server stammen.
MCP ergänzt Ihre Daten nicht um ein Berechtigungsmodell. Es standardisiert, wie Tools beschrieben und aufgerufen werden; worauf ein einzelnes Tool zugreifen darf, hat der Autor des Servers entschieden. Daraus folgt zweierlei, unabhängig vom Transport:
Vier Fragen, in etwa einer Minute von jeder Einrichtungsseite zu beantworten.
https://-URL ist ein
Cloud-Server. Ein npx-, uvx- oder docker-Befehl ist ein Prozess auf
Ihrem Rechner.Ganz offen, denn die Wahl ist nicht einseitig:
Die Cloud verliert nur auf einer Achse, aber es ist die Achse, um die es in diesem Artikel geht: Eine Kopie Ihrer Daten liegt auf fremder Infrastruktur, erreichbar mit Zugangsdaten.
Stellen Sie zwei Fragen statt einer. Wo läuft der Server sagt Ihnen, wer Ihre Daten speichert und wer mit einem Token an sie herankommt. Was liest der Assistent sagt Ihnen, was an Ihren Modellanbieter geht — und diese Antwort ist in beiden Fällen dieselbe.
Wenn Sie die Form lokaler Prozess auf lokalen Daten suchen: Genau das macht der
MCP-Server von Speak-Y. Er ist Teil der Desktop-App, installiert sich
mit einem Klick aus Einstellungen → Integrationen und liest die Aufnahmen,
die ohnehin auf Ihrem Rechner liegen — ohne Konto, ohne API-Schlüssel und ohne
gehostete Kopie. Das Lesen funktioniert auch bei geschlossener App; die
Werkzeuge, die etwas ändern, laufen über die App und fragen vorher nach, und die
Option --read-only beschränkt einen Client aufs Lesen. Der Server ist in jedem
Tarif enthalten. Die MCP-Dokumentation beschreibt die manuelle
Einrichtung, die Datenschutzerklärung sagt, was wo gespeichert wird,
und wenn Sie sehen möchten, wie andere Notiz-Tools dieselbe Frage beantworten,
haben wir ihre MCP-Server
verglichen.
Ein lokaler Server ist ein Programm, das Ihr KI-Client auf Ihrem eigenen Rechner startet und mit dem er über die Standardein- und -ausgabe des Prozesses spricht — ganz ohne Netzwerk. Ein Cloud-Server ist ein Webdienst, den der Client über HTTPS erreicht und per OAuth autorisiert. Die MCP-Spezifikation nennt das die Transporte stdio und Streamable HTTP.
Nein. Ein lokaler Server hält Ihre Daten von den Servern des Anbieters fern, aber alles, was der Assistent darüber liest, geht als Teil des Gesprächs an Ihren Modellanbieter — genau so, als hätten Sie es selbst eingefügt. Lokal steuert Speicherung und Zugriff, nicht das, was das Modell sieht.
Er ist privater, aber nicht automatisch sicherer. Die MCP-Autorisierungsspezifikation gilt nur für HTTP-Transporte; stdio-Servern wird stattdessen nahegelegt, Zugangsdaten aus der Umgebung zu beziehen, deshalb hat ein lokaler Server meist gar keine eigene Berechtigungsebene. Alles, was unter Ihrem Benutzerkonto läuft, erreicht ihn in der Regel.
An der Einrichtungsanleitung. Eine https://-URL und eine Anmeldung im Browser bedeuten die Cloud des Anbieters. Ein Befehl wie npx, uvx oder docker bedeutet einen Prozess auf Ihrem Rechner. Ein lokaler Prozess mit API-Schlüssel ruft trotzdem die API des Anbieters auf, der Befehl allein sagt also nichts darüber, wo die Daten liegen.
Claude Desktop startet lokale Server direkt, installiert als Desktop-Erweiterung. ChatGPT verbindet sich im Entwicklermodus mit entfernten HTTPS-Endpunkten, ein lokaler stdio-Server muss also erst über einen Tunnel erreichbar gemacht werden. Derselbe Server kann daher im einen Client lokal und im anderen entfernt sein.