MCP Read-only: Leserechte wirksam begrenzen und prüfen
Lesen soll möglich sein, Schreiben nicht. Diese Grenze braucht eine konkrete Einstellung und einen nachvollziehbaren Test.
Eine Read-only-Einrichtung beginnt an der Datenquelle. Benötigen Sie nur Informationen aus einem Projekt, wählen Sie eine Rolle mit genau diesem Zugriff. Dokumentieren Sie anschließend, welche Werkzeuge der MCP-Server anbietet und welche Freigaben Ihr Client verlangt. Der Berechtigungsplaner erstellt daraus eine Reihenfolge für die Prüfung. Dieser Leitfaden behandelt die Grenzen eines Lesezugangs; für den ersten Verbindungsaufbau nutzen Sie die jeweilige Einrichtungsanleitung.
Drei Bedeutungen von Read-only
| Begriff | Bedeutung | Zusätzlich prüfen |
|---|---|---|
| readOnlyHint | Werkzeug beschreibt sich als lesend | Vertrauen in die Quelle und tatsächliche Wirkung |
| Read-only-Modus | Server begrenzt angebotene Funktionen | Dokumentation und sichtbare Werkzeugliste |
| Leserolle | Quelle begrenzt das Konto | Projektumfang und vergebene Rechte |
Die MCP-Spezifikation behandelt Werkzeugannotationen als Hinweise. Ein Client darf aus einem Hinweis eines nicht vertrauenswürdigen Servers keine verlässliche Berechtigungsgrenze ableiten. Insbesondere entzieht readOnlyHint einem Token keine Rechte. Beschreiben Sie Ihr Ergebnis deshalb präzise: Ein Werkzeug meldet einen Hinweis, ein Server blendet Schreibfunktionen aus oder ein Konto darf nicht schreiben. Diese drei Beobachtungen können zusammengehören, sind aber nicht austauschbar.
Beispiel: GitHub auf Lesen begrenzen
Der GitHub MCP Server dokumentiert einen eigenen Read-only-Modus. Für den entfernten Zugang nennt die Konfigurationsdokumentation den Header X-MCP-Readonly oder einen Read-only-URL-Weg. Lokal sind --read-only und GITHUB_READ_ONLY vorgesehen. Übernehmen Sie die vollständige Form aus der aktuellen Herstelleranleitung für Ihren Startweg. Ergänzen Sie eine auf benötigte Repositories und Leserechte begrenzte Kontoberechtigung. Der Servermodus entfernt Schreibwerkzeuge, ersetzt aber nicht diese Einstellung am Konto. Die GitHub-Einrichtung führt durch den Zugang.
Eine kleine Probe mit klaren Grenzen
Legen Sie einen Testdatensatz an und halten Sie seinen Ausgangszustand außerhalb des zu prüfenden Lesezugangs fest.
Prüfen Sie in der Quelle Rolle, Projektumfang und Ablaufdatum des Zugangs. Aktivieren Sie zusätzlich den dokumentierten Servermodus.
Verbinden Sie den Client neu und lesen Sie die Werkzeugliste. Vergleichen Sie die verfügbaren Funktionen mit dem vorgesehenen Auftrag.
Lesen Sie den bekannten Datensatz. Prüfen Sie die Antwort gegen das Original und kontrollieren Sie, dass dessen Inhalt unverändert blieb.
Falls ein Negativtest nötig ist, führen Sie ihn ausschließlich im autorisierten isolierten Testziel aus. Prüfen Sie danach dessen Zustand unabhängig von der Fehlermeldung.
Ein abgelehnter Schreibversuch belegt nur die geprüfte Kombination aus Konto, Ziel und Operation. Er ist kein Nachweis für jede andere Funktion. Halten Sie diese Grenzen im Protokoll fest. Fehlt ein Werkzeug, prüfen Sie zuerst Servermodus und Rollen, bevor Sie weitere Rechte vergeben. Der Fehler-Navigator hilft dabei, eine fehlende Funktion von einem Verbindungsfehler zu unterscheiden.
Was Lesezugriff weiterhin erlaubt
Ein Lesezugang kann umfangreiche oder vertrauliche Daten abrufen. Begrenzen Sie deshalb auch den sichtbaren Bestand, etwa auf ein Testprojekt statt auf das gesamte Konto. Prüfen Sie, wo Antworten gespeichert und an welche weiteren Werkzeuge sie übergeben werden. Ein gelesener Text kann fremde Anweisungen enthalten; dafür gelten die Prüfungen aus der Berechtigungsanleitung. Nach einer Änderung an Rolle, Serverversion oder Werkzeugauswahl wiederholen Sie die betroffenen Proben. Notieren Sie Datum und Ergebnis, damit eine frühere Beobachtung später nicht als aktueller Nachweis gelesen wird.
- Ist readOnlyHint eine Zugriffssperre?
- Nein. Es ist ein Hinweis des Werkzeugs. Die tatsächliche Grenze muss durch die Quelle oder die Laufzeitumgebung durchgesetzt werden.
- Gibt es einen universellen Read-only-Schalter für alle Server?
- Nein. Prüfen Sie die Dokumentation des konkreten Servers und begrenzen Sie zusätzlich das Konto.
- Darf ich den Negativtest in Produktion ausführen?
- Verwenden Sie dafür ein isoliertes, ausdrücklich autorisiertes Testziel. Ein unerwartet erfolgreicher Aufruf darf keine produktiven Daten verändern.
- Kann ein Lesezugang Daten offenlegen?
- Ja. Lesen kann vertrauliche Inhalte liefern. Umfang, Weitergabe und Speicherung müssen deshalb ebenfalls begrenzt werden.
- MCP tools and annotations
Abrufbefehl anzeigen
curl -s https://modelcontextprotocol.io/specification/2025-11-25/server/tools - GitHub MCP server configuration
Abrufbefehl anzeigen
curl -s https://github.com/github/github-mcp-server/blob/main/docs/server-configuration.md - MCP security best practices
Abrufbefehl anzeigen
curl -s https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices