Les serveurs MCP ouvrent une nouvelle porte entre les applications Laravel et les assistants capables d’interagir avec elles. Grâce au Model Context Protocol, un agent peut découvrir des outils, consulter des données ou déclencher une action métier sans intégrer à l’avance chaque détail de l’API. Mais à mesure que le catalogue grandit, une difficulté apparaît : présenter toutes les définitions d’outils à chaque échange encombre le contexte du modèle et complique ses choix.

Une approche plus légère consiste à ne rendre visibles que quelques outils de recherche et d’exécution, puis à laisser l’agent découvrir les fonctions utiles à la demande. Cette méthode, mise en œuvre dans Laravel MCP 1.0, évite d’exposer tout le catalogue en permanence et ne nécessite pas d’exécuter du code généré par le modèle. Pour une boutique fictive, par exemple, les fonctions de commande, de remboursement ou de stock restent accessibles, mais seules celles utiles à la question sont chargées. Résultat : une intégration d’API plus lisible, une architecture logicielle plus simple à sécuriser et des outils pour développeurs qui s’intègrent naturellement au développement web avec Laravel.

En bref : des serveurs MCP Laravel plus simples à parcourir

• Le problème : chaque outil déclaré ajoute son nom, sa description et son schéma aux informations envoyées à l’agent.

• La réponse : deux méta-outils, dédiés à la recherche et à l’exécution par lots, permettent de retrouver les fonctions utiles à la demande.

• La prudence : le code PHP généré par un modèle ne doit pas être évalué directement dans le processus de l’application.

• Le bénéfice : moins de définitions à charger, une meilleure lisibilité pour l’agent et une productivité accrue sans infrastructure de sandbox à gérer.

Pourquoi un serveur MCP Laravel peut vite encombrer le contexte

Un appel d’outil ressemble à une requête d’API, mais le modèle doit d’abord recevoir les éléments qui lui permettent de choisir et de construire cet appel. Quand un serveur expose plusieurs dizaines de fonctions, leurs noms, descriptions et schémas d’entrée sont généralement fournis avant même que l’agent connaisse la demande.

Le coût ne se limite pas aux jetons consommés : des fonctions proches peuvent aussi rendre la sélection moins fiable. Les mesures rapportées pour Laravel MCP illustrent l’écart : dans un test avec 40 outils, la liste directe représentait 23 423 octets, contre 1 431 octets avec un catalogue de recherche. Ces chiffres dépendent des outils testés, mais la tendance est nette : le catalogue garde une taille stable lorsque le nombre de fonctions augmente.

Des outils nombreux, des choix plus difficiles

Imaginons une boutique qui expose la consultation des commandes, les remboursements, les stocks, les livraisons et les rapports. Un client demande simplement où en est la commande 4021 : si toutes les fonctions sont affichées d’emblée, l’agent doit aussi parcourir des schémas liés aux retours ou aux inventaires.

Le guide de la documentation Laravel consacrée à MCP présente les bases pour relier un serveur aux outils, ressources et prompts d’une application. Pour démarrer concrètement, le tutoriel sur l’utilisation d’un serveur MCP dans Laravel complète utilement cette découverte.

Laravel MCP 1.0 : rechercher les outils avant de les exécuter

Le principe repose sur deux méta-outils. search_tools recherche les fonctions disponibles dans un catalogue ; execute_tools exécute ensuite une ou plusieurs fonctions sélectionnées. Les outils courants peuvent rester directement visibles, tandis que les autres deviennent accessibles uniquement lorsqu’une recherche les fait apparaître.

Dans l’exemple de la boutique, l’agent recherche « commande » et obtient la fonction de suivi appropriée. Il peut ensuite demander l’état de la commande 4021 sans recevoir au préalable les schémas des outils de remboursement ou de gestion des stocks. Une série de plusieurs appels peut aussi être envoyée dans un même lot, ce qui réduit les allers-retours lorsque les tâches sont indépendantes.

Une recherche lexicale utile aux descriptions d’outils

La recherche décrite dans cette approche est déterministe : elle privilégie les correspondances exactes, puis examine le nom, la description et le schéma d’entrée. Un outil nommé station_readings peut ainsi être trouvé par le terme « rainfall » si son schéma comporte un paramètre tel que rainfall_mm.

Ce détail rappelle qu’un nom de paramètre bien choisi sert aussi de documentation exploitable. Pour approfondir la création de serveurs, le guide consacré à la construction d’un serveur MCP avec Laravel présente également les étapes de mise en place et de validation des outils.

Éviter eval et garder les protections Laravel

Une première piste consiste à demander au modèle d’écrire du PHP pour enchaîner plusieurs outils. Cette technique peut sembler naturelle : l’agent connaît le langage et pourrait filtrer des résultats avant de les retourner. Mais exécuter ce texte avec eval() dans le processus Laravel lui donnerait potentiellement accès à l’environnement, au conteneur et aux connexions de l’application.

Une solution fondée sur une sandbox peut isoler le code, mais elle ajoute alors une infrastructure et des responsabilités d’exploitation. Une autre tentative, consistant à n’autoriser qu’un sous-ensemble de PHP, expose un problème différent : le modèle peut produire des constructions parfaitement valides en PHP, mais refusées par cet interpréteur limité. Un format JSON dont le schéma définit explicitement les opérations permises rend les règles plus visibles et plus faciles à tester.

Une exécution qui repasse par les mécanismes du framework

Dans l’approche décrite, chaque opération du lot est convertie en requête JSON-RPC puis transmise à ToolInvoker, le mécanisme utilisé pour un appel normal. Les règles d’enregistrement conditionnel sont vérifiées au moment de l’exécution : trouver un outil par la recherche ne suffit donc pas à obtenir automatiquement l’autorisation de l’utiliser.

Pour une application métier, il reste essentiel de protéger les actions sensibles avec les mécanismes d’authentification et d’autorisation adaptés. Un dossier sur l’authentification et le contrôle d’accès des agents IA dans un monolithe Laravel détaille les enjeux de cette intégration.

Choisir entre catalogue, outils directs et sandbox

La recherche à la demande n’est pas une solution universelle. Sur un serveur qui ne contient que quelques outils, tous fréquemment utilisés, présenter directement leurs définitions reste plus simple : ajouter une recherche préalable créerait alors un détour sans bénéfice notable.

À l’inverse, un catalogue devient intéressant quand l’application expose de nombreuses fonctions et que chaque interaction ne mobilise qu’une petite partie d’entre elles. Pour une équipe qui veut déployer ce type d’intégration, l’article sur le déploiement d’une application Laravel MCP avec Laravel Cloud apporte un complément pratique sur le passage en production.

• Outils déclarés directement : à privilégier pour un catalogue réduit et prévisible, car toutes les définitions restent immédiatement disponibles.

• Recherche et exécution par lots : adaptée aux catalogues importants, avec un chargement à la demande et sans exécuter de code produit par le modèle.

• Code généré dans une sandbox : pertinent lorsque l’agent doit effectuer des boucles, des conditions ou des calculs intermédiaires, à condition d’assumer l’infrastructure d’isolation.

La bonne architecture dépend donc du besoin réel : une application qui interroge trois fonctions n’a pas les mêmes contraintes qu’une plateforme exposant des centaines d’opérations. Le gain de simplicité vient souvent du choix de ne pas charger tout le catalogue à chaque échange.

Une approche pragmatique pour les applications intelligentes

Les serveurs MCP étendent les possibilités d’automatisation en donnant aux agents un accès structuré aux fonctions d’une application Laravel. Leur efficacité repose toutefois sur un équilibre : offrir assez de capacités pour répondre aux demandes, sans noyer le modèle sous des définitions inutiles ni introduire une exécution risquée.

Pour une petite application, des outils directs peuvent suffire. Lorsque le catalogue grandit, la recherche progressive rend les fonctions découvrables sans augmenter à chaque tour la charge initiale ; et si un scénario exige un véritable contrôle de flux, une sandbox conçue pour cet usage devient une option à évaluer. La solution la plus efficace est celle qui répond au besoin métier avec le moins de mécanismes à maintenir.