MCP-Server für Claude, Cursor und VS Code: Was zuerst verbunden werden sollte
Ein praktischer MCP-Leitfaden: wie sich ein Server von einer Erweiterung oder einem API-Schlüssel unterscheidet, welche Verbindungen sich zuerst lohnen und wie man einem Agenten nicht zu viel Zugriff gewährt.
MCP löst ein wenig glamouröses, aber wichtiges Problem: Es gibt einer KI-Anwendung eine einheitliche Möglichkeit, externe Tools und Daten zu entdecken. Statt für GitHub, Dateien, eine Datenbank oder Slack jeweils einen eigenen Adapter zu bauen, führt ein Host einen MCP-Client aus, der mit einem kompatiblen Server spricht. Die offizielle MCP-Architektur trennt Host, Client und Server; ein Server kann Tools, Ressourcen und Prompts bereitstellen. Diese Grenze ist wichtiger als das Versprechen, „alles zu verbinden“, denn dort werden Zugriff und Verantwortung definiert.
Ein Protokoll, drei Rollen und getrennte Verbindungen
Der Host ist Claude, Cursor, ein Editor oder eine andere Anwendung, in der der Nutzer arbeitet. Der Host erstellt für jeden konfigurierten Server einen Client. Jeder Server stellt eine bestimmte Fähigkeit bereit: ein erlaubtes Verzeichnis lesen, GitHub abfragen, sichere Datenbankabfragen ausführen oder einen Browser steuern. Das ist kein allmächtiger Tunnel. Mehrere eng begrenzte Server lassen sich leichter deaktivieren, prüfen und mit getrennten Zugangsdaten ausstatten.
Die MCP-Dokumentation verwendet für eine lokale Verbindung häufig stdio: Der Host startet einen Prozess und tauscht Nachrichten über Standardeingabe und Standardausgabe aus. Ein Remote-Server verwendet Streamable HTTP. Die Wahl verändert Bereitstellung und Vertrauen. Ein lokaler Prozess erbt den Zugriff auf dem aktuellen Rechner; ein Remote-Dienst empfängt Daten über das Netzwerk und braucht eine eigene Authentifizierung.
Dateisystem und GitHub schaffen die erste nützliche Grenze
Verbinden Sie den am wenigsten spektakulären Server, der häufige Reibung mit einem klaren Schadensradius beseitigt. Dateisystemzugriff hilft, wenn der Host ein benötigtes Verzeichnis nicht lesen kann oder wenn das Wurzelverzeichnis eng begrenzt werden muss. GitHub ergänzt Issues, Pull Requests, Checks und Repositorys. Für die Entwicklung liefert dieses Paar den Aufgabenkontext und den Ort, an dem die Arbeit dokumentiert wird.
Beginnen Sie mit Lesezugriff. Wenn ein Server Branches erstellen, Issues schließen oder Pull Requests mergen kann, aktivieren Sie diese Aktionen separat. Ein Token für eine ganze Organisation ist in einer Demo bequem und im Alltag riskant. Bevorzugen Sie eine dedizierte Identität, minimale Scopes und ein Sandbox-Repository für den ersten Test.
Datenbanken, Slack und Drive brauchen ein strengeres Vertrauensmodell
Ein Postgres-Server kann ein Schema inspizieren, Abfragen diagnostizieren und Daten analysieren. Der Nur-Lese-Nutzer muss jedoch durch die Datenbank erzwungen werden, nicht nur in einem System-Prompt versprochen sein. Fügen Sie Statement-Timeouts hinzu, blockieren Sie sensible Schemas und führen Sie für Produktionszugriffe eine Audit-Spur. Slack und Google Drive können Unterhaltungen oder Dokumente offenlegen, die der Nutzer nie in die Aufgabe einbringen wollte; beschränken Sie daher Workspaces, Kanäle und Ordner.
MCP-Ressourcen sind für Kontext nützlich; Tools sind für Aktionen da. Wenn sich eine Aufgabe mit einer Nur-Lese-Ressource lösen lässt, stellen Sie kein Schreib-Tool bereit. Das ist besonders wichtig bei Abrechnung, CRM, Remote-Shells und Infrastruktur.
Browser MCP und PhonePi bedienen Oberflächen, keine Massen-APIs
Browser MCP lässt einen Agenten über eine Webseite arbeiten, während PhonePi MCP einen verwandten Ansatz auf ein Android-Gerät ausweitet. Sie sind nützlich für Interface-Tests, das Nachstellen einer Customer Journey und Systeme ohne passende API. UI-Automatisierung ist dennoch langsamer und fragiler als eine direkte API, weil sich Selektoren, Sitzungen, Dialoge und Berechtigungen ändern.
Nutzen Sie eine Browser- oder Telefon-Brücke, wenn die Oberfläche selbst wichtig ist. Für Massensynchronisierung, Abrechnung und kritische Schreibvorgänge ist eine offizielle API mit Idempotenz und Operationsprotokollen vorzuziehen.
Ein Server ist keine Erweiterung, kein API-Schlüssel und keine fertige Integration
Eine Erweiterung ergänzt eine Anwendung um UI oder Verhalten. Ein API-Schlüssel weist nach, wer einen Dienst aufruft. Eine Integration beschreibt einen fertigen Geschäftsablauf. Ein MCP-Server ist ein programmatischer Vertrag, über den ein Host Fähigkeiten entdeckt und aufruft. Der Server kann weiterhin einen API-Schlüssel, OAuth oder lokale Autorisierung benötigen. Das Protokoll erfindet weder Berechtigungen, noch garantiert es die Qualität der Implementierung.
Prüfen Sie Herausgeber, Repository, Abhängigkeiten, Update-Pfad und deklarierte Tools. Ein Server, der aus irgendeinem README installiert wird, führt Code mit lokalen Rechten aus. Pinnen Sie seine Version und prüfen Sie die Konfiguration, bevor Sie Secrets einführen.
Eine kleine Auswahl schlägt einen Katalog mit zwanzig Servern
Eine sinnvolle Reihenfolge für Entwickler lautet: lokale Dateien innerhalb eines erlaubten Wurzelverzeichnisses, ein GitHub-Repository, dann ein Browser zur Validierung. Fügen Sie Datenbanken, Chats und Cloud-Dokumente nur für einen konkreten, wiederkehrenden Workflow hinzu. Entfernen Sie Verbindungen, die nach einer Woche keinen Wert liefern.
Bevor Sie Schreibzugriffe aktivieren, beantworten Sie fünf Fragen: Welche Daten kann der Server sehen, welche Aktionen kann er ausführen, wo werden Secrets gespeichert, wer bestätigt irreversible Aktionen und wo befindet sich die Audit-Spur? MCP senkt die Integrationskosten, beseitigt aber nicht das Bedrohungsmodell. Eine gute Konfiguration macht einen Agenten gerade deshalb nützlicher, weil sie nicht alles auf einmal gewährt.