« Le Model Context Protocol est une norme ouverte qui permet aux applications de fournir du contexte et des outils aux grands modèles de langage de façon standardisée », résume la documentation officielle du protocole publié fin 2024. Sur un bloc Gutenberg maison, cette définition abstraite prend un sens concret dès qu’on tente de l’exposer à un assistant IA capable d’agir dessus.
Ce retour porte sur un serveur MCP minimal construit pour un seul cas d’usage : permettre à un assistant compatible de modifier la configuration d’un bloc d’appel à l’action (couleur, texte du bouton, lien de destination) sans toucher à l’interface de l’éditeur. Il ne couvre pas l’Abilities API native de WordPress, encore en développement à cette date, ni la génération de code de bloc par l’IA, qui relève d’un usage différent.
Pourquoi un serveur MCP plutôt qu’un simple endpoint REST
La question s’est posée frontalement : pourquoi ne pas simplement exposer un endpoint REST WordPress classique, que l’assistant pourrait appeler directement ? La réponse tient à la découverte des capacités. Un serveur MCP expose ses outils avec un schéma structuré (nom, description, paramètres attendus) que l’assistant peut interroger dynamiquement, sans documentation externe à maintenir en parallèle. Un simple endpoint REST demande, lui, de décrire manuellement à l’assistant ce qu’il fait et comment l’appeler, ce qui devient vite fragile.
L’architecture retenue
Le serveur MCP tourne en Node.js, séparé du processus PHP de WordPress, et communique avec lui via l’API REST WordPress authentifiée par application password. Un seul outil est exposé, configurer_bloc_cta, qui accepte trois paramètres : l’identifiant de l’article contenant le bloc, la couleur souhaitée, et le texte du bouton.
{
"name": "configurer_bloc_cta",
"description": "Modifie la couleur et le texte d'un bloc d'appel à l'action sur un article donné.",
"inputSchema": {
"type": "object",
"properties": {
"articleId": { "type": "integer" },
"couleur": { "type": "string" },
"texteBouton": { "type": "string" }
},
"required": [ "articleId", "couleur", "texteBouton" ]
}
}
Côté WordPress, l’outil ne modifie jamais directement post_content par manipulation de chaîne : il passe par une fonction PHP dédiée qui parse le contenu avec parse_blocks(), localise le bloc cta/appel-action par son nom, modifie ses attributs, puis reconstruit le contenu avec serialize_blocks(). Cette précaution évite de corrompre la structure HTML commentée du bloc, un risque réel avec une simple recherche-remplacement de texte.
Ce qui a mal fonctionné au premier essai
La première version de l’outil acceptait une couleur en langage naturel (« bleu foncé »), que l’assistant traduisait lui-même en code hexadécimal avant l’appel. Le résultat était inconsistant : deux appels avec la même demande produisaient parfois deux teintes de bleu différentes, l’assistant réinterprétant la couleur à chaque fois plutôt que de la fixer. La correction a consisté à imposer un schéma strict de couleurs autorisées, définies côté serveur et non laissées à l’appréciation du modèle.
- Couleur restreinte à une liste fermée issue de la palette
theme.jsondu thème, pas de valeur libre. - Longueur du texte de bouton plafonnée à 40 caractères, rejetée sinon par l’outil avant écriture.
- Chaque appel journalisé avec l’identifiant de la session assistant, pour traçabilité en cas d’anomalie.
La question de la validation
Exposer une action d’écriture à un assistant IA soulève une question de confiance : faut-il appliquer la modification immédiatement, ou la soumettre à validation humaine avant écriture en base ? Le choix retenu ici a été la validation systématique : l’outil MCP retourne une prévisualisation du changement proposé, et une seconde confirmation explicite de l’utilisateur humain est nécessaire avant l’appel d’écriture réel côté REST.
Un outil MCP qui écrit directement en base sans étape de confirmation n’est pas un gain de temps, c’est un gain de vitesse pour produire des erreurs.
Limites observées à ce stade
Le protocole étant encore jeune début 2025, la prise en charge côté client (l’application hébergeant l’assistant) reste variable : certains clients gèrent mal les schémas d’entrée complexes avec des énumérations imbriquées, ce qui a forcé à simplifier le schéma de l’outil plus que souhaité initialement. Ce type de contrainte évoluera probablement avec la maturité de l’écosystème.
Pour aller plus loin
Ce premier serveur reste volontairement étroit : un seul bloc, une poignée d’attributs, une validation humaine obligatoire. L’intérêt n’était pas de couvrir large mais de vérifier que l’architecture (serveur Node séparé, appel REST authentifié, parsing structuré du contenu) tenait la route avant d’envisager d’exposer davantage de blocs. La documentation officielle du Model Context Protocol reste la référence à suivre pour toute évolution du schéma d’outils.
