Verlauf und Benachrichtigungen für MCP-Server

Was wir alle 3 Stunden lesen

Alle 3 Stunden läuft eine Prüfung. Bei jedem gelisteten Server liest sie, was sie ohne Anmeldung und ohne etwas auszuführen lesen kann:

Remote-Server, die ihre Tools ohne Anmeldung auflisten: Wir führen den MCP-Handshake und tools/list aus, wie ein Client, und halten die Tools, die instructions des Servers und die gemeldete Version fest.
Server, deren Tools in einem MCP-Bundle beschrieben sind: Wir lesen das manifest.json in ihrem GitHub-Repository erneut, beim neuesten Commit.
Lokale Server, die auf npm oder PyPI veröffentlicht sind: Wir sehen nach der neuesten Version. Lokale Server führen wir nie aus.
Der eigene MCP-Server von mcp.tc.

Server, die eine Anmeldung oder einen API-Schlüssel verlangen, bevor sie ihre Tools auflisten, und lokale Server ohne Bundle-Manifest haben keine Tool-Liste, die wir beobachten können. Ihr Verlauf hält die Version fest, wenn wir sie lesen können, und Änderungen des Server-Betreibers. Derzeit können wir die Tools von 159 Einträgen lesen.

Oben im Verlauf jedes Eintrags steht, welcher dieser Fälle für ihn gilt und wann wir seine Tools zuletzt abgerufen haben. Jeder Remote-Server bekommt außerdem einmal am Tag eine Statusprüfung.

Was als Änderung zählt

Bei einem Server, dessen Tools wir lesen, hält der Verlauf fest:

hinzugefügte oder entfernte Tools (ein umbenanntes Tool erscheint als ein entferntes und ein hinzugefügtes);
bei einem Tool, das bleibt: eine neue Beschreibung oder ein neuer Titel, hinzugefügte, entfernte oder neu erforderliche Parameter, neue Parameterbeschreibungen, ein neues Ein- oder Ausgabeschema und geänderte Hinweise wie readOnlyHint oder destructiveHint;
unsichtbare Zeichen in der Beschreibung oder den Parametern eines Tools, etwa Zeichen mit Nullbreite oder Steuerzeichen für die Textrichtung, die Text vor Menschen verbergen können, während ein Modell ihn trotzdem liest;
neue instructions des Servers, also der Text, den der Server jedem Client beim Verbinden mitgibt.

Außerdem hält er neue Versionen fest, wie der Server sie meldet oder wie sein npm- oder PyPI-Paket sie veröffentlicht, und die Änderungen, die der Server-Betreiber am Eintrag speichert, mit dem Text vorher und nachher (bei den Hinweisen zur Einrichtung nur, dass sie sich geändert haben). Änderungen von uns oder aus öffentlichen Quellen wie der MCP-Registry erscheinen dort nicht, ebenso wenig ein Eintrag, der ausgeblendet oder wieder aufgenommen wird. Wird ein Eintrag gelöscht, löschen wir seinen Verlauf mit, und niemand folgt ihm mehr. Die Reihenfolge der Tools, Status und Prüfzeiten zählen nicht als Änderungen.

Zwei Abrufe vor einer Änderung

Eine Änderung wird nur festgehalten, wenn zwei Abrufe übereinstimmen. Weicht ein Abruf vom zuletzt festgehaltenen ab, rufen wir den Server mindestens eine Minute später erneut ab, meist im selben Durchlauf, und halten die Änderung nur fest, wenn der zweite Abruf dasselbe zeigt. Ein Abruf, der fehlschlägt, abbricht oder nur einen Teil der Liste liefert, zählt als „keine Daten“, nie als entfernte Tools. Eine Tool-Liste, die leer wird, braucht zwei Abrufe im Abstand von mindestens zwei Stunden.

Der erste Abruf eines Eintrags ist sein Ausgangspunkt. Der Verlauf markiert ihn als Beginn der Beobachtung, mit der Zahl der Tools, und nichts davor zählt als Änderung.

Ist eine Änderung bestätigt, zeigt der Eintrag sofort die neue Tool-Liste. Ein neues Tool erscheint mit dem Titel, den der Server ihm gibt, oder mit dem ersten Satz seiner Beschreibung.

Versionen laufen genauso: Eine Version, die der Server meldet, halten wir fest, sobald zwei Abrufe übereinstimmen, die neueste Version eines npm- oder PyPI-Pakets sofort. Es zählen nur Versionsnummern wie 1.3.0 oder v2.0.0-beta.1. Ein Eintrag bekommt höchstens eine Versionsänderung in 24 Stunden, und eine Version, die zu einer in der letzten Woche festgehaltenen zurückkehrt, halten wir nicht noch einmal fest. Außerdem bekommt er höchstens drei Tool-Änderungen in 24 Stunden: Eine vierte wartet, bis die erste davon 24 Stunden alt ist. Datumsangaben im Text eines Tools, etwa das heutige Datum, lassen wir beim Vergleich außen vor.

Den Verlauf lesen

Jeder Eintrag hat neben Überblick, Einbindung und FAQ einen Tab Verlauf; sieh dir zum Beispiel den von DeepWiki an. Die Änderungen stehen mit der neuesten zuerst, jeweils mit Datum und Uhrzeit in UTC, ihrer Herkunft und einer einzeiligen Zusammenfassung:

Automatische Prüfung: unsere eigenen Abrufe des Servers.
Server-Betreiber: eine Änderung durch jemanden, der nachgewiesen hat, dass er den Server betreibt. Wer das ist, zeigen wir nie.

Öffne eine Änderung für die Details: hinzugefügte und entfernte Tools, jede geänderte Beschreibung vorher und nachher, geänderte Parameter, umgeschaltete Hinweise und die Server-Anweisungen vorher und nachher. Badges markieren Änderungen, die einen genaueren Blick lohnen, etwa ein Tool, das nicht mehr als nur lesend markiert ist oder neu als destruktiv, ein neues Tool, das als destruktiv markiert ist, ein neu erforderlicher Parameter, unsichtbare Zeichen oder neue Server-Anweisungen. Hinweise sind Markierungen, die ein Server seinen eigenen Tools gibt: Sie sagen, was der Server über ein Tool angibt. Text, den wir von einem Server zitieren, stammt vom Server selbst und wird als reiner Text angezeigt.

Der Tab zeigt alle Änderungen, die neueste zuerst, 100 pro Seite; die neuesten 10 mit allen Details, ältere mit ihrer Zusammenfassung und den Namen der Tools. Jede hat eine eigene Adresse, den Link ihrer Seite gefolgt von #ch- und einer Nummer, sodass du darauf verlinken kannst. Der Verlauf bleibt erhalten, solange der Eintrag existiert. Wir können eine Änderung ausblenden, wenn sich ein Abruf als falsch herausstellt, oder auf Anfrage. Ausgeblendete Änderungen werden weder angezeigt noch per E-Mail verschickt.

Feeds und die Seite Letzte Änderungen

Um Änderungen im Blick zu behalten, brauchst du kein Konto:

Letzte Änderungen listet die 50 neuesten Änderungen im ganzen Verzeichnis.
/changes.xml liefert dieselbe Liste als Atom-Feed.
Auch der Verlauf jedes Eintrags ist ein Atom-Feed mit seinen 30 neuesten Änderungen, unter seinem Link mit angehängtem /history.xml, zum Beispiel mcp.tc/i/deepwiki/history.xml.

Programme können dieselben Daten lesen: Das JSON des Eintrags hat ein Objekt history, das Markdown des Eintrags enthält seine fünf letzten Änderungen, und get_server auf dem MCP-Server von mcp.tc liefert sie ebenfalls. API und Daten hat die Details.

Einem Eintrag folgen

Melde dich an, mit GitHub oder einem Code per E-Mail, und klicke oben in einem Eintrag auf Folgen. Das ist kostenlos, und du kannst bis zu 200 Einträgen folgen. Deine Seite Gefolgt listet sie mit ihren letzten Änderungen und einem Button „Nicht mehr folgen“, und dort legst du fest, wie du E-Mails bekommst:

sobald sich etwas ändert, höchstens eine E-Mail pro Stunde (Standard);
eine tägliche Zusammenfassung;
keine E-Mails.

Eine E-Mail deckt alle Einträge ab, denen du folgst und die sich seit der letzten E-Mail geändert haben. Sie nennt jeden Eintrag und fasst zusammen, was sich geändert hat (zum Beispiel „2 Tools hinzugefügt, 1 entfernt“). Eine E-Mail zu einem Eintrag verlinkt diese Änderung in seinem Verlauf (oder deine Seite Gefolgt, wenn der Eintrag nicht mehr im Verzeichnis ist); eine E-Mail zu mehreren verlinkt deine Seite Gefolgt, die ihre letzten Änderungen listet. Sie zitiert nie die Beschreibung eines Tools, denn das ist Text des Servers. Du bekommst nur Änderungen, die festgehalten wurden, nachdem du angefangen hast zu folgen, und keine, die älter als 7 Tage sind. Eine neue Version allein schicken wir nur, wenn ihre Nummer steigt, etwa von 1.2.0 auf 1.3.0: nicht bei einem neuen Build-Zusatz zur selben Nummer und nicht bei einem Schritt zurück auf eine frühere Version. Änderungen, die sich vor der E-Mail aufheben, etwa eine Version, die sich ändert und dann wieder zurückgeht, schicken wir nicht.

Jede E-Mail hat einen Link zum Abbestellen, der ohne Anmeldung funktioniert. In einer E-Mail zu einem Eintrag kannst du auf seiner Seite dem Eintrag nicht mehr folgen oder die E-Mails zu Änderungen abschalten; in einer E-Mail zu mehreren schaltet er die E-Mails zu Änderungen ab. Der Link öffnet eine Seite mit Buttons, sodass ein Mailfilter, der Links öffnet, nichts ändern kann, und auf der Seite kannst du rückgängig machen, was du gerade getan hast. Auch der Abmelde-Button deiner Mail-App öffnet eine dieser Seiten: Ein Klick dort schaltet die E-Mails zu Änderungen ab, und du folgst deinen Einträgen weiter. Wenn du dein Konto löschst, löschen wir auch die Liste der Einträge, denen du folgst. Die Datenschutzerklärung sagt, was wir speichern und was der E-Mail-Dienst erhält.

Was dir der Verlauf nicht sagen kann

Der Verlauf zeigt, was die anonymen Abrufe von mcp.tc bei jeder Prüfung gesehen haben. Er ist keine Sicherheitsprüfung und blockiert, genehmigt oder garantiert nichts.

Er sieht keine Tools, die ein Server erst nach der Anmeldung oder nur manchen Clients zeigt. Ein Server kann unserer Prüfung eine Liste zeigen und deinem Client eine andere.
Eine Änderung, die zwischen zwei Prüfungen gemacht und wieder rückgängig gemacht wird, kann uns entgehen.
Lokale Server laufen hier nie, also prüfen wir nicht, was ein Paket nach dem Start tut.
Wenn ein Server nicht erreichbar ist oder einen Abruf abbricht, hält diese Prüfung nichts fest.

Bevor du die Tools eines Servers in deinem Client freigibst, und nach einem Update noch einmal, lies die Tool-Liste, die dein Client zeigt: Diese Liste bekommt dein Modell. Der Verlauf sagt dir, wann sich ein neuer Blick lohnt.

Für Server-Betreiber

Änderungen, die du an deinem Eintrag speicherst, erscheinen in seinem Verlauf als Änderungen durch den Server-Betreiber, ohne deinen Namen oder dein Konto, und gehen per E-Mail an alle, die dem Eintrag folgen. Dasselbe gilt für Tool-Änderungen, die unsere Prüfung findet: Veröffentliche eine neue Tool-Liste, und der Eintrag zeigt sie meist innerhalb von 3 Stunden, sobald zwei Abrufe übereinstimmen.

Wir können deine Tools nur beobachten, wenn tools/list ohne Anmeldung antwortet oder dein Repository ein MCP-Bundle-Manifest hat, das sie auflistet. Versieh deine Tools mit readOnlyHint und destructiveHint, damit der Verlauf zeigen kann, wann sich diese Hinweise ändern. Für Server-Betreiber erklärt den Rest.