Wählen Sie den Transport bewusst
Ein lokaler stdio-Server und ein entfernter HTTP-Dienst haben unterschiedliche Bereitstellungsanforderungen. Verwenden Sie einen unterstützten entfernten Transport, TLS und eine authentifizierte Route. Prüfen Sie die Client- und Serverversionen, statt anzunehmen, dass jede Implementierung dieselben Fähigkeiten unterstützt.
Behandeln Sie jedes Werkzeug als API
Validieren Sie Argumente, erzwingen Sie benutzerspezifische Autorisierung und begrenzen Sie Ressourcen. Stellen Sie keine beliebige Shell-Ausführung als Komfortwerkzeug bereit. Beschränken Sie ausgehende Ziele, wenn ein Werkzeug URLs abruft, und halten Sie Geheimnisse aus Beschreibungen und Antworten heraus.
Halten Sie die Identitätserfassung verhältnismäßig
Ein Host ohne KYC kann die Anmeldedaten beim Anbieter minimieren, doch der MCP-Dienst benötigt möglicherweise weiterhin eigene Benutzer, Sitzungssicherheit und Missbrauchskontrollen. Legen Sie dar, was protokolliert wird, und vermeiden Sie die Aufbewahrung von Tool-Eingaben ohne definierten Zweck.
Für betriebliche Klarheit bereitstellen
Betreiben Sie den Dienst unter einem dedizierten Benutzer, verwenden Sie Health Checks, begrenzen Sie Anforderungszeiten und halten Sie Pufferung und Timeouts des Reverse-Proxys mit dem Protokoll kompatibel. Testen Sie Authentifizierung, Widerruf, Verbindungsabbrüche und Wiederholungen, bevor Sie Schreibrechte erteilen.
Authentifizierung an das unterstützte Protokoll anpassen
Für eine HTTP-basierte MCP-Bereitstellung prüfen Sie die aktuellen Autorisierungsanforderungen des Protokolls und die vom Client unterstützte Version. OAuth-basierter Ressourcenzugriff umfasst Token-Audience, Discovery und Scope, nicht einfach nur ein Passwort auf der Startseite. Verwenden Sie HTTPS, validieren Sie Tokens für die vorgesehene Ressource und halten Sie Bearer-Anmeldedaten aus Query-Strings heraus. Ein stdio-Server verwendet eine andere lokale Anmeldedaten-Grenze.
- Eine nicht authentifizierte Anfrage testen
- Eine authentifizierte Anfrage außerhalb ihres Geltungsbereichs testen
- Widerrufen Sie eine Anmeldedaten und prüfen Sie, dass sie nicht mehr funktioniert
Offizielle Dokumentation: MCP Autorisierungsspezifikation
Ein begrenztes erstes Toolset veröffentlichen
Beginnen Sie mit schreibgeschützten Tools, die eine begrenzte Datenmenge zurückgeben. Fügen Sie Dateischreibvorgänge, Server-Lebenszyklusoperationen oder externe Nachrichten erst hinzu, wenn deren Berechtigungen und Duplikatverhalten verstanden sind. Behandeln Sie zurückgegebene Webseiten und Dokumente als nicht vertrauenswürdige Eingaben; sie dürfen die Befugnisse des Tool-Servers nicht stillschweigend erweitern.
Protokollverhalten vor dem Schreiben von Proxy-Regeln festlegen
Notieren Sie sowohl die Server-SDK-Version als auch die MCP-Revision, die der Client verwenden wird. In der 2026-07-28 Streamable-HTTP-Revision verwenden Anfragen einen POST-Endpunkt; ältere Beispiele, die auf Protokollsitzungen oder einem eigenständigen GET-Stream beruhen, sind eine andere Revision. Entfernen Sie eine scheinbare Kompatibilitätsanforderung erst, wenn Sie wissen, welchen Client Sie unterstützen. Ein Reverse-Proxy muss die erforderlichen Header, den HTTP-Status und das Antwort-Streaming-Verhalten für diese Version erhalten.
- Beginnen Sie mit einem schreibgeschützten Tool auf einem Loopback-Listener und platzieren Sie dann die vorgesehene HTTPS-/Authentifizierungsgrenze davor.
- Testen Sie ein normales Ergebnis, ein Streaming-Ergebnis, einen Timeout und einen getrennten Client über den öffentlichen Proxy.
- Validieren Sie zulässige Origin-Werte wie vom Transport gefordert; eine Origin-Prüfung ersetzt nicht die Authentifizierung des Aufrufers.
- Wenn Ereignisse erst am Ende eintreffen, prüfen Sie Proxy-Pufferung und Timeout-Verhalten, bevor Sie den Tool-Code ändern.
Offizielle Dokumentation: MCP 2026-07-28: Streamable HTTP
Testen Sie Autorisierungsfehler ebenso gezielt wie Erfolgsfälle
Für OAuth-geschützten HTTP-Zugriff ist der MCP-Server eine geschützte Ressource. Testen Sie die Metadaten-Erkennung, den erwarteten Aussteller und die Token-Zielgruppe sowie die für einen bestimmten Vorgang erforderlichen Scopes. Halten Sie das Autorisierungstoken aus URL-Query-Strings heraus und leiten Sie es niemals unverändert an einen nicht zugehörigen nachgelagerten Dienst weiter. Ein clientseitiger Authentifizierungsfehler muss die passende HTTP-Challenge bewahren, damit der Client sich über seinen unterstützten Ablauf erholen kann.
- Kein Token oder ein abgelaufenes Token: Der geschützte Endpunkt verweigert den Zugriff, statt private Tool-Daten zurückzugeben.
- Gültiges Token mit unzureichender Berechtigung: Die angeforderte Ressource bleibt unzugänglich.
- Token für eine andere Zielgruppe: Ablehnen, auch wenn die Signatur ansonsten gültig ist.
- Unerwarteter externer URL oder Dateipfad: Validieren Sie ihn anhand der Autorität des Werkzeugs, bevor Sie abrufen oder schreiben.
- Protokolle und Fehlerablaufverfolgungen: Behalten Sie eine Vorgangskennung und das Ergebnis bei und entfernen Sie Token und private Tool-Eingaben.
Offizielle Dokumentation: MCP 2026-07-28: HTTP-Autorisierung · MCP: bewährte Sicherheitspraktiken