« Le MCP Adapter fournit un pont standardisé entre les capacités déclarées via l’Abilities API et les clients compatibles au protocole MCP » — c’est en substance ce qu’annonçait la note de version de WordPress 6.9 en décembre 2025, à l’époque encore sous forme de fonctionnalité activable via un plugin officiel de transition. Avec WordPress 7.0, cette fonctionnalité entre directement dans le cœur, sans plugin à installer.
Pour une extension qui avait anticipé le mouvement dès 2025 en déclarant ses capacités métier via l’Abilities API, la question n’est pas de tout reprendre : c’est de vérifier ce qui, dans le passage au cœur, casse silencieusement une intégration qui fonctionnait très bien la veille.
Le plugin de transition disparaît
Le plugin mcp-adapter distribué séparément pendant la phase de stabilisation de WordPress 6.9 gérait lui-même l’enregistrement du serveur MCP et ses réglages, stockés dans ses propres options. Avec l’internalisation dans WordPress 7.0, ces réglages ne sont pas repris automatiquement : le cœur initialise sa propre structure d’options avec des valeurs par défaut, distinctes du plugin.
Concrètement, une extension qui vérifiait la présence du plugin via is_plugin_active( 'mcp-adapter/mcp-adapter.php' ) pour activer sa propre passerelle doit désormais tester la présence de la fonctionnalité native du cœur :
if ( function_exists( 'wp_mcp_adapter_is_available' ) ) {
// Le cœur expose nativement le MCP Adapter (WordPress 7.0+)
add_action( 'wp_mcp_adapter_init', 'mon_extension_enregistrer_capacites' );
} elseif ( is_plugin_active( 'mcp-adapter/mcp-adapter.php' ) ) {
// Compatibilité descendante avec le plugin de transition (6.9)
add_action( 'mcp_adapter_init', 'mon_extension_enregistrer_capacites' );
}
Le point d’entrée change de chemin
Le plugin de transition exposait le serveur MCP sur un point d’entrée REST sous /wp-json/mcp-adapter/v1. La version intégrée au cœur de WordPress 7.0 le déplace sous un espace de noms natif, cohérent avec le reste de l’API REST du cœur. Toute extension qui avait codé en dur l’ancien chemin — par exemple dans une documentation d’intégration destinée à un assistant conversationnel externe — doit republier cette documentation avec le nouveau point d’entrée, sous peine de rediriger l’agent externe vers une route qui n’existe plus.
- Vérifier toute URL codée en dur pointant vers l’ancien espace de noms REST.
- Republier les manifestes de découverte destinés aux clients MCP externes.
- Tester la découverte des capacités depuis un client MCP à jour, pas seulement l’appel direct.
Les capacités déjà déclarées restent valides
Bonne nouvelle pour qui a suivi la voie recommandée dès 2025 : une capacité enregistrée via wp_register_ability() avec un identifiant, une description, un schéma d’entrée et un rappel d’exécution reste inchangée dans sa syntaxe. L’Abilities API elle-même n’a pas bougé entre WordPress 6.9 et 7.0 ; seul le mécanisme qui l’expose à un client externe via MCP a changé de support technique, du plugin vers le cœur.
Un point de vigilance sur les permissions par défaut
Le cœur applique désormais une politique de permission par défaut plus stricte que celle du plugin de transition, qui autorisait par défaut tout utilisateur disposant de la capacité manage_options à invoquer n’importe quelle capacité exposée. WordPress 7.0 exige une déclaration explicite du niveau de permission requis pour chaque capacité, via l’argument permission_callback lors de l’enregistrement. Sans cette déclaration explicite, la capacité reste enregistrée mais inaccessible depuis un client MCP, ce qui se traduit par un échec silencieux plutôt qu’une erreur claire.
Une capacité qui répond « accès refusé » à un client MCP n’est presque jamais un bug du protocole : c’est un argument de permission oublié lors de la migration du plugin vers le cœur.
Ce que cette version ne remet pas en cause
La conception même de l’Abilities API — décrire une capacité métier de façon standardisée, indépendamment du protocole qui l’exposera — ne change pas avec WordPress 7.0. Le MCP Adapter reste une couche de transport, pas une redéfinition de ce qu’est une capacité. Une extension qui avait bien séparé la déclaration de ses capacités de leur exposition n’a, en pratique, que deux ou trois lignes à ajuster.
En résumé
Le passage du MCP Adapter en plugin à composant natif du cœur dans WordPress 7.0 déplace le point d’entrée REST, retire les anciens réglages du plugin de transition et impose une déclaration explicite des permissions par capacité. Pour une extension déjà alignée sur les Abilities API depuis 2025, la mise à jour se limite à ces trois vérifications, sans reprise de la logique métier elle-même.
