Was deklariert ein MCP-Server wirklich? 31.439 Registereinträge gelesen

Drei Vertrauensgrade und zwei Arten, nichts zu wissen

Jeder Wert auf einer Eintragsseite nennt seine Herkunft in einer Zeile darunter, zum Beispiel „Quelle: MCP-Register · erhoben am 2026-08-06 · abgeleitet". Das letzte Wort ist der Vertrauensgrad, und es gibt drei davon. Selbstauskunft heißt: So steht es im Manifest des Anbieters, unverändert übernommen. Abgeleitet heißt: tracevero hat aus einer oder mehreren Rohangaben nach einer veröffentlichten Regel einen Wert gebildet, und die Rohangaben stehen als „Originalangabe" direkt daneben. Von Hand geprüft steht nur an Werten, die der Betreiber über eine protokollierte Korrektur gesetzt hat. Der Beispieleintrag weiter unten führt keine solche Korrektur.

Daneben gibt es zwei Zustände, die leicht verwechselt werden. Nachweislich nicht vorhanden heißt: Das Manifest enthält das Feld, und es ist leer. Nicht erhoben heißt: Die Quelle liefert das Feld gar nicht. Das Register hält beides auseinander und zeigt ein fehlendes Feld nie als „nein". Aus einer leeren Liste der geheimen Pflichtvariablen leitet es dagegen sehr wohl „nein" ab, mit demselben Vertrauensgrad wie aus einer gefüllten: Die Angabe ist ja da.

Die entscheidende Station in Abbildung 1 ist die dritte. Die Regel ist veröffentlicht, sie trägt eine Fassung (derzeit 2), und sie greift ohne Ermessen. Wer die Rohangabe und die Regel kennt, rechnet jeden abgeleiteten Wert nach. Die Methodik legt alle Regeln mit ihrem Wortlaut offen. Das ist die eine Zusage des Registers, und sie ist bewusst schmal: Es bewertet nicht, es empfiehlt nicht, und es erfindet keinen Wert, den die Quelle nicht hergibt.

Was der Bestand deklariert

Vier der abgeleiteten Merkmale haben genau einen Wert je Eintrag. Für sie lässt sich der ganze Bestand in einer Zahl je Wert zusammenfassen, und jedes Wertepaar ergibt zusammen wieder 31.439. Die Bestandszahlen zählen diese Verteilung bei jedem Aufruf neu; Abbildung 2 zeigt den Stand vom 12.09.2026.

Die größte Gruppe ist die unauffälligste: 24.294 Einträge (77,3 %) führen eine Repository-Adresse. Die Regel sagt ausdrücklich, was daraus nicht folgt: Ob unter der Adresse etwas liegt, ist damit nicht gesagt, denn das Register ruft sie nie ab. 17.789 Einträge (56,6 %) führen ausschließlich Remote-Adressen oder HTTP-Transporte und gelten nach der Regel als „entfernt". Für die übrigen 13.650 (43,4 %) sagt dieselbe Regel „lokal".

Aufschlussreicher sind die beiden kleinen Gruppen. 4.905 Einträge (15,6 %) deklarieren mindestens eine Umgebungsvariable oder eine Kopfzeile eines Remote-Endpunkts, die zugleich als geheim und als erforderlich markiert ist. Die übrigen 26.534 tun das nicht. Daraus folgt nicht, dass 84,4 % aller Server ohne Zugangsdaten auskommen, sondern nur, dass ihr Manifest keine als Pflicht erklärt. Ein Server, der seinen API-Schlüssel in der Beschreibung erwähnt, aber nicht im Schema, zählt hier zu „nein". Deshalb heißt die Kurzform auf der Eintragsseite „Keine Zugangsdaten angegeben" und nicht „keine erforderlich".

Die kleinste Gruppe: 317 Einträge (1,0 %) erklären ein Paket- oder Laufzeitargument oder eine Umgebungsvariable mit dem Format filepath. Wer einem Server einen Ordner mitgeben muss, erfährt das aus dem Manifest also nur selten über dieses Format. Ob ein Server trotzdem einen Pfad erwartet, steht, wenn überhaupt, in seiner eigenen Dokumentation.

Zwei Merkmale gekreuzt: Wo stehen die Geheimnisse?

Zwei Merkmale mit je einem Wert lassen sich gegeneinander stellen, auf der Seite über die Kreuztabelle und an der Schnittstelle über /v1/matrix. Die Frage, die sich hier lohnt: Deklarieren entfernte Server häufiger ein Pflicht-Geheimnis als lokale?

Die Zahlen laufen der Vermutung entgegen. Von den 13.650 lokalen Einträgen deklarieren 3.285 ein Pflicht-Geheimnis (24,1 %), von den 17.789 entfernten nur 1.620 (9,1 %). 67,0 % aller Einträge mit deklariertem Pflicht-Geheimnis sind lokal. Warum das so ist, misst das Register nicht, und dieser Beitrag rät es nicht. Wer der Frage nachgehen will, öffnet eine Zelle: Jede Zelle der Kreuztabelle führt in die gefilterte Liste, und dort steht bei jedem Eintrag die Originalangabe, aus der sein Wert entstanden ist.

Einen Eintrag in fünf Schritten lesen

Als Beispiel dient der Eintrag com.pulsemcp/remote-filesystem, ein Server für Dateien in Google Cloud Storage, abgerufen am 13.09.2026. Er trägt keinen eigenen Anzeigenamen, ist klein genug, um ihn ganz zu lesen, und zeigt jeden der Fälle aus der Tabelle oben.

1. Die Rohangaben zuerst. Der Eintrag führt ein Paket (npm:remote-filesystem-mcp-server, Version 0.1.5) mit dem Transport stdio, 8 Umgebungsvariablen und die Repository-Adresse https://github.com/pulsemcp/mcp-servers, alle als Selbstauskunft, erhoben am 06.08.2026. Das ist die Grundlage; alles Weitere wird daraus gebildet.

2. Dann die abgeleiteten Werte, jeweils mit ihrer Regel. Ausführungsort „lokal": Die Regel sagt „entfernt" nur, wenn ausschließlich Remote-Adressen oder HTTP-Transporte geführt sind, und stdio ist keines von beiden. Pflicht-Geheimnisse deklariert „nein", und hier lohnt der zweite Blick: Das Manifest markiert GCS_PRIVATE_KEY als geheim, aber nicht als erforderlich, und GCS_BUCKET als erforderlich, aber nicht als geheim. Die Regel verlangt beide Markierungen an derselben Variable, also bleibt die Liste der geheimen Pflichtvariablen leer. Das ist keine Aussage über den Server, sondern genau das, was sein Manifest erklärt. Pfadargument vorhanden „nein": GOOGLE_APPLICATION_CREDENTIALS ist laut ihrer Beschreibung ein Pfad zu einer Schlüsseldatei, trägt aber nicht das Format filepath.

3. Das Datum lesen, nicht nur den Wert. „Erhoben am" nennt den Tag, an dem der geltende Wert aufgezeichnet wurde. Liefert die Quelle am nächsten Tag denselben Wert, entsteht keine neue Zeile. Beim Beispiel sind es vier Tage: 06.08.2026 für die Kernangaben, 16.08.2026 für später eingeführte Rohangaben, 26.08.2026 für die Beschreibung und 08.09.2026 für die Verbindungswege.

4. Die leeren Felder als Auskunft nehmen. Geheime Pflichtvariablen, geheime Pflichtkopfzeilen, Remote-Adressen, Pfadargumente und die Formate der Umgebungsvariablen stehen als „nachweislich nicht vorhanden" da. Daraus folgt nur, was die Regel folgert. Welche Zugangsdaten der Server beim Start wirklich braucht, steht, wenn überhaupt, in seiner Dokumentation und nicht in diesem Register.

5. Zuletzt den Registerstatus als das lesen, was er ist. „Registerstatus: aktiv" gibt wieder, was das Quellregister führt, und ist keine Messung des Betriebs. Für seine Einträge ruft tracevero keinen Server auf. Wer wissen will, ob der Server antwortet, startet ihn; die Clientseiten zeigen, wie die Konfigurationsdatei dafür aufgebaut ist und wo sie liegt.

Abbildung 4 zeigt, warum das Datum an jedem Wert steht und nicht einmal am Eintrag. Die Quelle meldet die Eintragung am 26.06.2026; tracevero hat den Server am 06.08.2026 zum ersten Mal gesehen und danach an drei weiteren Tagen neue Rohangaben aufgezeichnet. Der letzte Lauf vor diesem Beitrag hat den Eintrag am 12.09.2026 wieder gesehen (Feld zuletzt_geprueft der Schnittstelle), ohne dass sich einer der Kernwerte geändert hätte. Wer nur ein einziges Datum nennt, sagt deshalb weniger, als er zu sagen glaubt.

Was das Register nicht sagt

Die Grenze der Messung gehört zur Messung. Vier Dinge stehen bewusst auf keiner Eintragsseite, und wer sie hineinliest, liest falsch:

• Kein Abruf der Adressen aus einem Eintrag. Weder die Repository-Adresse noch ein Remote-Endpunkt noch ein Paketindex wird geöffnet. „Repository-Adresse geführt" sagt, dass eine Adresse im Manifest steht, sonst nichts.
• Keine Note, keine Rangfolge nach Beliebtheit. Die Liste ordnet nach „Zuletzt geändert", nach Name, nach „Neu im Register" oder nach der Zahl belegter Merkmale. Eine Ordnung nach Beliebtheit gibt es nicht, weil das Register keine Abrufe der Pakete zählt.
• Keine Verträglichkeitszusage. Ob ein Server mit einem bestimmten Client zusammenarbeitet, erklärt kein Manifest. Die Clientseiten beschreiben die Form der Konfigurationsdatei, nicht die Eignung eines Servers.
• Das Einsatzgebiet ist gerechnet, nicht gemeldet. Es entsteht aus Begriffen in der Anbieterbeschreibung, gesucht an Wortgrenzen. Das Gebiet Zahlung greift bei payment, payments, invoice, invoices, invoicing, checkout, stripe, paypal, payouts, subscriptions. Ein Server, dessen Beschreibung von „invoices" spricht, steht dort auch dann, wenn er Rechnungen nur ausliest. Die Themenseiten nennen die Suchmuster jedes Gebiets.

Abbildung 5 zeigt die zwölf größten der 33 Gebiete. Dass Kryptowährung mit 1.021 Einträgen vorn liegt, sagt etwas über die Beschreibungstexte im Quellregister und nichts über die Qualität der Server. Genauso zu lesen ist die deklarierte Version: Der Bestand kennt 1.634 verschiedene Werte, und 8.675 Einträge (27,6 %) nennen „1.0.0". Eine Version im Manifest ist eine Angabe und keine Prüfung des Pakets.

Wer über eine einzelne Eintragsseite hinaus prüfen will, findet unter Werkzeuge die Kreuztabelle, die Lücken je Merkmal und die Sammelabfrage, die eine ganze Konfigurationsdatei Zeile für Zeile nachschlägt. Alle drei zählen; eine Note vergibt keines von ihnen.

Häufige Fragen

Heißt „Keine Zugangsdaten angegeben", dass der Server ohne Schlüssel läuft?

Nein. Es heißt, dass das Manifest keine Umgebungsvariable und keine Kopfzeile als geheim und erforderlich erklärt. Ob der Server einen Schlüssel braucht, steht in seiner Dokumentation. Das Register misst die Erklärung, nicht den Bedarf.

Warum zeigt ein Eintrag mehrere Erhebungsdaten?

Weil jede Rohangabe den Tag trägt, an dem ihr geltender Wert aufgezeichnet wurde, und das Register seine Felder nicht alle am selben Tag eingeführt hat. Ein einziges Datum je Eintrag ließe ältere Werte jünger aussehen, als sie sind.

Kann ich die abgeleiteten Werte selbst nachrechnen?

Ja. Die Regeln stehen mit Fassung 2 und Wortlaut unter https://api.tracevero.com/v1/regeln, die Rohangaben stehen bei jedem Eintrag. Wer beides nimmt, kommt auf denselben Wert; dafür sind die Regeln veröffentlicht.

Was bedeutet „Registerstatus: aktiv"?

Den Wert, den das Quellregister für den Eintrag führt. Er sagt nicht, ob der Server heute antwortet. tracevero misst keinen Betrieb, und deshalb heißt das Feld Registerstatus und nicht Status.

Wie aktuell sind die Zahlen in diesem Beitrag?

Sie gelten für den Datenstand vom 12.09.2026 und wurden am 13.09.2026 abgerufen. Der Bestand ändert sich täglich; die Befehle im Quellenblock ziehen die Zahlen neu, und die Bestandszahlen zeigen sie laufend.

Quellen und Befehle

Alle Zahlen dieses Beitrags stammen aus tracevero selbst, Datenstand 12.09.2026, abgerufen am 13.09.2026. Jede Zeile nennt den Befehl, der sie neu zieht.

1. Bestand, Verteilung der einwertigen Merkmale, Einsatzgebiete und Versionen
   curl -s https://api.tracevero.com/v1/kennzahlen
2. Ausführungsort gegen deklarierte Pflicht-Geheimnisse, vier Zellen mit Rändern
   curl -s "https://api.tracevero.com/v1/matrix?art=mcp_server&a=ausfuehrungsort&b=zugangsdaten_erforderlich"
3. Die veröffentlichten Ableitungsregeln mit ihrer Fassung
   curl -s https://api.tracevero.com/v1/regeln
4. Der Beispieleintrag mit Quelle, Erhebungsdatum und Vertrauensgrad je Wert
   curl -s https://api.tracevero.com/v1/eintrag/mcp_server/com-pulsemcp-remote-filesystem
5. Die Suchmuster des Einsatzgebiets Zahlung
   curl -s https://tracevero.de/themen/einsatz-zahlung

Alle Beiträge