Décembre 2025 : WordPress 6.9 introduit l’Abilities API, qui permet à une extension de déclarer des capacités interrogeables par des systèmes externes. Cinq mois plus tard, WordPress 7.0 fait un pas de plus en intégrant nativement l’Adaptateur MCP (Model Context Protocol) au cœur, alors qu’il n’existait jusque-là que sous forme de plugin de fonctionnalité distinct.
Pour une extension qui exposait déjà des capacités via l’Abilities API et s’appuyait sur le plugin MCP Adapter en 2025, la question posée par un client est simple : le passage à WordPress 7.0 va-t-il casser quelque chose ? La réponse tient en un mot : ça dépend du point d’entrée utilisé, pas du contrat de capacités lui-même.
Ce qui ne change pas
L’Abilities API elle-même reste stable entre les deux versions. Une capacité déclarée avec wp_register_ability(), assortie d’un schéma d’entrée et de sortie au format JSON Schema et d’une fonction de vérification des permissions, continue de fonctionner à l’identique. Le contrat que respecte une extension bien conçue — déclarer, vérifier les permissions, exécuter, retourner une réponse structurée — n’est pas remis en cause par l’intégration native de l’adaptateur.
Les tests PHPUnit qui valident directement l’enregistrement et l’exécution d’une capacité, sans passer par le protocole MCP, restent donc valables sans modification :
public function test_ability_retourne_le_schema_attendu(): void
{
$ability = wp_get_ability('mon-plugin/creer-rendez-vous');
$this->assertNotNull($ability);
$this->assertSame('object', $ability->get_input_schema()['type']);
}
Ce qui change : le point d’entrée du protocole
Le changement majeur concerne la façon dont un agent MCP externe découvre et appelle ces capacités. En 2025, le plugin de fonctionnalité MCP Adapter exposait un point de terminaison REST spécifique, activé et configuré séparément du cœur. Avec WordPress 7.0, ce point de terminaison devient une route native, disponible sans installation supplémentaire, avec ses propres réglages par défaut en matière d’authentification et de journalisation.
C’est précisément cette bascule qu’il faut tester en priorité, car une extension qui codait en dur l’ancien chemin du plugin de fonctionnalité, ou qui vérifiait la présence de la classe du plugin avant d’activer certaines options, doit être rejouée contre le nouveau point d’entrée natif :
public function test_extension_repond_via_adaptateur_natif(): void
{
$requete = new WP_REST_Request('POST', '/wp/v2/mcp/tools/call');
$requete->set_body_params([
'name' => 'mon-plugin/creer-rendez-vous',
'arguments' => ['praticien_id' => 12, 'date' => '2026-06-01'],
]);
$reponse = rest_do_request($requete);
$this->assertSame(200, $reponse->get_status());
}
Impact fort : la gestion des permissions par défaut
L’intégration native modifie aussi le comportement par défaut de la vérification des permissions. Le plugin de fonctionnalité de 2025 exigeait une configuration explicite du champ d’application (scope) pour chaque capacité exposée à un agent externe. WordPress 7.0 applique un comportement plus restrictif par défaut : une capacité qui ne déclare pas explicitement son niveau d’exposition n’est tout simplement pas listée dans la découverte MCP.
Concrètement, cela veut dire qu’une extension qui fonctionnait en 2025 grâce à une configuration manuelle du plugin peut devenir invisible pour un agent après la mise à jour, sans qu’aucune erreur ne remonte : la capacité existe, mais n’est plus découvrable. Un test de découverte, qui interroge la liste des capacités exposées et vérifie la présence de celles attendues, est donc indispensable avant toute mise en production :
- Lister les capacités retournées par le point de découverte natif
- Comparer cette liste à celle obtenue avec l’ancien plugin de fonctionnalité
- Vérifier explicitement la présence de chaque capacité métier critique
Impact modéré : le format des erreurs de refus
Autre différence à couvrir : le format de la réponse quand une capacité est appelée hors des permissions déclarées. Le plugin de fonctionnalité renvoyait un code d’erreur générique, tandis que l’implémentation native de WordPress 7.0 structure le refus avec un code d’erreur spécifique au protocole MCP, plus facilement exploitable côté agent.
public function test_refus_hors_permission_bien_structure(): void
{
wp_set_current_user(0); // utilisateur non authentifié
$requete = new WP_REST_Request('POST', '/wp/v2/mcp/tools/call');
$requete->set_body_params(['name' => 'mon-plugin/creer-rendez-vous']);
$reponse = rest_do_request($requete);
$this->assertSame(403, $reponse->get_status());
$this->assertSame('mcp_permission_denied', $reponse->get_data()['code']);
}
Rejouer la même suite de tests contre l’ancien plugin de fonctionnalité et contre le cœur natif, plutôt que de migrer directement, permet de dater précisément le comportement qui a changé.
Nouveautés classées par impact
Pour prioriser les vérifications avant une mise à jour de parc, l’ordre suivant reflète l’expérience du projet mené fin avril 2026 :
- Impact fort : découverte des capacités et permissions par défaut, à revalider intégralement
- Impact modéré : format des réponses d’erreur, à adapter si l’extension les interprète explicitement
- Impact faible : chemin du point de terminaison REST, généralement transparent grâce à la couche de compatibilité
En résumé
Le passage au MCP Adapter natif de WordPress 7.0 ne casse pas le contrat des capacités déclarées via l’Abilities API, mais change suffisamment leur exposition par défaut pour justifier une suite de tests dédiée à la découverte et aux permissions. Sur ce projet, deux capacités sur cinq sont devenues invisibles après la mise à jour, faute de déclaration explicite de leur champ d’application — un correctif de quelques lignes une fois le problème identifié par les tests.
