Everything MCP : pour les auteurs de clients, exercer les fonctions de protocole avec npx

Pour qui

Ceux qui implémentent ou déboguent un client MCP et ont besoin d’un serveur de test capable de parcourir les fonctions de protocole. Il est explicitement « not intended to be a useful server » et ne sert qu’à exercise les fonctions du protocole MCP. Convient à qui peut lancer @modelcontextprotocol/server-everything avec npx et accepter que les retours soient des données de démo plutôt que des résultats métier. Ne convient pas comme outil de production de collecte, dépôt ou recherche. Page officielle : https://github.com/modelcontextprotocol/servers/tree/main/src/everything

Premier essai en 3 minutes

Un seul chemin officiel : stdio par défaut.

Prérequis : npx est présent. C’est un banc d’essai pour constructeurs de clients, pas pour un usage métier final.

Lieu d’installation et de configuration : dans le client MCP, écrire la commande de démarrage ainsi :

npx @modelcontextprotocol/server-everything

Le fragment de configuration équivalent est command: npx, arguments -y et @modelcontextprotocol/server-everything.

Action à bas risque : une fois connecté, faire lister au client les tools déclarés par ce serveur, puis appeler le premier tool de la liste. N’écrivez pas à la main un nom d’outil absent du document. Le serveur implémente aussi prompts, resources, sampling ; si le client liste prompts ou resources, vous pouvez plutôt prendre le premier prompt ou lire une resource. Ces appels vérifient qu’un aller-retour réel tool / prompt / resource est possible, pas qu’une tâche métier soit finie.

Signal de succès : le client liste au moins une classe (tools, prompts ou resources), et l’appel choisi renvoie du contenu. Une liste vide ou un processus qui quitte tout de suite compte comme inachevé. En cas d’échec, confirmez d’abord que la commande est le stdio par défaut, pas HTTP+SSE déprécié.

Cas d’usage

Cas 1 : vérifier tools. Correspond à « It implements prompts, tools, resources, sampling, and more ». Faire parcourir à un client de test list tools → call tool. Les retours peuvent être des espaces réservés ou des charges de démo ; ils ne servent qu’à juger l’analyse du client. Les preuves ne donnent aucun nom ni paramètre de tool ; le cas s’arrête à « un appel vers un tool réellement présent dans la liste ».

Cas 2 : vérifier prompts, resources ou sampling. Même phrase de capacité. Faire prendre un prompt ou lire une resource ; si le client implémente sampling, observer si le serveur déclenche un flux d’échantillonnage. Les preuves ne nomment que des classes de capacité, pas les noms de prompt, URI de resource ou formats de messages sampling. Les parties manquantes suivent les objets listés à l’exécution ; n’inventez pas d’URI.

Limites d’usage

C’est un serveur de test, pas un serveur métier utile. Ne l’utilisez pas pour des données clients réelles et n’attendez pas de sémantique métier stable.

HTTP+SSE Transport a été déprécié le 2025-03-26. npm install et npm run start:sse sous le répertoire source ne sont pas le chemin du premier essai.

La recommandation officielle est npx stdio par défaut. Même si un appel de tool paraît en lecture seule, l’implémentation de test peut encore envoyer des notifications, demander un échantillonnage ou écrire des resources de démo ; ne le traitez pas comme zéro effet de bord. Il n’y a ni liste de clients ni URL hébergée.