Je mets cartes sur table avant que le café refroidisse : l'élément qui fait peur dans laravel/mcp 1.0, la suppression des sessions côté serveur, est pour nous la partie la plus facile de la mise à jour. Ce qui décidera si les agents font vraiment des choses utiles avec ton appli, c'est le catalogue d'outils, et celui-là arrive avec un comportement par défaut que tu as le droit d'ignorer. À mon avis, l'ignorer, c'est justement la vraie erreur qui te guette dans cette version.

Commençons par les sessions, puisque c'est là que se loge l'inquiétude. Le package parle désormais la révision MCP 2026-07-28, et avec cette révision, le serveur ne se souvient d'aucune conversation d'un appel à l'autre. $request->sessionId() et $request->setSessionId() disparaissent, tout comme SessionInitialized. Si tu planquais une recherche coûteuse ou un compteur des étapes de l'agent derrière un ID de session, ce code cesse de compiler dans ta tête dès que tu lis le changelog. Soit. Maintenant, pense à ce que fait PHP depuis avant que la plupart d'entre nous aient écrit leur premier foreach : chaque requête démarre, fait son boulot et oublie tout. On a bâti des carrières entières sur cette amnésie. Des files d'attente, Redis, un ID de corrélation dans le payload, une ligne dans une table indexée par quelque chose que l'appelant te renvoie. Cette boîte à outils est déjà dans ton dossier vendor.

Pour une équipe Laravel, la migration ressemble donc à ça en pratique. Tu cherches les méthodes supprimées dans le dossier app, et chaque résultat devient une petite question de conception : quel identifiant l'agent doit-il m'envoyer pour que je retrouve mes propres notes ? En général, la réponse, c'est un ID de job ou un ID de rapport que tu générais déjà de toute façon. J'ai vu des équipes d'autres écosystèmes se donner beaucoup de mal pour greffer du routage persistant sur leurs processus longue durée ; les gens de Go, et c'est tout à leur honneur, se tournent eux aussi très tôt vers des ID explicites, et ça fait plaisir de voir le protocole adopter l'approche en laquelle les deux camps avaient déjà confiance. Ton load balancer se fiche désormais de savoir quelle machine répond. C'est un cadeau.

Les anciens clients ne vont pas tomber du jour au lendemain non plus. La version reconnaît toujours les révisions 2025-06-18 et 2025-11-25 pour les clients qui arrivent à l'ancienne, ce qui compte si des agents que tu ne contrôles pas pointent vers ton serveur. Teste ce chemin à part. C'est le genre de code de compatibilité qui marche le jour du lancement et qui pourrit avant Noël si rien ne le fait tourner.

Passons maintenant à la partie qui devrait vraiment t'empêcher de dormir. La 1.0 permet à un agent de trouver des outils via search_tools et execute_tools au lieu de recevoir tout ton inventaire d'entrée. Imagine l'appli d'admin interne typique sur laquelle on m'appelle : une trentaine d'outils, dont la moitié portent une variante de GetOrder, FindOrder ou OrderLookup, chacun avec un paragraphe de description et un schéma JSON bien gras. Chaque connexion paie tout ça en contexte avant que le modèle ait produit le moindre token de travail utile, et ensuite le modèle doit choisir le bon dans une rangée de quasi-jumeaux. Il se trompe plus souvent que tu ne le voudrais, et tu finis par accuser le modèle pour un menu que tu as conçu toi-même.

Le serveur MCP de Statamic a fait le choix que j'aimerais voir devenir la norme : trois outils visibles à la connexion, les huit autres accessibles par la recherche. C'est une décision produit, du même ordre que choisir ce qui va dans une barre de navigation et ce qui reste dans les paramètres. Il faut que quelqu'un en soit responsable. Dans la plupart des équipes que je connais, personne ne s'en chargera, parce que l'ancien comportement continue de marcher et qu'aucun test ne passe au rouge quand un agent brûle un tiers de son contexte à lire la description d'outils qu'il n'appelle jamais. Ajoute les nouveaux indices de cache sur tout ce qui est statique, tables de référence et descriptions de schéma, et tu réduis en plus les allers-retours répétés.

Un mot rapide sur l'auth pour que tu ne te fasses pas surprendre : PKCE est désormais obligatoire, et si un serveur d'autorisation tiers n'annonce pas code_challenge_methods_supported dans ses métadonnées, redirect() lèvera une exception au lieu de continuer. Le Dynamic Client Registration est déprécié au profit des Client ID Metadata Documents. Déprécié, ça veut dire que ça marche encore aujourd'hui, alors inscris la bascule dans ta roadmap et fais-la un mardi tranquille plutôt que la semaine où la suppression tombe.

C'est là que j'aimerais t'entendre, parce que j'ai une opinion tranchée et peu de données. Quand tu répartis tes outils entre ceux qu'un agent voit à la connexion et ceux qu'il doit chercher, quelle règle appliques-tu ? Les plus appelés, les plus dangereux, les plus ambigus, quelque chose lié aux rôles des utilisateurs ? Raconte-moi comment tu as tracé cette ligne dans une vraie appli, et si l'agent s'est amélioré ou s'il a simplement changé.