Einige Server auf HostedMCP tragen ein Verified-Markierung. Auf dieser Seite erklären wir genau, was diese Markierung misst, damit du selbst entscheiden kannst, wie viel Gewicht du ihr beimessen möchtest.
Verified bedeutet, dass ein Server unsere automatisierten Checks (Version 2) in Bezug auf sein öffentliches Repository, seine Packages, Dependencies, Tool-Beschreibungen und Endpoints bestanden hat. Das bedeutet nicht, dass eine Person den Code manuell geprüft hat, und wir führen den Server niemals in deinem Namen aus. Verstehe es als „keine offensichtlichen Probleme in den öffentlichen Daten gefunden“ und nicht als Sicherheitsgarantie.
Die Checks
Wir führen elf Checks durch, einmal pro Woche und immer dann, wenn sich das README oder die Packages eines Listings ändern. Jedes Ergebnis speichert seine Belege und einen Link zur öffentlichen Quelle, damit du es selbst überprüfen kannst.
| Gruppe | Check | Gewichtung | Quelle | Grund für ein Scheitern |
|---|---|---|---|---|
| Origin | Source repository | 10 | GitHub | ein Package ohne verknüpftes Repository oder eines, das wir nicht erreichen können |
| Origin | Package names the same repository | 5 | npm, PyPI | die eigenen Metadaten des Packages verweisen auf ein anderes Repository |
| Origin | Build provenance | 10 | Sigstore attestations auf npm und PyPI | zählt nur, wenn eine Attestation existiert; das Fehlen einer Attestation gilt nicht als Fehler |
| Origin | License | 5 | GitHub, SPDX | keine Lizenz vorhanden oder eine, die nicht OSI-approved ist |
| Practices | Maintenance | 5 | GitHub | kein Commit und kein Release in den letzten 365 Tagen |
| Practices | OpenSSF Scorecard | 15 | OpenSSF | ein Wert unter 7 von 10 führt zu einem Teil der Gewichtung, proportional zum Score |
| Supply chain | Package name | 10 | unsere Liste populärer Packages | ein Name, der nur ein oder zwei Buchstaben von einem populären Package unter einem anderen Owner entfernt ist |
| Supply chain | Advisories | 15 | deps.dev, OSV | ein kritisches Advisory im Package oder in einer aufgelösten Dependency dieser Version |
| Tool safety | Hidden instructions | 15 | tool descriptions, README | Text, der auf das Model abzielt ("ignore previous instructions", <IMPORTANT> Blöcke), unsichtbare Unicode-Zeichen oder eine Tool description, die auf Dateien wie ~/.ssh verweist |
| Tool safety | Destructive tools | 5 | tool annotations | ein Tool mit einem Namen wie delete_*, drop_* oder exec* ohne die destructiveHint Annotation |
| Endpoint | MCP handshake | 5 | ein Live-Request von uns | ein Remote Endpoint über plain HTTP oder einer, der nicht auf initialize antwortet |
So wird der Score berechnet
Ein Check zählt nur dann, wenn uns die entsprechenden Daten vorliegen. Ein hosted server hat kein Package, daher gelten die Checks für Package, Provenance und Advisory hier nicht; ein Repository, das nicht von Scorecard analysiert wurde, hat auch kein Scorecard-Ergebnis. Übersprungene Checks werden beim Gesamtwert nicht abgezogen, sodass ein Server niemals für etwas abgestraft wird, das wir nicht prüfen konnten.
Der Score ergibt sich aus dem Gewicht der bestandenen Checks im Verhältnis zum Gewicht der durchgeführten Checks. Um als Verified eingestuft zu werden, benötigt ein Server:
- einen Score von 80 oder mehr,
- keine serious findings (Package Name, plain HTTP, versteckte Anweisungen oder ein kritisches Advisory),
- mindestens 60 der 100 geprüften Punkte, damit ein Eintrag mit fast gar keinen Daten nicht automatisch bestehen kann,
- ein öffentliches Source Repository, das seinen Check bestanden hat.
Auf jeder Server-Seite wird jeder Check mit seinem Ergebnis, den entsprechenden Nachweisen (Evidence), dem Datum der Durchführung und – sofern Scorecard dies meldet – dem beschriebenen Commit aufgelistet. Wir speichern die letzten zehn Ergebnisse pro Server.
Was dir die Checks nicht sagen
Die Checks lesen öffentliche Daten und führen einen Handshake-Request an Remote-Endpoints aus. Sie führen keinen Code eines Servers aus und prüfen auch nicht dessen Logik. Ein Server kann jeden Check bestehen und trotzdem etwas tun, das du nicht möchtest. Zudem kann ein gut gebauter Server durchfallen, weil die Daten, die wir benötigen, nicht veröffentlicht sind. Ein offizieller Server vom Hersteller des Produkts ist in der Regel ein besseres Vertrauenssignal als dieses Markenzeichen.
Bevor du einen lokalen Server installierst, denke daran, dass dieser mit deinen Benutzerrechten läuft. Lies den Quellcode, bevorzuge Server, die vom Unternehmen des Produkts selbst veröffentlicht wurden, und gib jedem Server ein Token mit dem minimal notwendigen Zugriff.
Unser MCP Security Guide geht hierauf im Detail ein.
Etwas nicht in Ordnung?
Falls ein Check deinen Server fälschlicherweise markiert hat, beanspruche den Eintrag und sag uns Bescheid oder schreib eine E-Mail an legal@hostedmcp.org. Wenn du glaubst, dass ein Verified Server schädlich ist, schreibe an dieselbe Adresse und wir werden uns innerhalb von 72 Stunden darum kümmern.