Après plusieurs mois d’initiatives expérimentales dispersées, un projet a émergé courant du premier trimestre 2025 pour standardiser l’exposition d’un site WordPress comme serveur MCP : MCP Adapter for WordPress. Son approche est pragmatique : plutôt que de réinventer une couche de description des fonctionnalités, il s’appuie sur ce que WordPress expose déjà par son API REST et sur les routes personnalisées enregistrées par les extensions via register_rest_route(), en les traduisant vers le format attendu par un client MCP.
Cet article présente la structure générale de ce connecteur et ce qu’il permet concrètement à ce stade de son développement, sans prétendre à une couverture exhaustive tant le projet évolue vite.
Le principe : traduire, pas dupliquer
Plutôt que de demander aux développeurs d’extensions de réécrire une couche entière pour exposer leurs fonctionnalités au format MCP, l’adaptateur propose un mécanisme d’enregistrement qui réutilise la logique déjà en place pour l’API REST : un même point de terminaison peut ainsi rester accessible aux clients REST classiques tout en devenant, une fois déclaré explicitement, un outil (tool) interrogeable par un client MCP compatible. Cette approche limite la duplication de code et facilite l’adoption par les développeurs d’extensions déjà familiers avec l’API REST native de WordPress.
Une exposition volontaire, jamais automatique
Point important pour la sécurité : aucune route REST existante n’est exposée automatiquement au protocole MCP par la simple installation de l’adaptateur. Chaque capacité doit être déclarée explicitement, à la façon d’un enregistrement REST classique, avec une description destinée au modèle qui explique ce que fait l’outil et quels paramètres il attend :
add_action( 'mcp_adapter_init', function ( $serveur ) {
$serveur->enregistrer_outil( array(
'nom' => 'lister-articles-en-attente',
'description' => 'Liste les articles WordPress en attente de relecture éditoriale.',
'callback' => 'mon_extension_lister_articles_attente',
'permission_callback' => function () {
return current_user_can( 'edit_others_posts' );
},
) );
} );Le permission_callback fonctionne exactement comme sur une route REST classique : il est évalué à chaque appel, dans le contexte de l’utilisateur ou du jeton d’authentification associé à la session MCP en cours. Un agent IA connecté avec les droits d’un abonné ne peut donc pas invoquer un outil qui nécessite la capacité edit_others_posts, exactement comme un appel REST classique serait rejeté dans les mêmes conditions.
Ce que ça permet concrètement aujourd’hui
- Lister, créer ou modifier du contenu via un assistant IA connecté au site, dans les limites des droits accordés
- Interroger des données structurées du site (statuts de commentaires, statistiques de publication) depuis une conversation avec un assistant compatible MCP
- Déclencher des actions de maintenance courantes, par exemple la purge d’un cache, via une conversation en langage naturel plutôt qu’une commande WP-CLI
Ce périmètre reste volontairement restreint à ce stade : le projet est jeune, et la priorité affichée par ses contributeurs porte sur la solidité du modèle de permissions avant l’élargissement des capacités disponibles par défaut.
Un point de vigilance : l’authentification
Contrairement à une session d’administration WordPress classique, un client MCP se connecte généralement via un jeton d’application dédié, dans la continuité du système d’application passwords introduit par WordPress plusieurs années auparavant. Ce jeton doit être traité avec la même rigueur qu’une clé API de service tiers : stocké de façon sécurisée côté client, révocable individuellement depuis le profil utilisateur WordPress, et jamais partagé entre plusieurs usages distincts, pour permettre une révocation ciblée en cas de compromission sans affecter les autres intégrations.
Exposer un site à un agent IA commence toujours par la même question qu’exposer une API : qui a le droit de faire quoi, et comment le vérifie-t-on à chaque appel ?
En résumé
MCP Adapter for WordPress propose une passerelle pragmatique entre l’API REST existante de WordPress et le protocole MCP, sans dupliquer la logique déjà en place côté extensions. Son modèle d’exposition strictement opt-in, couplé au système de permissions natif de WordPress, en fait une base sérieuse pour les premières expérimentations d’agents IA pilotant un site, à condition de rester rigoureux sur la gestion des jetons d’authentification qui donnent accès à ces capacités.
