Comment créer un plugin MCP pour connecter ses agents IA à WordPress

Connecter un agent IA à WordPress avec une extension existante est relativement simple. Mais pour exposer une fonctionnalité propre à votre site, un type de contenu personnalisé ou une action métier spécifique, il faut aller plus loin et développer son propre plugin MCP WordPress.✨ Dans ce tutoriel, nous allons créer une extension capable de déclarer une fonctionnalité personnalisée grâce à la WordPress Abilities API, puis de la rendre accessible à un agent IA via le MCP Adapter officiel.🎉

L’objectif n’est donc pas simplement d’installer MCP, mais de comprendre comment développer une véritable intégration sur mesure. Si vous recherchez plutôt une configuration prête à l’emploi, sans développement PHP, consultez le tutoriel LWS pour découvrir MCP WordPress sans écrire de code, pour un usage no-code.

Objectif

👇À la fin de ce tutoriel, vous disposerez d’un plugin MCP WordPress fonctionnel déclarant une capacité personnalisée, appelée Ability. Celle-ci permettra de récupérer les derniers articles publiés sur votre site et pourra ensuite être utilisée par un client compatible MCP, comme Claude Desktop.✔ Nous allons construire progressivement la chaîne complète : votre plugin → Abilities API → MCP Adapter → agent IA. Vous apprendrez notamment à utiliser wp_register_ability(), à définir les paramètres acceptés par une Ability avec un JSON Schema, à contrôler son exécution avec permission_callback et à décider précisément quelles fonctionnalités rendre accessibles via MCP.⚡ Cette base pourra ensuite être adaptée à des besoins plus avancés : gestion de contenus personnalisés, automatisations métier, interactions avec WooCommerce ou connexion à une API interne.

Pré-requis

Avant de développer votre plugin MCP WordPress, assurez-vous de disposer des éléments suivants :

• un site sous WordPress 6.9 ou supérieur, avec un accès à ses fichiers via FTP, un gestionnaire de fichiers ou SSH ;
• des connaissances de base en PHP et en développement WordPress, notamment sur les hooks et les actions ;
• le MCP Adapter officiel de WordPress installé et activé ;
• un client compatible avec le protocole MCP, comme Claude Desktop ;
• idéalement, un environnement de développement ou de staging pour tester le plugin sans intervenir directement sur le site en production.

Aucune connaissance approfondie en intelligence artificielle n’est nécessaire. Nous expliquerons progressivement les éléments propres à MCP. En revanche, vous devez être suffisamment à l’aise avec PHP pour comprendre et adapter les différents exemples de code proposés dans ce tutoriel.

Comprendre l’architecture avant de coder

Avant d’écrire la première ligne de PHP, il est important de distinguer les trois composants qui interviennent dans notre plugin MCP WordPress. MCP n’est pas directement responsable de la logique métier exécutée dans WordPress : plusieurs couches collaborent pour rendre une fonctionnalité exploitable par un agent IA.

L’Abilities API constitue donc le point de départ. Introduite dans le cœur de WordPress avec WordPress 6.9, elle fournit une manière standardisée de déclarer ce qu’un composant WordPress est capable de faire.

Une Ability peut, par exemple :

• récupérer une liste d’articles,
• créer un contenu,
• consulter une donnée métier,
• déclencher une opération particulière.

Une fois enregistrée, elle n’est pas exclusivement destinée à l’intelligence artificielle : elle peut être découverte et exécutée depuis différents contextes pris en charge par WordPress.

C’est le MCP Adapter qui établit ensuite le pont avec les agents IA. Il permet d’exposer les capacités appropriées via le Model Context Protocol, afin qu’un client compatible puisse les découvrir puis les appeler.

Autrement dit, nous n’allons pas placer toute notre logique directement dans un « serveur IA ». Nous allons d’abord déclarer proprement une fonctionnalité WordPress, puis utiliser MCP comme couche d’exposition vers l’agent.

Cette distinction est essentielle pour comprendre l’architecture :

Plugin personnalisé → Ability WordPress → MCP Adapter → client MCP → agent IA

Elle permet également de mieux distinguer cette approche d’une extension WordPress classique. Pour approfondir ce point avant de poursuivre le développement, vous pouvez comprendre la différence conceptuelle entre un plugin classique et une exposition MCP.

Dans les sections suivantes, notre plugin va déclarer une Ability chargée de récupérer les derniers articles publiés. Nous l’exposerons ensuite via MCP afin qu’un agent comme Claude puisse la découvrir et l’exécuter.

Créer un snapshot LWS avant de commencer

Le développement d’un plugin MCP WordPress implique de modifier des fichiers PHP et d’enregistrer de nouvelles fonctionnalités dans WordPress. Une erreur de syntaxe ou une incompatibilité avec une version de l’API peut donc perturber le fonctionnement du site.

Avant de commencer, travaillez de préférence sur un environnement de staging plutôt que directement sur votre site en production. Avec WP Manager LWS, vous pouvez disposer d’un environnement adapté aux tests avant de déployer vos modifications.

Si votre site fonctionne sur un VPS, créez également un snapshot depuis le LWS Panel KVM avant vos essais. Vous pourrez ainsi revenir rapidement à un état fonctionnel de votre serveur en cas de problème. Sur un hébergement mutualisé, vérifiez que vos sauvegardes automatiques LWS sont disponibles et récentes.

Cette précaution est particulièrement importante ici : MCP Adapter et son API peuvent évoluer, et un code compatible avec une version donnée doit toujours être testé avant son déploiement en production.

Créer le squelette du plugin

Nous pouvons maintenant créer notre extension. Un plugin MCP WordPress reste avant tout un plugin WordPress classique : il possède son propre répertoire, un fichier PHP principal et un en-tête permettant au CMS de l’identifier.

Pour ce tutoriel, nous utiliserons une structure volontairement simple :

wp-content/
└── plugins/
    └── mon-plugin-mcp/
        └── mon-plugin-mcp.php

Cette structure minimale suffit pour comprendre le fonctionnement de l’Abilities API et du MCP Adapter. Sur un projet plus important, vous pourrez ensuite séparer les callbacks, les classes et la logique métier dans plusieurs fichiers.

L’objectif n’est pas encore de créer notre Ability. Nous allons d’abord nous assurer que WordPress reconnaît et charge correctement notre extension. Cette approche progressive facilite le débogage : si une erreur apparaît plus tard, nous saurons qu’elle provient de la déclaration des capacités plutôt que de la structure initiale du plugin.

1. Créer le fichier principal

Dans le répertoire wp-content/plugins/, créez un dossier nommé :

mon-plugin-mcp

À l’intérieur, créez le fichier mon-plugin-mcp.php.

Puis ajoutez le code suivant :

<?php
/**
 * Plugin Name: Mon Plugin MCP
 * Description: Expose des capacités personnalisées à des agents IA via MCP.
 * Version: 1.0.0
 * Author: Votre nom
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

L’en-tête placé au début du fichier permet à WordPress d’identifier le plugin et de l’afficher dans l’administration. Les champs Plugin Name, Description, Version et Author fournissent ici les informations essentielles.

La condition suivante constitue une protection élémentaire :

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

La constante ABSPATH est définie lorsque le fichier est chargé dans le contexte de WordPress. Si quelqu’un tente d’accéder directement au fichier PHP depuis son URL, le script arrête donc son exécution.

À ce stade, notre extension ne possède encore aucune fonctionnalité MCP. C’est normal : nous créons d’abord une base WordPress valide avant d’y enregistrer notre première Ability personnalisée.

2. Activer le plugin

Une fois le fichier enregistré sur votre serveur, connectez-vous au tableau de bord WordPress, puis rendez-vous dans la section « Extensions > Extensions installées ».

Vous devriez voir apparaître “Mon Plugin MCP” dans la liste. Cliquez sur le bouton « Activer ».

Si l’extension s’active normalement, notre squelette est fonctionnel. Si WordPress affiche une erreur PHP ou si le plugin n’apparaît pas, vérifiez en priorité le nom du fichier, son emplacement et la syntaxe de l’en-tête.

Pendant toute la phase de développement, il est également recommandé d’activer WP_DEBUG sur l’environnement de test. Cette précaution deviendra particulièrement utile dans la prochaine étape : certaines erreurs liées à l’Abilities API peuvent être difficiles à identifier sans le mode debug.

Le plugin est maintenant chargé par WordPress. Nous pouvons donc commencer à lui déclarer ses propres capacités.

Déclarer une catégorie (si nécessaire)

Chaque Ability WordPress appartient à une catégorie. Celle-ci permet d’organiser les capacités enregistrées et doit exister avant l’appel à wp_register_ability().

WordPress fournit notamment les catégories site et user. Pour notre Ability chargée de récupérer les articles récents, nous pourrions donc directement utiliser site.

Un plugin métier peut toutefois avoir intérêt à posséder sa propre catégorie. Pour en créer une, utilisez le hook wp_abilities_api_categories_init :

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category(
        'mon-plugin',
        [
            'label' => 'Mon Plugin',
        ]
    );
} );

Ici, mon-plugin correspond à l’identifiant technique de la catégorie tandis que Mon Plugin constitue son libellé lisible.

L’utilisation du hook approprié est importante : la catégorie doit être enregistrée au moment où l’Abilities API initialise ses catégories, avant que les Abilities qui en dépendent soient déclarées.

C’est l’une des raisons pour lesquelles il vaut mieux utiliser une catégorie native comme site lorsque vous n’avez pas réellement besoin d’une classification personnalisée.

Pour activer le débogage sur votre environnement de développement, vérifiez notamment la présence de cette constante dans wp-config.php :

define( 'WP_DEBUG', true );

Évitez en revanche d’afficher publiquement les erreurs PHP sur un site en production, car elles peuvent révéler des informations techniques sur votre installation.

Notre exemple principal utilisera la catégorie site, mais vous savez désormais comment créer mon-plugin si votre extension doit regrouper plusieurs Abilities personnalisées sous une catégorie dédiée.

Déclarer une première capacité (Ability)

Notre plugin est maintenant actif. Nous pouvons déclarer sa première Ability WordPress avec la fonction wp_register_ability().

Dans cet exemple, nous allons créer une capacité nommée mon-plugin/get-posts-recents. Son rôle sera simple : recevoir un nombre d’articles à récupérer, interroger WordPress puis retourner le titre et l’extrait de chaque publication.

Ajoutez le code suivant dans mon-plugin-mcp.php, après le code déjà présent :

add_action( 'wp_abilities_api_init', function () {

    wp_register_ability(
        'mon-plugin/get-posts-recents',
        [
            'label'       => 'Récupérer les articles récents',
            'description' => 'Retourne les N derniers articles publiés, avec leur titre et leur extrait.',
            'category'    => 'site',

            'input_schema' => [
                'type'       => 'object',
                'properties' => [
                    'nombre' => [
                        'type'        => 'integer',
                        'description' => 'Nombre d\'articles à retourner.',
                        'default'     => 5,
                    ],
                ],
            ],

            'execute_callback' => function ( $input ) {

                $nombre = isset( $input['nombre'] )
                    ? absint( $input['nombre'] )
                    : 5;

                $articles = get_posts(
                    [
                        'numberposts' => $nombre,
                        'post_status' => 'publish',
                    ]
                );

                return array_map(
                    function ( $article ) {
                        return [
                            'titre'   => $article->post_title,
                            'extrait' => get_the_excerpt( $article ),
                        ];
                    },
                    $articles
                );
            },

            'permission_callback' => function () {
                return current_user_can( 'edit_posts' );
            },
        ]
    );
} );

La première règle importante concerne le hook wp_abilities_api_init. L’appel à wp_register_ability() doit être effectué au moment prévu par l’Abilities API. Il ne faut donc pas placer directement cette fonction à la racine du plugin.

L’identifiant :

mon-plugin/get-posts-recents

utilise un format avec un namespace (mon-plugin) suivi du nom de la capacité (get-posts-recents). Un identifiant explicite réduit également les risques de conflit avec les Abilities enregistrées par d’autres extensions.

Examinons maintenant les principaux champs utilisés.

Comprendre input_schema

Le champ input_schema repose sur un schéma décrivant la structure des données attendues.

Notre Ability accepte ici un objet contenant la propriété nombre :

'input_schema' => [
    'type'       => 'object',
    'properties' => [
        'nombre' => [
            'type'        => 'integer',
            'description' => 'Nombre d\'articles à retourner.',
            'default'     => 5,
        ],
    ],
],

Cette déclaration indique que nombre doit être un entier et que sa valeur par défaut est 5.

Cette description structurée est essentielle pour une intégration avec un agent IA : le client peut comprendre quels paramètres transmettre à l’outil au lieu de devoir deviner le format attendu.

Comprendre execute_callback

execute_callback représente la logique métier de notre Ability.

Nous commençons par récupérer et sécuriser le nombre demandé :

$nombre = isset( $input['nombre'] )
    ? absint( $input['nombre'] )
    : 5;

Puis get_posts() interroge WordPress :

$articles = get_posts(
    [
        'numberposts' => $nombre,
        'post_status' => 'publish',
    ]
);

Enfin, array_map() transforme les objets retournés par WordPress en une structure simple contenant uniquement les informations utiles :

[
    'titre'   => $article->post_title,
    'extrait' => get_the_excerpt( $article ),
]

Une Ability n’est donc pas limitée à ce type de lecture. Son execute_callback peut appeler des fonctions WordPress, interroger une API externe ou déclencher une logique propre à votre application.

Comprendre permission_callback

Même si notre première Ability ne modifie aucune donnée, nous définissons également un contrôle d’accès :

'permission_callback' => function () {
    return current_user_can( 'edit_posts' );
},

Seuls les utilisateurs possédant la capacité WordPress edit_posts peuvent ainsi l’exécuter.

Ce contrôle deviendra encore plus important avec des Abilities capables de créer, modifier ou supprimer des données.

Il ne faut pas considérer permission_callback comme une simple formalité. Lorsqu’une fonctionnalité WordPress est accessible à travers MCP, l’autorisation doit toujours être vérifiée côté serveur, indépendamment de ce que demande ou décide l’agent IA.

Notre Ability est maintenant enregistrée dans WordPress. Il reste cependant une étape essentielle : décider si elle doit être accessible via MCP.

Exposer la capacité via MCP

Déclarer une Ability avec wp_register_ability() et la rendre disponible à un agent IA via MCP sont deux opérations distinctes.

Cette séparation est volontaire. Une capacité peut être utile à WordPress ou à d’autres interfaces sans devoir automatiquement être exposée à un client MCP externe.

Nous devons donc choisir quelles Abilities notre plugin MCP WordPress rend accessibles.

Deux stratégies sont particulièrement intéressantes :

• rendre explicitement une Ability accessible au serveur MCP par défaut ;
• créer un serveur MCP personnalisé qui n’expose qu’un ensemble déterminé d’Abilities.

La première solution est la plus simple pour découvrir l’architecture et tester rapidement notre extension. La seconde offre davantage de contrôle lorsque le plugin possède plusieurs fonctionnalités ou lorsqu’un projet nécessite une surface MCP précisément délimitée.

Dans les deux cas, le principe de sécurité reste le même : n’exposez que les capacités réellement nécessaires et conservez des contrôles d’autorisation adaptés dans chaque Ability.

1. Exposition sur le serveur MCP par défaut

Pour rendre notre capacité disponible via le MCP Adapter, nous pouvons ajouter des métadonnées MCP à sa déclaration.

Dans wp_register_ability(), ajoutez :

'meta' => [
    'mcp' => [
        'public' => true,
    ],
],

La déclaration contient alors notamment :

wp_register_ability(
    'mon-plugin/get-posts-recents',
    [
        'label'       => 'Récupérer les articles récents',
        'description' => 'Retourne les N derniers articles publiés, avec leur titre et leur extrait.',
        'category'    => 'site',

        // input_schema, callbacks...

        'meta' => [
            'mcp' => [
                'public' => true,
            ],
        ],
    ]
);

La métadonnée mcp.public indique que cette Ability peut être rendue accessible par le mécanisme MCP concerné. Elle permet ainsi de contrôler l’exposition MCP indépendamment de l’enregistrement général de la capacité.

Le serveur MCP par défaut fourni par l’adaptateur est accessible via l’API REST WordPress à l’endpoint :

/wp-json/mcp/mcp-adapter-default-server

Sur un site utilisant HTTPS, l’adresse prend donc une forme comparable à :

https://exemple.fr/wp-json/mcp/mcp-adapter-default-server

Le serveur par défaut du MCP Adapter s’appuie sur un mécanisme permettant au client MCP de découvrir les Abilities disponibles, d’obtenir leurs informations puis de les exécuter. Cette architecture évite notamment de devoir construire manuellement un outil MCP indépendant pour chaque fonctionnalité WordPress.

Si votre capacité est correctement enregistrée dans WordPress mais reste introuvable côté MCP, contrôlez en priorité meta.mcp.public, les permissions et les éventuelles erreurs visibles avec WP_DEBUG.

Pour un premier développement, le serveur par défaut constitue une bonne solution. Mais un plugin contenant plusieurs Abilities peut nécessiter un contrôle plus strict sur celles qui sont proposées aux clients MCP.

2. Exposition via un serveur MCP personnalisé (contrôle plus fin)

Un serveur MCP personnalisé permet de définir explicitement quelles Abilities doivent être exposées. Cette approche est particulièrement utile lorsque votre plugin possède plusieurs capacités internes, mais que vous souhaitez n’en rendre accessibles que certaines à un agent IA.

Le MCP Adapter permet de créer un serveur après son initialisation. Le principe consiste à utiliser le hook mcp_adapter_init, puis à déclarer le serveur avec create_server().

La structure d’une implémentation peut prendre cette forme :

add_action( 'mcp_adapter_init', function ( $adapter ) {

    $adapter->create_server(
        'mon-plugin-mcp-server',
        'mcp',
        'mon-plugin',
        'Mon Plugin MCP Server',
        'Serveur MCP exposant les capacités de Mon Plugin.',
        '1.0.0',
        [
            \WP\MCP\Transport\HttpTransport::class,
        ],
        \WP\MCP\Infrastructure\ErrorHandling\ErrorLogMcpErrorHandler::class,
        \WP\MCP\Infrastructure\Observability\NullMcpObservabilityHandler::class,
        [
            'mon-plugin/get-posts-recents',
        ],
        [],
        []
    );
} );

Dans cet exemple, la liste :

[
    'mon-plugin/get-posts-recents',
]

permet d’indiquer explicitement l’Ability à exposer sur ce serveur.

Cette approche devient intéressante si votre plugin déclare, par exemple :

mon-plugin/get-posts-recents
mon-plugin/get-statistiques
mon-plugin/create-post
mon-plugin/delete-post

Vous pourriez décider de créer un serveur qui expose uniquement :

mon-plugin/get-posts-recents
mon-plugin/get-statistiques

Les capacités d’écriture ou de suppression resteraient alors hors de cette surface MCP.

Le serveur personnalisé apporte ainsi une séparation plus fine des responsabilités. Vous contrôlez non seulement les permissions dans chaque Ability, mais aussi les capacités effectivement présentées par un serveur donné.

Il est toutefois important de ne pas confondre ces deux mécanismes de sécurité. Limiter la liste des Abilities exposées ne remplace jamais permission_callback.

Le serveur détermine ce qui est proposé via MCP ; permission_callback détermine si l’utilisateur authentifié a réellement le droit d’exécuter l’action.

Cette distinction devient fondamentale pour les capacités sensibles :

Agent IA
   ↓
Serveur MCP personnalisé
   ↓
Ability autorisée sur ce serveur
   ↓
permission_callback
   ↓
execute_callback

Vous pouvez ainsi concevoir plusieurs serveurs destinés à des usages différents, chacun avec un périmètre d’Abilities contrôlé.

Pour notre tutoriel, le serveur MCP par défaut suffit pour tester l’Ability mon-plugin/get-posts-recents. La création d’un serveur personnalisé constitue surtout une solution à retenir lorsque votre intégration MCP gagne en complexité et nécessite une exposition beaucoup plus sélective.

Tester le plugin depuis Claude Desktop

Notre plugin MCP WordPress déclare maintenant une Ability et l’autorise à être exposée via MCP. Il reste à vérifier qu’un véritable client MCP est capable de la découvrir et de l’exécuter.

Nous utiliserons Claude Desktop pour ce test. Pour un site WordPress distant, le MCP Adapter peut être utilisé avec le proxy @automattic/mcp-wordpress-remote, qui fait le lien entre le client et l’endpoint HTTP de WordPress.

Créer un mot de passe d’application WordPress

Pour authentifier la connexion, évitez d’utiliser directement le mot de passe principal de votre compte WordPress.

Depuis l’administration, rendez-vous dans la section « Utilisateurs > Profil », puis recherchez la section consacrée aux mots de passe d’application.

Créez-en un spécifiquement destiné à votre connexion MCP, par exemple :

Claude Desktop MCP

Copiez immédiatement le mot de passe généré et conservez-le dans un emplacement sécurisé.

Configurer Claude Desktop

Dans Claude Desktop, ouvrez les paramètres destinés aux développeurs, puis accédez à la configuration des serveurs MCP locaux.

La configuration peut utiliser @automattic/mcp-wordpress-remote. Adaptez l’exemple suivant à votre installation :

{
  "mcpServers": {
    "wordpress-lws": {
      "command": "npx",
      "args": [
        "-y",
        "@automattic/mcp-wordpress-remote@latest"
      ],
      "env": {
        "WP_API_URL": "https://exemple.fr/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "votre-utilisateur",
        "WP_API_PASSWORD": "votre-mot-de-passe-application"
      }
    }
  }
}

Remplacez évidemment exemple.fr, votre-utilisateur et votre-mot-de-passe-application par les informations de votre environnement.

Cette méthode nécessite également Node.js, puisque la commande utilise npx.

Après avoir enregistré le fichier de configuration, redémarrez Claude Desktop afin que le serveur MCP soit chargé.

Demander à Claude d’utiliser l’Ability

Ouvrez ensuite une nouvelle conversation et formulez une demande correspondant clairement à la description de notre capacité. Par exemple :

Peux-tu me donner mes 3 derniers articles publiés ?

Le client MCP peut alors découvrir les outils proposés par le serveur WordPress. Le serveur par défaut du MCP Adapter utilise notamment des mécanismes permettant de découvrir les Abilities, d’obtenir leurs informations et de demander leur exécution.

Notre description :

Retourne les N derniers articles publiés, avec leur titre et leur extrait.

a donc une réelle importance. Elle aide le système à comprendre dans quel contexte mon-plugin/get-posts-recents est pertinente.

Lors de l’exécution, la valeur 3 est transmise au paramètre nombre. WordPress exécute ensuite notre execute_callback, sous réserve que le permission_callback autorise l’utilisateur authentifié.

Le résultat retourné peut alors être exploité dans la conversation.

Si Claude voit le serveur mais pas votre Ability, vérifiez successivement son enregistrement, son exposition MCP, les droits de l’utilisateur et les logs WordPress.

Le transport HTTP actuel utilise également un mécanisme de session MCP : le client initialise la connexion, récupère un identifiant de session puis le transmet lors des requêtes suivantes. Lorsque vous utilisez le proxy officiel, cette mécanique technique est prise en charge par la couche de connexion.

Aller plus loin : capacités d’écriture

Jusqu’ici, notre Ability ne fait que lire des données WordPress. Le même principe peut toutefois être appliqué à une action d’écriture : créer un article, changer un statut, mettre à jour un champ personnalisé ou déclencher une opération métier.

Dans ce cas, la sécurité doit être renforcée.

Prenons l’exemple d’une capacité permettant de créer un brouillon. Son contrôle d’autorisation pourrait notamment vérifier :

'permission_callback' => function () {
    return current_user_can( 'edit_posts' );
},

Pour une opération nécessitant des droits plus élevés, utilisez la capability WordPress réellement adaptée plutôt qu’un contrôle générique.

L’objectif est simple : l’agent IA ne doit jamais pouvoir contourner le système d’autorisations WordPress.

Décrire précisément les effets de l’action

La description mérite encore plus d’attention pour une Ability d’écriture.

Évitez une description trop vague comme :

Gère un article WordPress.

Préférez une formulation explicite :

Crée un nouvel article WordPress au statut brouillon. Cette action ajoute un contenu dans la base de données mais ne le publie pas.

L’agent dispose alors d’une description beaucoup plus précise de l’opération et de ses effets de bord.

Une bonne pratique consiste également à créer des Abilities limitées à une tâche. Par exemple :

mon-plugin/create-draft
mon-plugin/update-post-title
mon-plugin/change-post-status

est préférable à une seule capacité :

mon-plugin/manage-everything

Vous simplifiez ainsi les paramètres, les permissions et le raisonnement nécessaire pour déterminer l’action appropriée.

Cette architecture devient particulièrement intéressante avec WooCommerce. Un plugin métier pourrait déclarer des Abilities distinctes pour consulter une commande, mettre à jour certaines informations ou interagir avec un catalogue.

Dans tous les cas, une Ability qui modifie des données doit conserver un permission_callback explicite. L’exposition MCP et le contrôle des permissions sont deux protections complémentaires, pas interchangeables.

Pour les actions les plus sensibles, envisagez également un mécanisme de validation métier supplémentaire avant toute modification irréversible.

Vérification du bon fonctionnement

Avant de considérer votre plugin MCP WordPress comme terminé, effectuez une série de contrôles sur votre environnement de test.

• Activation du plugin : l’extension doit pouvoir être activée sans erreur PHP.
• Débogage : avec WP_DEBUG activé, aucune notice liée à une catégorie inexistante ou à un mauvais usage de l’Abilities API ne doit apparaître.
• Enregistrement : mon-plugin/get-posts-recents doit être correctement enregistré dans WordPress.
• Exposition MCP : l’Ability doit pouvoir être découverte par le serveur MCP prévu à cet effet.
• Connexion du client : Claude Desktop doit parvenir à communiquer avec votre serveur WordPress.
• Exécution : une demande portant sur les derniers articles doit déclencher l’Ability et retourner les données attendues.
• Permissions : un utilisateur ne possédant pas les droits requis doit se voir refuser l’exécution.

Ce dernier test est particulièrement important. Une Ability qui fonctionne avec un administrateur ne prouve pas que votre contrôle d’accès est correctement configuré.

Créez ou utilisez donc un compte disposant de permissions plus limitées et reproduisez le test. Le résultat attendu dépend du permission_callback défini pour votre capacité.

Effectuez ces vérifications sur le staging avant tout déploiement en production.

Erreurs fréquentes et cas de blocage

Le développement d’un plugin MCP WordPress fait intervenir plusieurs couches : chargement du plugin, Abilities API, permissions, MCP Adapter, authentification et client MCP. Lorsqu’une fonctionnalité n’apparaît pas, il est donc préférable de procéder méthodiquement.

L’Ability n’apparaît pas : vérifier d’abord la catégorie

C’est un cas particulièrement trompeur. Si vous utilisez :

'category' => 'ma-categorie',

sans avoir enregistré ma-categorie, ne partez pas immédiatement à la recherche d’un problème dans Claude Desktop ou dans le MCP Adapter.

Commencez par vérifier l’Abilities API.

En développement, WP_DEBUG vous aide à repérer les notices _doing_it_wrong() qui seraient autrement faciles à manquer.

L’Ability existe, mais Claude ne la trouve pas

Dans ce cas, séparez le diagnostic en deux étapes.

Vérifiez d’abord que l’Ability est correctement enregistrée dans WordPress. Vérifiez ensuite qu’elle est effectivement exposée via MCP.

Pour le serveur par défaut, contrôlez notamment les métadonnées d’exposition. Pour un serveur personnalisé, vérifiez que l’identifiant exact de l’Ability figure bien dans la configuration.

Cette méthode permet d’éviter de modifier le code métier alors que le problème se situe uniquement dans la couche MCP.

Le serveur répond avec une erreur d’authentification

L’endpoint MCP HTTP nécessite un contexte utilisateur WordPress authentifié. Avec la configuration distante présentée dans ce tutoriel, vérifiez donc le nom d’utilisateur et le mot de passe d’application.

N’utilisez pas votre mot de passe WordPress habituel dans le fichier de configuration.

Si vous révoquez le mot de passe d’application depuis WordPress, pensez également à remplacer les identifiants utilisés par le client MCP.

Enfin, gardez une règle simple pendant vos recherches d’erreurs :

WordPress → Ability → exposition MCP → authentification → client MCP.

Testez les couches dans cet ordre. Vous identifierez beaucoup plus rapidement l’origine du blocage qu’en modifiant simultanément le plugin et la configuration de Claude Desktop.

Bonnes pratiques

Un plugin MCP WordPress fonctionnel n’est pas nécessairement prêt à être déployé en production. Avant d’exposer vos Abilities à un agent IA, plusieurs bonnes pratiques permettent de rendre l’intégration plus fiable et plus facile à maintenir.

Commencez par tester chaque nouvelle Ability sur un environnement de staging. Vous pourrez vérifier son comportement, consulter les logs PHP et corriger les erreurs sans affecter les utilisateurs du site. Pendant cette phase, activez WP_DEBUG, notamment pour identifier les problèmes d’enregistrement de catégories ou d’Abilities.

Accordez également une attention particulière aux label et description. Ces informations ne servent pas uniquement aux développeurs : elles permettent au système consommant l’Ability de comprendre sa finalité. Une description précise doit indiquer clairement l’action réalisée et, pour une capacité d’écriture, ses éventuels effets de bord.

Privilégiez ensuite des Abilities spécialisées. Une capacité create-draft ou get-recent-posts est plus prévisible qu’une capacité générique chargée de gérer plusieurs opérations différentes.

Enfin, appliquez systématiquement le principe du moindre privilège. Le permission_callback doit correspondre aux droits réellement nécessaires à l’action. Évitez d’exiger un rôle administrateur lorsqu’une capability WordPress plus précise suffit.

Gardez également à l’esprit que l’écosystème MCP de WordPress continue d’évoluer. Avant une mise à jour du MCP Adapter ou de WordPress, consultez la documentation de la version concernée et testez votre plugin sur le staging avant de mettre à jour l’environnement de production.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

FAQ

Faut-il coder pour créer un plugin MCP WordPress, ou existe-t-il des solutions sans code ?

Le développement d’un plugin MCP WordPress personnalisé nécessite des connaissances en PHP lorsque vous souhaitez créer vos propres Abilities et y intégrer une logique métier spécifique.

Il n’est cependant pas obligatoire de développer une extension pour simplement commencer à utiliser MCP avec WordPress. Des solutions existantes permettent d’exploiter les capacités disponibles sans écrire son propre plugin.

Si votre objectif est avant tout de connecter un agent IA à votre site plutôt que de développer de nouvelles fonctionnalités, consultez le tutoriel LWS pour découvrir MCP WordPress sans écrire de code, pour un usage no-code.

Les deux approches répondent donc à des besoins différents : une solution existante convient à l’utilisation de capacités déjà disponibles, tandis que le développement présenté ici permet d’exposer vos propres fonctionnalités métier.

Qu’est-ce que l’Abilities API et quel est son rapport avec MCP ?

L’Abilities API fournit à WordPress un mécanisme standardisé permettant aux composants du CMS de déclarer des fonctionnalités, appelées Abilities.

Une Ability décrit notamment son rôle, les données qu’elle accepte, la logique PHP à exécuter et les conditions nécessaires pour autoriser cette exécution.

L’Abilities API n’est donc pas exclusivement une technologie destinée à l’intelligence artificielle. MCP constitue une couche d’exposition supplémentaire : le MCP Adapter peut rendre certaines Abilities disponibles à des clients compatibles avec le Model Context Protocol.

L’architecture peut être résumée ainsi :

Plugin WordPress
      ↓
Abilities API
      ↓
MCP Adapter
      ↓
Client MCP
      ↓
Agent IA

Cette séparation permet de conserver la logique métier dans WordPress tout en choisissant précisément les fonctionnalités pouvant être utilisées par un agent externe.

Pourquoi ma capacité personnalisée n’apparaît-elle pas après l’enregistrement ?

Commencez par vérifier la catégorie de l’Ability. Si wp_register_ability() référence une catégorie qui n’est pas enregistrée, la capacité peut ne pas être enregistrée correctement.

Vérifiez également que l’appel à wp_register_ability() intervient bien depuis le hook :

wp_abilities_api_init

Pendant le développement, activez WP_DEBUG afin de détecter les notices qui permettent d’identifier plus facilement une utilisation incorrecte de l’API.

Si l’Ability existe bien dans WordPress mais reste invisible côté MCP, le problème se situe probablement dans la couche suivante. Vérifiez son exposition MCP, notamment meta.mcp.public lorsque cette méthode est utilisée, ou assurez-vous que son identifiant figure dans la liste des Abilities de votre serveur MCP personnalisé.

Procédez toujours dans cet ordre : enregistrement WordPress d’abord, exposition MCP ensuite.

Peut-on connecter Claude Desktop à un plugin MCP WordPress personnalisé ?

Oui. Claude Desktop peut utiliser un serveur compatible avec le Model Context Protocol et donc interagir avec les fonctionnalités WordPress rendues accessibles par le MCP Adapter.

Dans le cas présenté dans ce tutoriel, le client utilise une couche de connexion vers l’endpoint HTTP du serveur MCP WordPress. L’utilisateur est authentifié côté WordPress et les Abilities accessibles peuvent ensuite être découvertes et exécutées en fonction des permissions accordées.

La connexion MCP ne supprime cependant jamais les contrôles d’accès de WordPress. Une Ability protégée par :

'permission_callback' => function () {
    return current_user_can( 'edit_posts' );
},

reste soumise à cette vérification lorsque Claude demande son exécution.

Il est donc recommandé d’utiliser un compte WordPress dédié, disposant uniquement des permissions nécessaires aux actions prévues.

L’Abilities API sera-t-elle intégrée au cœur de WordPress ?

L’Abilities API PHP est intégrée au cœur de WordPress depuis WordPress 6.9. Il ne faut donc plus la présenter comme une API dont l’intégration au core serait seulement prévue pour une version future.

L’écosystème continue néanmoins d’évoluer. WordPress 7.0 a notamment étendu cette architecture avec des fonctionnalités JavaScript liées aux Abilities, tandis que le MCP Adapter poursuit lui aussi son développement.

Cette distinction est importante : l’existence de l’Abilities API dans WordPress Core ne signifie pas que toutes les briques entourant MCP sont désormais figées.

Si vous développez une intégration destinée à la production, vérifiez donc toujours la documentation correspondant à votre version de WordPress et du MCP Adapter avant de reprendre un exemple de code. Une évolution de l’adaptateur peut modifier certains détails d’implémentation sans remettre en cause le principe général des Abilities.

Conclusion

Créer son propre plugin MCP WordPress permet d’aller bien plus loin que l’installation d’une intégration prête à l’emploi. Grâce à l’Abilities API, vous pouvez déclarer précisément les fonctionnalités propres à votre site, puis utiliser le MCP Adapter pour les rendre accessibles à des agents IA compatibles.🦉 Vous disposez désormais des bases nécessaires pour enregistrer une Ability avec wp_register_ability(), définir ses paramètres, protéger son exécution avec permission_callback et contrôler son exposition via MCP.💥 La même architecture peut ensuite servir à construire des intégrations beaucoup plus avancées, de la gestion de contenus aux outils métier connectés à WordPress.

Pour développer et tester ces intégrations dans un environnement disposant d’un accès complet au serveur, vous pouvez découvrir les VPS KVM LWS pour développer vos intégrations IA WordPress, avec accès root, snapshots et outils adaptés au débogage.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Vous avez testé ou développé votre propre plugin MCP WordPress ? Partagez votre expérience, vos questions ou vos astuces dans les commentaires !