Ce billet explique comment intégrer un serveur MCP (Model Context Protocol) dans un projet Symfony en utilisant le bundle symfony/mcp-bundle. L'objectif est d'exposer des outils via un endpoint HTTP standardisé, permettant à des clients comme Claude d'interagir dynamiquement avec ces outils sans nécessiter une API REST classique. La configuration repose sur un fichier YAML minimal, où l'on précise notamment le transport HTTP (plutôt que stdio) et les répertoires à scanner pour découvrir les outils, un point crucial souvent omis dans la documentation officielle.

L'auteur détaille ensuite la création d'un outil MCP via une méthode PHP annotée avec #[McpTool], où la description et les paramètres typés définissent le comportement exposé. Cependant, il souligne des limites actuelles du bundle, comme l'absence de schéma de sortie typé, obligeant à gérer manuellement la sérialisation des réponses. La sécurité est également abordée, avec une recommandation d'isoler la route MCP sur un sous-domaine dédié pour limiter les risques liés à l'exécution de code privilégié.

Enfin, le billet met en garde contre les pièges spécifiques à la production, notamment les comportements encore instables des versions 0.x du bundle et du SDK MCP, ainsi que les différences entre la version du serveur exposée et celle du bundle. L'auteur insiste sur l'importance de bien configurer le transport HTTP et de sécuriser l'endpoint pour éviter des vulnérabilités dans un environnement partagé.

Un développeur partage son expérience de transition de PHP vers Go, soulignant les changements de paradigme rencontrés dès la première semaine. L’idée principale réside dans l’approche radicalement différente de la gestion des erreurs et des interfaces par rapport à PHP. Go impose une gestion explicite des erreurs via des retours multiples (comme error), remplaçant les blocs try/catch, ce qui peut sembler contraignant au début mais favorise une transparence accrue dans le code.

L’auteur aborde également l’absence d’héritage classique au profit de la composition, illustrée par l’embedding de structures, une méthode qui diffère fortement des pratiques orientées objet traditionnelles. Les interfaces en Go, définies par les comportements plutôt que par des déclarations explicites, surprennent par leur flexibilité et leur alignement avec le principe de ségrégation des interfaces (ISP) de SOLID, bien que cette approche puisse dérouter les développeurs habitués à des systèmes plus rigides.

Enfin, l’article souligne que Go privilégie la simplicité et la clarté, même au prix d’une courbe d’apprentissage plus abrupte. L’auteur reste partagé sur l’efficacité à long terme de ces choix, mais reconnaît l’influence positive de cette philosophie sur ses habitudes de codage, malgré une adaptation initiale difficile.