Ein lokaler MCP-Server und ein entfernter sehen im Betrieb identisch aus: dieselbe Werkzeugliste im Client, dasselbe Gespräch, dasselbe Ergebnis. Der Unterschied liegt darin, was Sie dafür aus der Hand gegeben haben. Ein lokaler Server ist ein Programm auf Ihrem Rechner, das der Client startet und mit dem er über Standardeingabe und Standardausgabe spricht; aus der Hand geben Sie eine Befehlszeile. Ein Remote-Server ist der HTTPS-Endpunkt eines anderen, und aus der Hand geben Sie Zugangsdaten — samt allem, was sie aufschließen, solange Sie sie am Leben lassen.
Die nützliche Frage, bevor Sie eine URL in einen Connector-Dialog einfügen, lautet deshalb nicht „Ist dieser Server vertrauenswürdig“ — das kann niemand von einer Verzeichnisseite ablesen. Es sind drei engere Fragen, auf die es nachschlagbare Antworten gibt: worauf das Token in seinen Scopes begrenzt ist, wo Sie es zurücknehmen und was der Katalog, in dem Sie den Server gefunden haben, tatsächlich geprüft hat. Die Antworten unten beziehen sich auf die MCP-Spezifikation und die Herstellerdokumentation in ihrem Stand vom 16. August 2026.
Die aktuelle Fassung der Spezifikation, 2026-07-28, behandelt die beiden Transporte als unterschiedliche Sicherheitskontexte. Autorisierung ist in MCP optional, und wo sie gilt, ist ausdrücklich geregelt: Implementierungen mit einem HTTP-Transport sollen der OAuth-Spezifikation folgen, während stdio-Implementierungen ihr gar nicht folgen sollen und Zugangsdaten stattdessen aus der Umgebung beziehen. HTTP+SSE, der ältere Remote-Transport, gilt als veraltet; zu erwarten ist Streamable HTTP.
| Lokal (stdio) | Remote (Streamable HTTP) | |
|---|---|---|
| Was Sie aus der Hand geben | Einen Befehl, den Ihr Client ausführt | Eine URL und meist eine OAuth-Freigabe |
| Wo der Code läuft | Ihr Rechner, Ihr Benutzerkonto | Infrastruktur, die jemand anders betreibt |
| Zugangsdaten | Aus der Umgebung entnommen | Access Token, an genau diesen Server gebunden |
| Was „disconnect“ bewirkt | Es wird kein Prozess mehr gestartet | Löscht die Token-Kopie des Clients; die Freigabe kann bestehen bleiben |
| Schlimmster Fall bei bösartigem Autor | Beliebiger Code mit Ihren Rechten | Alles, was die genehmigten Scopes erreichen |
Keine der beiden Spalten ist die sichere. Ein lokaler Server ist beliebiger Code, der unter Ihrem Konto läuft — genau deshalb verlangt die Spezifikation, dass ein Client, der eine lokale Einrichtung per Klick anbietet, den exakten auszuführenden Befehl ungekürzt anzeigt und zuvor eine ausdrückliche Zustimmung einholt. Ein Remote-Server legt keinen Code auf Ihren Rechner, verschiebt aber Ihre Daten zu einem Betreiber und hinterlässt einen Zugangsweg, der Ihre Aufmerksamkeit überdauert. Die beiden versagen in verschiedene Richtungen; unser Vergleich, was die eine und die andere Art sehen kann, geht das genauer durch.
Das Autorisierungsmodell ist OAuth 2.1, und der als Nutzer lohnende Teil ist die
Bindung an ein Publikum. Clients müssen Resource Indicators for OAuth 2.0
(RFC 8707) umsetzen: Der Parameter resource muss sowohl in der Autorisierungs-
als auch in der Token-Anfrage mitgeschickt werden und benennt den konkreten
Server, für den das Token gilt. Server müssen prüfen, dass Token für sie
ausgestellt wurden, nur für ihre eigenen Ressourcen gültige Token annehmen und
dürfen keine anderen annehmen oder weiterleiten. Das Token eines Clients an eine
nachgelagerte API durchzureichen — „token passthrough“ — ist rundheraus
verboten.
Ein korrekt umgesetztes Token ist an einem anderen Server also nutzlos. Das schließt Replay, die Wiederverwendung von Zugangsdaten über Dienste hinweg und eine Klasse von Confused-Deputy-Angriffen aus — und über den Betreiber selbst gar nichts. Die Bindung an ein Publikum sagt, wo das Token wirkt, nicht, was das Unternehmen am anderen Ende mit dem macht, was seine Werkzeuge in Ihrem Auftrag abrufen. Darüber entscheidet dessen Datenschutzerklärung, nicht das Protokoll.
Entschieden wird Ihre Exposition aber bei den Scopes. Die Spezifikation drängt
Server zum geringstmöglichen Recht: scopes_supported soll die minimale Menge
für die Grundfunktion sein, alles Weitere wird schrittweise angefragt, wenn eine
privilegierte Operation zum ersten Mal versucht wird. Server, die sich daran
halten, verlangen vorab wenig; Server, die es nicht tun, zeigen einen einzigen
Zustimmungsdialog, der alles auflistet. Dieser Dialog ist der letzte Punkt, an
dem die Entscheidung bei Ihnen liegt.
Es gibt zwei Stellen für den Entzug, und die meisten nutzen nur die erste.
Im Assistenten. In Claude liegen eigene Connectors unter Customize > Connectors; dort fügen Sie einen hinzu, indem Sie die Server-URL einsetzen — Free-Nutzer sind auf einen begrenzt. Auf derselben Seite trennen Sie die Verbindung wieder und schalten die einzelnen Werkzeuge des Servers frei oder ab, statt sie alle zu übernehmen. Anthropic benennt die Vertrauenslage im Hilfebereich unumwunden: Eigene Connectors verbinden Claude mit beliebigen Diensten, die Anthropic nicht geprüft hat. In ChatGPT kommen Remote-Server über den Entwicklermodus — Settings → Security and login, im Web, mit SSE- und Streaming-HTTP-Endpunkten. Die Dokumentation von OpenAI nennt das mächtig, aber gefährlich, führt Prompt Injection und zerstörerische Schreibaktionen unter den Risiken auf und verlangt für Schreibaktionen standardmäßig eine Bestätigung.
Bei dem Dienst, bei dem Sie autorisiert haben. Diese Stelle überspringen die meisten. Den Connector zu löschen entfernt die Token-Kopie Ihres Clients; die in Ihrem Konto bei Google, GitHub, Atlassian oder Notion vermerkte Freigabe ist ein eigenes Objekt mit eigener Lebensdauer, und ein daran hängendes Refresh Token kann den Connector um Längen überdauern. Die Hinweise von Anthropic sagen genau das — entziehen, indem Sie den Connector in den Einstellungen von Claude oder in den Sicherheitseinstellungen des Drittdienstes trennen. Tun Sie beides, und suchen Sie die Seite mit den verbundenen Apps, bevor Sie verbinden.
Das offizielle MCP-Registry unter registry.modelcontextprotocol.io ist der
naheliegende Ort, um Server zu finden, und es ist leicht, einen Eintrag zu
überinterpretieren. Die Charta der Arbeitsgruppe ist da genau. Veröffentlichung
und Vertrauen umfassen Authentifizierungsabläufe — GitHub OAuth, GitHub OIDC,
DNS- und HTTP-Verifizierung — dazu die Inhaberschaft an Namensräumen, Werkzeuge
zur Moderation und Meldungen aus der Community. Ausdrücklich außerhalb des
Rahmens: MCP-Server-Implementierungen stellvertretend für Clients oder Endnutzer
zu bewerten oder auszuwählen, sowie Servercode zu hosten, zu verteilen oder
auszuführen, denn das Registry ist ein Metadaten-Katalog und kein
Paket-Registry.
Ein verifizierter Namensraum belegt also, dass die veröffentlichende Partei die GitHub-Organisation oder die Domain im Namen kontrolliert. Das ist ein echtes Signal: Es erschwert Typosquatting und gibt Ihnen jemanden, den Sie in die Pflicht nehmen können. Es ist keine Code-Prüfung, kein Sicherheitsaudit und keine Empfehlung — die Identität steht fest, das Verhalten weiter nicht.
Ein Grundsatz aus der Spezifikation lohnt sich bei jeder Verbindung: Beschreibungen des Werkzeugverhaltens, Annotationen eingeschlossen, gelten als nicht vertrauenswürdig, solange sie nicht von einem vertrauenswürdigen Server stammen, und Hosts müssen vor dem Aufruf eines Werkzeugs die ausdrückliche Zustimmung des Nutzers einholen. Eine Werkzeugbeschreibung ist Text, den eine entfernte Partei schreibt und Ihr Modell liest — die Definition einer nicht vertrauenswürdigen Eingabe und der Grund, warum „der Server hat gesagt, er sei read-only“ keine Sicherheitsmaßnahme ist.
Der konkrete Präzedenzfall ist CVE-2025-6514, veröffentlicht am 9. Juli 2025 zu
mcp-remote, dem Proxy, über den viele Clients Remote-Server erreichten. Mit
9,6 bewertet, erlaubte er einem bösartigen Server, auf dem verbindenden Rechner
Betriebssystembefehle einzuschleusen — über einen präparierten Wert von
authorization_endpoint im OAuth-Ablauf, betroffen waren die Versionen 0.0.5
bis 0.1.16, behoben in 0.1.16. Im Chat musste nichts bestätigt werden: Das
Verbinden war der ganze Angriff. Alles, was ein Remote-Server schickt, sind
Daten, die Ihre Software auswertet, und die Verbindung selbst gehört zu Ihrer
Angriffsfläche.
All das oben ist der Preis dafür, etwas zu erreichen, das tatsächlich in der Cloud eines anderen lebt — Ihr Ticketsystem, Ihr CRM, Ihr Kalender. Für die ist er angemessen und für Dateien, die ohnehin auf Ihrer Festplatte liegen, merkwürdig; deshalb liefert Speak-Y einen lokalen Server statt eines gehosteten Endpunkts.
Sein MCP-Server ist ein Prozess, den Ihr Client auf Ihrem Rechner startet. Zum
Lesen muss nichts weiter laufen: Suchergebnisse, Transkripte,
Besprechungszusammenfassungen und Action Items kommen direkt aus der Bibliothek
auf demselben Computer, ohne ausgestelltes Token und ohne Relais dazwischen.
Befehle, die etwas ändern — eine Aufnahme verschlagworten, Sprecher benennen, in
einen Team-Kanal teilen —, laufen über die geöffnete App, werden Ihrem Client
als datenverändernd gemeldet, sodass er vorher fragt, und werden dort
protokolliert, wo Sie sie auch abschalten können. Fügt man --read-only zu den
Argumenten des Servers hinzu, werden die ändernden Befehle diesem Client gar
nicht erst angeboten — eine stärkere Garantie als eine Beschreibung, die gutes
Verhalten verspricht. Die Installation ist ein Klick unter
Einstellungen → Integrationen, kostenlos in jedem Tarif einschließlich Free.
Der Tausch geht in beide Richtungen: Ein lokaler Server kann ChatGPT im Browser-Tab nicht bedienen, und er läuft nur dort, wo die App läuft. Wenn diese Einschränkung zählt, ist welche Clients einen lokalen Server überhaupt starten der nächste Vergleich — und wenn die Frage lautet, was ein Assistent nach dem Verbinden ändern darf, behandelt das wo die Grenze beim Schreibzugriff liegt. Die MCP-Übersicht listet, was der Server von Speak-Y bereitstellt.
Ein lokaler Server ist ein Programm auf Ihrem eigenen Rechner, das der Client startet und mit dem er über Standardeingabe und Standardausgabe spricht — aus der Hand geben Sie eine Befehlszeile, ein Token wird nicht ausgestellt. Ein Remote-Server ist ein HTTPS-Endpunkt, den jemand anders betreibt: Aus der Hand geben Sie Zugangsdaten, meist ein OAuth-2.1-Access-Token, und die Daten, die die Werkzeuge berühren, reisen zur Infrastruktur dieses Betreibers.
Nach der Autorisierungsspezifikation von MCP ist das Token an einen Server und eine Menge von Scopes gebunden. Clients müssen einen Resource Indicator nach RFC 8707 mitschicken, der den Server sowohl in der Autorisierungs- als auch in der Token-Anfrage benennt, und der Server muss prüfen, dass die Token für ihn ausgestellt wurden — er darf kein anderes Token annehmen oder weiterleiten. Damit lässt sich das Token bei einem anderen Dienst nicht erneut einsetzen. Über das, was der Betreiber mit den Daten macht, die seine Werkzeuge in Ihrem Auftrag abrufen, sagt es nichts.
An zwei Stellen, und die meisten erledigen nur die erste. Den Connector im Assistenten zu entfernen löscht die Token-Kopie des Clients; die OAuth-Freigabe, die bei dem Dienst vermerkt ist, bei dem Sie autorisiert haben, ist ein eigenes Objekt und überdauert das in der Regel. Anthropic empfiehlt, Berechtigungen zu entziehen, indem man den Connector in den Einstellungen von Claude oder in den Sicherheitseinstellungen des Drittdienstes trennt. Suchen Sie die Seite mit den verbundenen Apps beim Anbieter, bevor Sie verbinden, nicht danach.
Nein. Das Registry verifiziert die Inhaberschaft an Namensräumen — einen Namen unter io.github.* über die Authentifizierung bei GitHub, einen domainbasierten Namen über DNS- oder HTTP-Verifizierung —, was belegt, dass der Herausgeber diesen Namen kontrolliert. Seine Charta stellt das Bewerten oder Auswählen zwischen Server-Implementierungen ausdrücklich außerhalb des Rahmens und hält fest, dass das Registry ein Metadaten-Katalog ist und kein Paket-Registry: Es hostet, verteilt und führt keinen Servercode aus.
Nur so weit, wie die von Ihnen genehmigten Scopes reichen. Das Risiko ist, dass die Scopes weiter reichen als die Aufgabe: Ein Token für ein ganzes Postfach oder Laufwerk steht jedem Werkzeug dieses Servers zur Verfügung, solange die Freigabe lebt. Lesen Sie den Zustimmungsdialog statt der Marketingseite und nutzen Sie Regler je Werkzeug, wo der Client sie hat — in den Connector-Einstellungen von Claude lassen sich einzelne Werkzeuge ein- und ausschalten, und der Entwicklermodus von ChatGPT verlangt für Schreibaktionen standardmäßig eine Bestätigung.