Zwei Verbindungswege, zwei Risikomodelle
Bei einem lokalen Server startet der Host einen Prozess und spricht typischerweise über stdio. Konfiguration, Umgebungsvariablen und Prozessrechte liegen auf demselben Rechner. Bei einem entfernten Server verbindet sich der Client über eine öffentliche URL; die offizielle Registry-Dokumentation nennt dafür Streamable HTTP und behandelt ältere HTTP-plus-SSE-Pfade als veraltet.
Absoluter Startbefehl, Arbeitsverzeichnis, erlaubte Umgebungsvariablen, Dateirechte und Netzwerkzugriff müssen vor dem Start bekannt sein.
HTTPS-Origin, Redirects, Tokenziel, Scopes, Mandant, Timeouts und Egress-Regeln gehören in den Vertrag.
Eine Toolliste ist Inventar, keine Freigabe. Wirkung, Kosten, Datenquelle und maximale Ergebnismenge werden je Tool festgelegt.
Ein Konfigurationsbeispiel belegt weder erfolgreichen Auth-Flow noch korrekte Ergebnisse oder sichere Fehlerpfade.
Quellen: MCP TypeScript SDK, „Connect to local and remote MCP servers“ und Model Context Protocol Registry, „Publishing remote servers“. Beobachtet am 22.08.2026.
Ein clientneutraler Vertrag verhindert Scheinkompatibilität
Die herunterladbare Vorlage ist bewusst kein Konfigurationssnippet für Claude Desktop, VS Code oder einen bestimmten Anbieter. Solche Syntax kann sich ändern und würde ohne echten Lauf schnell wie ein Kompatibilitätsclaim wirken. Die Vorlage hält stattdessen die Felder fest, die vor jeder clientspezifischen Umsetzung beantwortet sein müssen.
{
"target": {
"protocolVersion": "2026-07-28",
"transport": "stdio | streamable-http",
"endpointOrCommand": "SET_ME"
},
"authorization": {
"mode": "none | environment | oauth",
"secretStorage": "SET_ME",
"scopes": []
},
"proof": {
"clientVersion": "SET_ME",
"serverVersion": "SET_ME",
"testedAt": null,
"result": "not_tested"
}
}Keine echten Tokens, Passwörter oder personenbezogenen Daten gehören in diese Datei. Ein Remote-Ziel bleibt not_tested, bis Client-, Server-, Account-, Auth- und Protokollstand zusammen mit dem Ergebnis aufgezeichnet wurden.
Sieben Schritte vom Inventar zum belastbaren Befund
- 01
Ziel identifizieren
Publisher, Repository oder offizielles Produkt, Endpoint beziehungsweise Startbefehl, Version und Beobachtungstag festhalten. Keine URL aus einem Suchtreffer ungeprüft übernehmen.
- 02
Transport fixieren
Für lokal
stdio, für remote Streamable HTTP oder einen ausdrücklich begründeten Legacy-Pfad dokumentieren. Redirects dürfen weder Host noch Tokenziel unbemerkt wechseln. - 03
Identität und Auth binden
Secret-Ablage, OAuth-Resource, Scopes, Mandant und Ablaufverhalten bestimmen. Ein Token darf nicht an einen anderen Dienst weitergereicht werden.
- 04
Capabilities inventarisieren
Toolname, Eingabeschema, Datenquelle, Lese- oder Schreibwirkung, externe Ausführung, Kostenmodell und Rückgabegrenzen erfassen.
- 05
Kleinsten Read-only-Probeaufruf ausführen
Mit einem engen Scope starten, strukturierte Antwort, Quellen- und Frischefelder prüfen und keine Schreib- oder Publishing-Aktion in denselben Lauf mischen.
- 06
Negativpfade testen
Unbekannte Methode, ungültiges Schema, zu großes Limit, fehlender Scope und abgelaufenes Auth-Material müssen kontrolliert scheitern.
- 07
Beleg und Verfall speichern
Client, Server, Protokoll, Accountklasse, Zeitpunkt, Assertions, Fehler und Seiteneffekte festhalten. Ohne neuen Lauf wird der Befund nicht stillschweigend fortgeschrieben.
Was hier bereits belegt ist – und was offen bleibt
Fixture 001 reproduziert lokal 11 Assertions für den Initialize-/Session-Pfad 2025-11-25. Sie erzeugt keine Providerclaims.
Eine separate Fixture für den zustandslosen Kern und server/discover ist noch nicht implementiert.
Es gibt keinen öffentlich verifizierten Contextter-MCP-Endpunkt. Die gemeinsame Betreiberschaft ändert diese Beweisgrenze nicht.
Ein öffentlicher Remote-Validator bleibt ohne SSRF-, Abuse-, Kosten- und Logging-Vertrag ausgeschlossen.