Le socle · actions et MCP
Ce qu’un humain fait à l’écran,
un agent le fait par MCP.
Dans nos applications, chaque action est décrite une seule fois. Elle devient un point d’API pour les programmes et un outil pour les agents IA. Rien n’est développé deux fois, et aucune application n’a besoin d’un connecteur spécial pour être pilotée par un agent.
À quoi ça sert
MCP (Model Context Protocol) est le protocole ouvert qui permet à un agent IA — un assistant conversationnel, un agent de code, un automate — de découvrir les outils d’une application et de les appeler. Un agent qui parle MCP n’a pas besoin qu’on lui écrive un connecteur : il demande la liste des outils, lit leur description et leurs paramètres, et s’en sert.
Dans le socle, MCP n’est pas un ajout. C’est l’une des deux portes de chaque action, avec REST. Toutes nos applications se pilotent donc aussi bien par un humain que par un agent — et c’est le même code qui répond.
Comment ça marche, côté application
Le Worker décrit ses actions
Pour chaque action : un nom, une description en clair, des paramètres typés (texte, nombre, booléen, objet, liste), le mode synchrone ou asynchrone, et deux drapeaux utiles à un agent — « ne fait que lire » et « demande une confirmation ».
Le framework les découvre
Au démarrage, un registre recense toutes les actions de tous les Workers. Les paramètres sont traduits en schéma JSON, la langue que comprennent les agents.
L’agent se présente
Il ouvre la conversation MCP sur POST /mcp, sur le port de l’application, en JSON-RPC 2.0. Il s’authentifie par une clé ou par un jeton.
L’agent demande la liste
tools/list lui rend chaque action sous le nom worker__action, avec sa description et son schéma. Par exemple h2_database__query.
L’agent appelle
tools/call exécute l’action. Le résultat revient dans une enveloppe fixe : succès, données, erreur, durée.
Tout est consigné
Chaque appel est écrit dans la base technique de l’application, paramètres sensibles masqués. On sait qui a fait quoi, et quand.
Le framework sert MCP de deux façons : en HTTP, sur le port de l’application, pour un agent distant ; et en stdio, pour un agent lancé sur la même machine, un client à la fois. La même action reste joignable en REST : une liste des actions, un appel par action, et un mode asynchrone qui répond aussitôt « accepté » avec un identifiant de tâche à suivre.
Ce que voit un agent
Un agent ne travaille bien que s’il comprend ce qu’il appelle. C’est pourquoi chaque description compte :
- le nom dit le Worker et l’action :
docker_worker__get_logs,salon_worker__salon_post; - la description dit, en une phrase, ce que fait l’action et ce qu’elle rend ;
- les paramètres sont typés et documentés, avec leurs valeurs par défaut ;
- le drapeau lecture seule permet à un agent prudent de n’appeler que des actions sans effet ;
- le drapeau confirmation signale une action qui mérite qu’un humain dise oui.
Pour les humains, MCPagger — « le Swagger de Socle » — affiche les mêmes outils sur une page de l’application, avec un bouton pour les essayer, et produit leurs descriptions OpenAPI et MCP.
Le Hub, un seul point MCP pour toute la flotte
Une application isolée se pilote par sa propre porte MCP. Mais un agent qui travaille sur plusieurs applications ne veut pas en connaître vingt adresses. Le Hub règle cela.
Un proxy MCP qui agrège
Le Hub interroge régulièrement les applications qu’il fait tourner et republie leurs outils sous la forme application__outil, rafraîchis toutes les cinq minutes. Un agent branché sur le Hub voit donc d’un coup les outils du Hub lui-même — plusieurs centaines — et ceux de chaque application installée.
Un explorateur commun, sur le portail du Hub, montre l’ensemble des spécifications.
Des droits, outil par outil
Un agent entre sur le Hub avec une clé de plateforme ou avec un jeton émis par l’annuaire du Hub (OIDC). Le jeton doit porter la portée d’invocation MCP ; une matrice de portées décide ensuite ce qu’il peut faire : administrer un domaine, seulement lire (et alors seules les actions en lecture seule lui sont ouvertes), déployer, envoyer du courrier, piloter une application précise.
La même règle filtre la liste : chacun ne voit que ce qu’il a le droit d’appeler.
L’identité de la personne suit l’appel
Quand un agent agit pour le compte de quelqu’un, il le fait avec un jeton délégué. L’application appelée sait alors quelle personne est derrière l’agent, et pour quel client (tenant) elle agit.
Des exemples réels
Gérer la flotte
Un agent liste les applications, lit leurs journaux, relance un conteneur, publie une nouvelle version, vérifie un certificat — par les outils du Hub.
Tenir des tâches
L’application Things se pilote entièrement par MCP : un agent y dépose, met à jour et coche des tâches comme un humain.
Lire un tableau blanc
TheDash rend chaque carte d’un tableau lisible et modifiable en texte structuré : un agent travaille sur un tableau comme un membre de l’équipe.
Interroger une base
DataApp ouvre les bases de données à un agent, requête par requête, avec les droits qu’on lui donne.
Se parler entre agents
Les salons du Hub sont des fils d’échange persistants entre sessions MCP : un agent poste, un autre lit, attend une réponse, joint un fichier.
Habiter une cité
Machinapolis pousse l’idée au bout : une cité dont les habitants sont des agents IA.
Et pour les applications tierces qui ne parlent pas MCP, des adaptateurs leur en donnent la porte : MCP Sidecar →
Ce que cela apporte
Aucun connecteur à écrire
Une action écrite pour l’écran est déjà un outil pour l’agent. Le coût d’ouverture à l’IA est nul.
Des agents tenus en laisse
Portées, lecture seule, confirmation, jeton délégué, journal d’audit : un agent fait ce qu’on lui permet, et tout se relit.
Un seul point d’entrée
Le Hub rassemble les outils de toute la flotte derrière une seule adresse et un seul jeu de droits.
Faut-il un modèle d’IA particulier ?
Non. MCP est un protocole ouvert : tout client qui le parle peut appeler nos applications.
Un agent peut-il tout casser ?
Il ne voit et n’appelle que les outils que ses portées lui ouvrent. Une portée en lecture seule ne laisse passer que les actions marquées comme telles, et chaque appel est consigné.
Et un humain, dans tout ça ?
Il garde la même porte, en REST ou à l’écran. L’agent et l’humain appellent les mêmes actions, avec les mêmes contrôles.
Le reste du socle
Les actions naissent dans les Workers du framework ; le Hub les rassemble et les protège.