Se connecterCompte

Historique et alertes

Toutes les 3 heures, mcp.tc lit les listes d’outils qu’il peut voir sans se connecter, et chaque fiche garde un Historique public de ce qui a changé. Suivez une fiche pour recevoir un e-mail quand elle change.

Ce que nous lisons toutes les 3 heures

Une vérification a lieu toutes les 3 heures. Pour chaque serveur référencé, elle lit ce qu’elle peut sans se connecter et sans rien exécuter :

  • Serveurs distants qui listent leurs outils sans connexion : nous faisons le handshake MCP et tools/list, comme un client, et enregistrons les outils, les instructions du serveur et la version qu’il annonce.
  • Serveurs dont les outils sont décrits dans un bundle MCP : nous relisons le manifest.json de leur dépôt GitHub, au dernier commit.
  • Serveurs locaux publiés sur npm ou PyPI : nous consultons la dernière version. Nous n’exécutons jamais les serveurs locaux.
  • Le serveur MCP de mcp.tc.

Les serveurs qui demandent une connexion ou une clé API avant de lister leurs outils, et les serveurs locaux sans manifeste de bundle, n’ont pas de liste d’outils que nous puissions observer. Leur Historique enregistre la version quand nous pouvons la lire, et les modifications du propriétaire du serveur. Aujourd’hui, nous pouvons lire les outils de 159 fiches.

En haut de l’Historique de chaque fiche, vous voyez lequel de ces cas la concerne et quand nous avons lu ses outils pour la dernière fois. Chaque serveur distant reçoit aussi une vérification d’état une fois par jour.

Ce qui compte comme un changement

Pour un serveur dont nous lisons les outils, l’Historique enregistre :

  • les outils ajoutés ou retirés (un outil renommé apparaît comme un outil retiré et un outil ajouté) ;
  • pour un outil qui reste : une nouvelle description ou un nouveau titre, des paramètres ajoutés, retirés ou devenus obligatoires, de nouvelles descriptions de paramètres, un nouveau schéma d’entrée ou de sortie, et des indications qui ont changé, comme readOnlyHint ou destructiveHint ;
  • des caractères invisibles dans la description ou les paramètres d’un outil, comme des caractères de largeur nulle ou de direction du texte, qui peuvent cacher du texte aux personnes alors qu’un modèle le lit quand même ;
  • de nouvelles instructions du serveur, le texte qu’il donne à chaque client à la connexion.

Il enregistre aussi les nouvelles versions, telles que le serveur les annonce ou que son paquet npm ou PyPI les publie, et les modifications que le propriétaire du serveur enregistre sur la fiche, avec le texte avant et après (pour les notes de configuration, seulement le fait qu’elles ont changé). Les modifications faites par nous ou venues de sources publiques comme le registre MCP n’y apparaissent pas, pas plus qu’une fiche masquée ou publiée à nouveau. Quand une fiche est supprimée, son Historique et ses suivis disparaissent avec elle. L’ordre des outils, l’état et les heures de vérification ne comptent pas comme des changements.

Deux lectures avant un changement

Un changement n’est enregistré que lorsque deux lectures concordent. Quand une lecture diffère de la dernière enregistrée, nous relisons le serveur au moins une minute plus tard, en général lors du même passage, et n’enregistrons le changement que si la seconde lecture montre la même chose. Une lecture qui échoue, s’interrompt ou ne renvoie qu’une partie de la liste compte comme une absence de données, jamais comme des outils retirés. Une liste d’outils qui devient vide demande deux lectures à au moins deux heures d’intervalle.

La première lecture d’une fiche est son point de départ. L’Historique la marque comme le début de l’observation, avec le nombre d’outils, et rien d’antérieur ne compte comme un changement.

Une fois un changement confirmé, la fiche affiche aussitôt la nouvelle liste d’outils. Un nouvel outil apparaît avec le titre que lui donne le serveur ou la première phrase de sa description.

Les versions suivent la même règle : une version annoncée par le serveur est enregistrée quand deux lectures concordent, et la dernière version d’un paquet npm ou PyPI aussitôt. Seuls les numéros de version comptent, comme 1.3.0 ou v2.0.0-beta.1. Une fiche reçoit au plus un changement de version par période de 24 heures, et une version qui revient à une version enregistrée la semaine passée n’est pas enregistrée à nouveau. Elle reçoit aussi au plus trois changements d’outils par période de 24 heures : un quatrième attend que le premier ait 24 heures. Les dates dans le texte d’un outil, comme la date du jour, sont laissées de côté dans la comparaison.

Lire l’onglet Historique

Chaque fiche a un onglet Historique à côté d’Aperçu, Intégration et FAQ ; voyez par exemple celui de DeepWiki. Les entrées vont de la plus récente à la plus ancienne, chacune avec la date et l’heure en UTC, l’origine du changement et un résumé d’une ligne :

  • Vérification automatique : nos propres lectures du serveur.
  • Propriétaire du serveur : une modification faite par quelqu’un qui a prouvé qu’il exploite le serveur. Nous n’indiquons jamais qui.

Ouvrez une entrée pour le détail : les outils ajoutés et retirés, chaque description modifiée avant et après, les paramètres modifiés, les indications inversées et les instructions du serveur avant et après. Des badges signalent les changements qui méritent un examen attentif, par exemple un outil qui a perdu son indication de lecture seule ou reçu une indication destructive, un nouvel outil marqué comme destructif, un paramètre devenu obligatoire, des caractères invisibles ou de nouvelles instructions du serveur. Les indications sont des étiquettes que le serveur donne à ses propres outils : elles disent ce que le serveur affirme qu’un outil fait. Le texte cité d’un serveur vient du serveur lui-même et s’affiche en texte brut.

L’onglet montre toutes les entrées, de la plus récente à la plus ancienne, 100 par page, avec tous les détails pour les 10 plus récentes ; les plus anciennes montrent leur résumé et le nom des outils. Chaque entrée a sa propre adresse, le lien de sa page suivi de #ch- et d’un numéro, pour que vous puissiez y renvoyer. L’Historique reste aussi longtemps que la fiche existe. Nous pouvons masquer une entrée quand une lecture s’avère fausse, ou sur demande. Les entrées masquées ne sont ni affichées ni envoyées par e-mail.

Les flux et la page Modifications récentes

Pas besoin de compte pour garder un œil sur les changements :

Les programmes peuvent lire les mêmes données : le JSON de la fiche contient un objet history, le Markdown de la fiche inclut ses cinq changements les plus récents, et get_server sur le serveur MCP de mcp.tc les renvoie aussi. API et données donne les détails.

Suivre une fiche

Connectez-vous avec GitHub ou un code reçu par e-mail, puis appuyez sur Suivre en haut d’une fiche. C’est gratuit, et vous pouvez suivre jusqu’à 200 fiches. Votre page Suivis les liste avec leurs changements récents et un bouton pour ne plus les suivre, et c’est là que vous choisissez comment recevoir les e-mails :

  • au fil des changements, au plus un e-mail par heure (par défaut) ;
  • un résumé quotidien ;
  • aucun e-mail.

Un seul e-mail couvre toutes les fiches suivies qui ont changé depuis le précédent. Il nomme chaque fiche et résume ce qui a changé (par exemple « 2 outils ajoutés, 1 retiré »). Un e-mail sur une seule fiche renvoie à ce changement dans son Historique (ou à votre page Suivis quand la fiche a quitté l’annuaire) ; un e-mail sur plusieurs fiches renvoie à votre page Suivis, qui liste leurs changements récents. Il ne cite jamais la description d’un outil, qui est le texte du serveur. Seuls les changements enregistrés après le début de votre suivi vous sont envoyés, et aucun de plus de 7 jours. Une nouvelle version seule n’est envoyée que si son numéro augmente, par exemple de 1.2.0 à 1.3.0 : pas pour une nouvelle étiquette de build sur le même numéro, ni pour un retour à une version antérieure. Les changements qui s’annulent avant l’e-mail, comme une version qui change puis revient en arrière, ne sont pas envoyés.

Chaque e-mail contient un lien d’arrêt qui fonctionne sans connexion. Dans un e-mail sur une seule fiche, sa page permet d’arrêter son suivi ou de couper les e-mails de changement ; dans un e-mail sur plusieurs fiches, il coupe les e-mails de changement. Le lien ouvre une page avec des boutons, donc un filtre de messagerie qui ouvre les liens ne peut rien changer, et la page permet d’annuler ce que vous venez de faire. Le bouton de désabonnement de votre application de messagerie ouvre aussi l’une de ces pages : un clic y coupe les e-mails de changement et garde vos suivis. Supprimer votre compte supprime vos suivis. La politique de confidentialité indique ce que nous conservons et ce que reçoit le service d’envoi des e-mails.

Ce que l’Historique ne peut pas vous dire

L’Historique montre ce que les lectures anonymes de mcp.tc ont vu à chaque vérification. Ce n’est pas un audit de sécurité, et il ne bloque, n’approuve ni ne garantit rien.

  • Il ne voit pas les outils qu’un serveur ne montre qu’après connexion, ou seulement à certains clients. Un serveur peut répondre à notre vérification avec une liste et à votre client avec une autre.
  • Un changement fait puis annulé entre deux vérifications peut passer inaperçu.
  • Les serveurs locaux ne sont jamais exécutés ici, donc ce que fait un paquet une fois lancé n’est pas vérifié.
  • Quand un serveur est hors service ou interrompt une lecture, cette vérification n’enregistre rien.

Avant d’approuver les outils d’un serveur dans votre client, et de nouveau après une mise à jour, lisez la liste d’outils que votre client affiche : c’est elle que reçoit votre modèle. L’Historique vous dit quand il vaut la peine de regarder à nouveau.

Pour les propriétaires de serveurs

Les modifications que vous enregistrez sur votre fiche apparaissent dans son Historique comme des changements du propriétaire du serveur, sans votre nom ni votre compte, et sont envoyées par e-mail aux personnes qui suivent la fiche. Il en va de même des changements d’outils que trouve notre vérification : publiez une nouvelle liste d’outils et la fiche l’affiche en général dans les 3 heures, une fois que deux lectures concordent.

Nous ne pouvons observer vos outils que si tools/list répond sans connexion, ou si votre dépôt contient un manifeste de bundle MCP qui les liste. Annotez vos outils avec readOnlyHint et destructiveHint, pour que l’Historique puisse montrer quand ces indications changent. Pour les propriétaires de serveurs couvre le reste.