Tous les articles

Serveurs MCP en PHP : ce que donne le SDK officiel, et quand s'en passer

Outils IA · 4 min de lecture ·

Le Model Context Protocol a un SDK PHP officiel, développé avec The PHP Foundation et le projet Symfony, et il figurait cette semaine dans le classement hebdomadaire des dépôts PHP en tendance sur GitHub. Si vous vivez du PHP, vous pouvez donc ouvrir votre application à un assistant IA sans changer de langage. Avant de vous lancer, mieux vaut savoir ce que vous construisez vraiment : une porte d'entrée dans votre système, à laquelle un modèle viendra frapper.

MCP en deux phrases

MCP est un protocole ouvert qui permet à une application IA de découvrir et d'appeler des outils (des actions), de lire des ressources (des données) et d'utiliser des prompts (des modèles de requête) qu'un serveur expose. L'application IA joue le rôle d'hôte, votre code celui de serveur, et les deux échangent des messages structurés au lieu de laisser le modèle deviner votre API à partir de la documentation.

Appli IA (l'hôte) lance votre script messages via STDIO ou HTTP, pour un serveur distant Votre serveur MCP PHP écrit avec mcp/sdk Outils Ressources Prompts actions, données, modèles
En STDIO, l'hôte exécute votre script PHP comme processus enfant et lui parle par son entrée et sa sortie. Rien n'écoute sur un port.

Ce que le SDK PHP vous apporte

Le SDK ne dépend d'aucun framework et couvre les deux côtés : serveurs et clients, outils, ressources et prompts, transports STDIO et HTTP, sessions et autorisation. Il parle aussi les deux générations du protocole, l'ancienne poignée de main qui commence par initialize et la révision sans état du 2026-07-28. L'installation passe par composer require mcp/sdk, plus symfony/finder si vous voulez qu'il découvre vos outils en parcourant votre code. L'exemple de serveur du README se lit d'une traite :

class Calculator
{
    /** Adds two numbers. */
    #[McpTool]
    public function add(int $a, int $b): int { return $a + $b; }
}

exit(Server::builder()
    ->setServerInfo('Calculator', '1.0.0')
    ->setDiscovery(__DIR__, ['.'], excludeDirs: ['vendor'])
    ->build()
    ->run(new StdioTransport()));

Un attribut fait d'une méthode un outil, le commentaire de documentation devient sa description et les paramètres typés deviennent ses entrées. Une ressource fonctionne de la même façon avec #[McpResource] et une URI. Mais la ligne du README qui compte le plus n'est pas dans le code : jusqu'à la première version majeure, le SDK est considéré comme expérimental. Fixez la version et attendez-vous à des changements.

Comme il est indépendant de tout framework, il tourne dans une application Laravel comme n'importe quel paquet Composer. Le README cite des intégrations construites dessus pour Symfony, API Platform, Drupal et d'autres. Vérifiez s'il existe une intégration Laravel avant d'écrire la colle vous-même.

Quand un serveur est le bon outil, et quand il ne l'est pas

Un serveur MCP se justifie quand il donne au modèle quelque chose qu'il ne peut obtenir autrement : des données vivantes de votre base, ou une action dans votre système, comme consulter l'état d'une commande ou ouvrir un ticket de support. Pour de la documentation statique, c'est un mauvais choix. Cristian Tabacitu, qui maintient Backpack for Laravel, a écrit cette semaine que le serveur MCP qu'ils avaient construit pour interroger leur documentation donnait des résultats mitigés, parce que l'agent doit décider de l'appeler et, la plupart du temps, ne le fait pas. Si l'agent a déjà l'information, ou peut la lire dans votre code, un serveur ajoute une pièce mobile et pas grand-chose d'autre.

Chaque argument d'outil est une entrée non fiable

Un outil est une action, et ses arguments viennent d'un modèle qui a lu tout ce qu'on a mis devant lui. Traitez-les exactement comme un formulaire envoyé par un inconnu. Ce qui suit relève des bonnes pratiques générales, le SDK ne le fait pas à votre place :

frontière de confiance entrée non fiable vos règles Le modèle choisit un outil Appel d'outil et ses arguments Votre validation type, plage, droits Vos données droits minimaux Rejeté, journalisé
Les paramètres typés vérifient la forme d'un argument. Seul votre code peut vérifier si cet utilisateur a le droit de toucher cet enregistrement.

Validez chaque argument comme vous valideriez le corps d'une requête. Donnez à chaque outil la plus petite permission qui suffit à sa tâche : une connexion en lecture seule pour un outil de consultation, une table plutôt que tout le schéma. N'exposez jamais un outil qui exécute n'importe quelle requête SQL ou commande shell qu'on lui passe. Identifiez l'appelant et vérifiez les droits utilisateur par utilisateur, comme le font vos contrôleurs. Et journalisez chaque appel : le jour où un outil fait quelque chose d'inattendu, vous saurez quels arguments l'ont demandé.

Un int dans la signature de la méthode vous dit que l'argument est un nombre. Il ne vous dit pas que ce nombre appartient à la personne qui le demande.

Pour essayer, commencez par un seul outil en lecture seule, sur des données que votre assistant ne voit pas aujourd'hui, lancez-le en STDIO sur votre machine, et lisez chaque appel dans le journal pendant une semaine avant d'ajouter un outil qui écrit quoi que ce soit. Source : le SDK PHP officiel de MCP sur GitHub.

Ce que disent les lecteurs

  1. Pas encore de mot. Le premier est toujours le plus courageux.
Vous construisez quelque chose du genre ? Je peux vous aider. Écrivez-moi sur WhatsApp