Notre serveur MCP pour WordPress ne sait que lire. C'est voulu.

L'Abilities API, intégrée au cœur depuis WordPress 6.9, décrit les fonctions d'un site de manière standard : un identifiant, une description, un schéma d'entrée et de sortie, un contrôle de droits (permission_callback). Le Model Context Protocol (MCP) permet à un assistant — Claude Desktop, Claude Code, Cursor et d'autres — de se brancher sur des sources d'outils. L'extension MCP Adapter, publiée par le projet WordPress sur GitHub, fait le pont entre les deux.

Mises bout à bout, ces briques permettent à un agent qui tourne sur votre ordinateur d'agir sur votre site. C'est précisément pour cela qu'il faut choisir ce qu'on lui ouvre.

Ce que fait le connecteur embarqué dans StormPress

StormPress embarque le connecteur Stormeo, qui déclare trente abilities : santé de la base, espace disque, audit SEO, intégrité des fichiers du cœur, mais aussi création d'articles, mise à jour d'extensions, vidage de cache, annulation d'une modification.

Quand MCP Adapter est installé et que l'Abilities API est disponible, le connecteur demande à l'Adapter de publier un serveur MCP, servi par défaut à l'adresse /wp-json/stormeo/v1/mcp (l'écran décrit plus bas affiche l'adresse exacte de votre site). Ce branchement n'est pas encore éprouvé avec l'Adapter lui-même ; nous y revenons plus bas. Si l'un des deux manque, il ne publie rien. Et ce serveur n'expose pas les trente abilities : il en expose dix.

Les dix abilities exposées

Toutes lisent ou vérifient ; aucune ne modifie le site.

Les deux dernières sont des pré-contrôles : un agent peut demander si le site est prêt pour une mise à jour, pas la lancer.

get-core-integrity compare les fichiers sensibles du cœur à une référence enregistrée sur le site, mais ne crée jamais cette référence. Celle-ci est établie par le scan de sécurité planifié du connecteur, qui tourne chaque jour, dès son premier passage ; sur un site qui n'est pas relié à StormeoOS, il l'établit sans rien envoyer. Tant que ce passage n'a pas eu lieu, get-core-integrity le dit (chaque fichier est marqué no_baseline) plutôt que d'enregistrer comme sain un état peut-être déjà altéré. Jusqu'au connecteur 3.13.6, son premier appel écrivait cette référence ; l'ability n'étant alors jamais enregistrée sur WordPress 6.9 et suivants, ce défaut restait latent.

Les vingt abilities retenues

Créer, modifier ou supprimer une page, un article, un produit ; changer le statut d'une commande ; modifier un utilisateur ; mettre à jour ou rétrograder une extension ; vider le cache ; restaurer l'état capturé avant une modification ; changer la politique de mises à jour automatiques ; lancer un scan de sécurité ou d'espace disque ; produire un rapport de maintenance ; réinitialiser la référence d'intégrité. Ces vingt abilities existent, mais elles ne sont pas exposées : ni au serveur MCP, ni au point d'accès REST des abilities du cœur (/wp-json/wp-abilities/v1), qui ne sert, parmi les trente du connecteur, que les dix lectures.

Ce n'est pas un oubli : chaque ability du connecteur doit être classée exposée ou retenue, et nos tests échouent si une nouvelle n'est classée nulle part. L'exposition est une décision, jamais un effet de bord.

Pourquoi pas les permissions WordPress seules ?

Chaque ability a déjà son permission_callback : un agent connecté avec un compte d'éditeur ne fera pas plus qu'un éditeur. Cette barrière reste en place, mais elle dit si l'utilisateur peut faire l'action, pas si l'action devait être confiée à un agent. Trois raisons nous font tenir les écritures à l'écart :

• Un agent lit des contenus que vous n'avez pas écrits. Un commentaire ou une page importée peut contenir des instructions déguisées ; un agent qui n'a que des outils de lecture ne peut pas être détourné vers une suppression par ce serveur MCP — à condition que son compte ne lui ouvre pas davantage ailleurs (voir plus bas).
• Une écriture sur un site client engage quelqu'un. Mettre à jour une extension en production a un responsable ; ce geste passe aujourd'hui par un parcours où une personne décide.
• Toutes les erreurs ne se défont pas. Ouvrir une écriture supposerait de savoir la borner, la journaliser et l'annuler.

Se connecter, concrètement

Depuis la version 4.2.0, StormPress a un écran Agents IA (MCP), réservé aux administrateurs (capacité manage_options). Il n'écrit rien : il fait l'état des lieux, puis donne la marche à suivre.

Ce que l'écran vous dit

• Les prérequis : l'Abilities API (WordPress 6.9 ou plus) et MCP Adapter, que StormPress n'embarque pas ; l'écran renvoie vers son dépôt.
• L'état du serveur : publié, non publié faute de prérequis, ou non enregistré malgré les prérequis — ce dernier cas, mesuré sur les routes REST réelles, signale par exemple une version de l'Adapter que le connecteur ne sait pas piloter.
• L'adresse du serveur telle que votre site la sert, et les abilities exposées, chacune avec son rôle minimum.

La marche à suivre

1. Un utilisateur dédié à l'agent, avec le rôle le plus bas qui couvre ce qu'il doit lire. Un compte dédié se révoque sans toucher au vôtre.
2. Un mot de passe d'application, créé depuis le profil de ce compte ; WordPress ne l'affiche qu'une fois. S'ils sont indisponibles (site sans HTTPS, extension de sécurité qui les coupe), l'écran le signale.
3. Brancher le client. Pour Claude Code, l'écran donne la commande complète, avec l'adresse de votre site. Il reste à remplacer l'emplacement réservé par l'identifiant et le mot de passe d'application, séparés par deux-points et encodés en base64 :

claude mcp add --transport http stormpress https://votre-site.fr/wp-json/stormeo/v1/mcp --header "Authorization: Basic <identifiant:mot de passe en base64>"

L'écran fournit aussi la commande qui calcule cette valeur sous macOS et Linux : printf '%s' 'identifiant:mot de passe' | base64.

Pour Claude Desktop, Cursor et les autres clients, l'écran ne propose aucune syntaxe : chacun déclare un serveur MCP distant à sa façon, et tous n'acceptent pas un en-tête d'authentification. L'écran vous invite à le vérifier dans la documentation de votre client et renvoie à la liste des clients tenue par le projet MCP. L'adresse, elle, ne change pas.

Et le copilote intégré ?

Depuis la version 4.2.0, le copilote de StormPress reçoit comme outils les abilities déclarées sur votre site par WordPress et vos extensions (ses autres garde-fous sont détaillés dans un article dédié). Pas toutes :

• une ability annotée destructive par l'extension qui la déclare n'est pas proposée par défaut ;
• pour le connecteur Stormeo, le copilote applique la liste du serveur MCP : les dix exposées deviennent des outils, les vingt retenues restent à l'écart ;
• les abilities de StormPress lui-même sont écartées, ses outils intégrés couvrant déjà l'essentiel ;
• un filtre, stormpress_ai_expose_ability, permet à un développeur de trancher autrement, ability par ability.

Qu'une lecture exposée du connecteur arrive bien parmi les outils du copilote est vérifié par un test qui démarre StormPress ; son appel auprès d'un vrai fournisseur d'IA n'a pas encore été éprouvé.

Chaque appel passe par l'Abilities API, qui applique le permission_callback de l'ability : le copilote agit avec vos droits, jamais au-delà. Ces outils ne sont proposés qu'aux utilisateurs qui peuvent modifier des articles.

Ouvrir un site à des agents est facile. Choisir ce qu'on leur ouvre est le vrai travail.

• MCP
• Abilities API
• agents IA
• WordPress
• sécurité