Le problème que tout le monde rencontre tôt ou tard
Dès qu'on commence à brancher des agents IA sur ses applications métier, le même besoin revient en boucle : exposer quelques outils de diagnostic (statut des queues, logs, retry de jobs), protégés par des permissions, accessibles uniquement via un identifiant non devinable. Et à chaque nouveau projet, on réécrit la même mécanique de zéro.
C'est exactement le constat que fait Nasrul Hazim Bin Mohamad dans son dev log du 19 juin 2026, repéré sur dev.to. En une seule journée, il a déployé des serveurs MCP (Model Context Protocol) sur trois plateformes d'entreprise différentes — un système IAM, un gestionnaire d'API-gateway et un portail utilisateur — et s'est rendu compte qu'il recopiait systématiquement le même socle d'outils. Sa réponse : en faire un package générique, laravel-mcp-kit.
L'angle est intéressant bien au-delà de l'écosystème Laravel : il illustre une démarche d'industrialisation qu'on peut reproduire dans n'importe quel projet PHP, Symfony y compris.
MCP, en deux mots
Le Model Context Protocol est un standard ouvert qui permet à un agent IA (type Claude, ou tout LLM compatible) d'interagir avec une application via un ensemble d'outils bien définis : lecture de logs, statut d'une queue, relance d'un job en échec, gestion de tokens, etc. Plutôt que de donner un accès brut à une base de données ou à un shell, on expose une API d'outils contrôlée, avec ses propres règles d'autorisation.
Le vrai sujet n'est donc pas "comment parler à un LLM", mais "comment exposer en toute sécurité les bons leviers opérationnels à un agent qui peut agir au nom d'un humain".
Le pattern qui revient à chaque serveur MCP
En construisant trois serveurs MCP coup sur coup, l'auteur a identifié une forme commune, toujours la même :
- Des outils de lecture seule, protégés par une vérification d'autorisation (ability gate), pour le diagnostic :
whoami, lecture de logs, statut des queues.
- Quelques outils d'écriture, qui ne touchent jamais directement le domaine métier mais passent systématiquement par une couche d'Actions (le pattern Action/Service qu'on retrouve aussi côté Symfony avec les handlers de commandes).
- Une interface d'administration minimale pour activer/désactiver le serveur et gérer les tokens d'accès.
- Des identifiants opaques (UUID) plutôt que des IDs auto-incrémentés, pour éviter qu'un agent (ou un attaquant ayant capturé un token) puisse deviner ou énumérer des ressources.
Une fois ce pattern identifié trois fois de suite, le réécrire une quatrième fois n'avait plus de sens. D'où le package.
Ce qu'apporte concrètement laravel-mcp-kit
Le package extrait la boîte à outils générique — les outils d'exploitation qu'on retrouve presque partout — et la rend opt-in et modulaire :
- Chaque outil ne s'enregistre que si le package qu'il instrumente est réellement présent dans le projet. Pas de queue dashboard ? L'outil "queue status" ne s'active simplement pas.
- Tous les outils passent par le même mécanisme de gate (autorisation) avant exécution.
- Toute référence à une ressource transite par UUID, jamais par un identifiant interne séquentiel.
En pseudo-code, l'idée d'enregistrement conditionnel ressemble à ceci :
if (class_exists(\Illuminate\Queue\QueueManager::class)) {
$registry->register(new QueueStatusTool());
}
$registry->register(new WhoAmITool(), gate: 'mcp.diagnostics');
Le point clé n'est pas la syntaxe Laravel en soi, mais le principe : un outil ne doit jamais exister sans sa permission associée, et ne doit jamais s'enregistrer si sa dépendance n'est pas là. C'est ce double verrou — présence + autorisation — qui rend le toolbox réutilisable sans devenir un trou de sécurité.
Pourquoi ça parle aussi aux équipes Symfony
Chez MulerTech, on travaille principalement en PHP/Symfony, et ce retour d'expérience se transpose presque terme à terme :
- Bundle dédié : exactement comme un bundle Symfony peut s'enregistrer conditionnellement selon les services disponibles dans le container, un toolbox MCP peut vérifier la présence d'un bundle (Messenger pour les queues, MonologBundle pour les logs) avant d'exposer l'outil correspondant.
- Voters comme gates : le système de gates décrit ici correspond directement aux Voters de Symfony Security. Chaque outil MCP devrait être protégé par un Voter dédié, testable indépendamment du reste de l'application.
- Identifiants opaques : utiliser des UUID (ou des ULID) comme clé d'exposition externe plutôt que l'ID auto-incrémenté de la base est une bonne pratique générale, que Doctrine facilite nativement.
- Écriture via Messenger : faire transiter toute action d'écriture déclenchée par un agent via un bus de commandes (Messenger) plutôt que d'appeler directement un repository garantit la même traçabilité et la même séparation des responsabilités que les "Actions" évoquées dans l'article.
Ce qu'il faut retenir
L'enseignement principal de ce dev log n'est pas tant le code que la méthode : dès qu'un pattern technique se répète trois fois dans des contextes différents, c'est le signal qu'il mérite d'être extrait en package réutilisable. Pour des serveurs MCP destinés à des agents IA opérant sur des systèmes de production, cette discipline est d'autant plus importante que les enjeux de sécurité — autorisation, traçabilité, identifiants non devinables — ne souffrent aucune approximation.
Si votre équipe commence à exposer des outils MCP à des agents IA, la question à se poser n'est pas "comment écrire ce serveur", mais "quelle est la part générique que je vais devoir réécrire trois fois si je ne l'extrais pas maintenant".
Article inspiré du dev log original "Dev Log: 2026-06-19 — MCP Servers Everywhere, Email That Tracks Itself, and Menus That Behave" de Nasrul Hazim Bin Mohamad, publié sur dev.to.
