MCPagger Hub

Le catalogue des actions de toutes les applications déployées : workers, actions, paramètres, avec un bouton pour les essayer.

Voir l'élément dans l'écran : hub/mcpagger

Explication

Chaque application TheSocle est faite de workers, et chaque worker expose des actions (lire, créer, purger…). MCPagger les rassemble en un seul catalogue, application par application.

À gauche, la liste des applications. Un point vert : leur description a été lue. Un point gris : l'application n'a pas répondu. Le badge donne la source de la description, et le nombre en regard le nombre d'actions.

À droite, l'application choisie : ses workers, et pour chacun ses actions avec leur mode (SYNC, ASYNC), le repère READ-ONLY des actions sans effet, leurs paramètres, et un bouton Tester.

C'est l'écran de l'intégrateur : Thomas Robin y vérifie le nom exact d'une action et de ses paramètres avant d'écrire son appel MCP.

Fiche complète

Ce que l'écran appelle

À l'ouverture, GET /hub/mcpagger → mcpagger_aggregator_worker.list_all_specs : la liste des applications connues (appId, available, source, toolCount), le total et le nombre de disponibles. Le contrôleur fabrique aussi un jeton d'accès à votre nom, pour Tester.

Au clic sur une application : GET /hub/mcpagger/apps/<appId>/spec.json → mcpagger_aggregator_worker.get_app_spec (app_id).

D'où viennent les descriptions

Toutes les 5 minutes, le worker (mode POLLING, 300 000 ms) :

1. relève les applications à l'état running dans apps.applications ;
2. demande à chacune GET http://<appId>:<port>/mcpagger/spec.json ;
3. à défaut, appelle son POST /mcp en tools/list et en déduit une description ;
4. décrit le Hub lui-même d'après son registre local d'actions.

Les descriptions sont gardées dans le KvBus du Hub.

Par MCP

Les mêmes données : mcpagger_aggregator_worker__list_all_specs, __get_app_spec, __get_aggregated_spec, __refresh_specs.