# Un badge « compatible MCP Adapter » sur la fiche d’une extension interne

> Aider une équipe à repérer d'un coup d'œil quelles extensions maison sont prêtes pour l'écosystème MCP de WordPress 7.0.

- Auteur : Clément Hadrot
- Publié le : 2026-04-11
- Mis à jour le : 2026-04-11
- Catégorie : Tips
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tips/badge-compatible-mcp-adapter-extension-interne/

## L’essentiel

- Un attribut de compatibilité déclaré par extension
- Un badge visible sur l'écran des extensions
- Une liste filtrable pour l'équipe technique

Décembre 2025 a marqué l'arrivée de l'Abilities API dans le cœur de WordPress avec la version 6.9, suivie de près par le MCP Adapter permettant d'exposer ces capacités à des agents externes via le Model Context Protocol. Quelques mois plus tard, avec l'approche de WordPress 7.0, la question devient très concrète pour une agence disposant d'un parc d'extensions maison : lesquelles ont déjà été adaptées, et lesquelles restent à auditer ?

Plutôt que de tenir cette information dans un tableur externe, vite désynchronisé du code réel, il est plus fiable de la déclarer directement dans l'en-tête de chaque extension et de l'afficher sous forme de badge sur l'écran natif des extensions.

## Déclarer la compatibilité dans l'en-tête de l'extension

WordPress permet d'ajouter des champs personnalisés dans le commentaire d'en-tête d'un plugin, au même titre que `Plugin Name` ou `Version`. On y ajoute un champ `MCP Adapter` qui prend la valeur `compatible`, `partiel` ou `non-teste` :

```
/**
 * Plugin Name: Gestion des rendez-vous internes
 * Description: Extension maison de gestion de créneaux.
 * Version: 2.4.0
 * MCP Adapter: compatible
 */
```

## Lire cette information et l'afficher en badge

> L'essentiel à retenir : Un attribut de compatibilité déclaré par extension ; Un badge visible sur l'écran des extensions ; Une liste filtrable pour l'équipe technique

La fonction `get_plugin_data` ne remonte pas nativement les en-têtes personnalisés : il faut les lire soi-même via `get_file_data`, puis injecter le badge sur la ligne correspondante de l'écran des extensions grâce au hook `plugin_row_meta` :

```
add_filter( 'plugin_row_meta', 'ajouter_badge_mcp_adapter', 10, 2 );
function ajouter_badge_mcp_adapter( $meta, $plugin_file ) {
    $chemin_complet = WP_PLUGIN_DIR . '/' . $plugin_file;
    $donnees = get_file_data( $chemin_complet, array( 'mcp' => 'MCP Adapter' ) );

    $statuts = array(
        'compatible'  => '<span style="color:green;">✓ Compatible MCP Adapter</span>',
        'partiel'     => '<span style="color:orange;">⚠ Compatibilité partielle</span>',
        'non-teste'   => '<span style="color:gray;">— Non testé</span>',
    );

    if ( ! empty( $donnees['mcp'] ) && isset( $statuts[ $donnees['mcp'] ] ) ) {
        $meta[] = $statuts[ $donnees['mcp'] ];
    }

    return $meta;
}
```

### Pourquoi trois niveaux plutôt qu'un simple oui/non

Une extension peut exposer certaines capacités via l'Abilities API sans que l'ensemble de ses fonctionnalités soit couvert. Le niveau « partiel » évite de donner une fausse impression de complétude à une équipe qui déciderait de connecter un agent externe en se fiant uniquement à un badge binaire.

## Construire une liste filtrable pour l'équipe technique

Sur un parc de trente extensions, parcourir l'écran natif reste praticable, mais une page d'administration dédiée, listant chaque extension avec son statut et sa date de dernier audit, facilite le suivi dans le temps :

- Extensions compatibles : aucune action requise
- Extensions partielles : ticket d'audit à planifier
- Extensions non testées : priorité selon leur usage réel en production

## Ne pas confondre ce badge avec la déclaration de l'ability elle-même

Ce dispositif se limite à un indicateur de suivi côté gouvernance ; il ne remplace pas le travail d'implémentation consistant à enregistrer réellement les capacités de l'extension via `wp_register_ability`, sujet qui relève d'un tout autre chantier technique, propre à chaque extension.

> Un badge de compatibilité n'a de valeur que s'il est mis à jour à chaque changement de version de l'extension concernée ; sinon, il devient plus trompeur qu'utile.

## Automatiser la vérification lors des mises à jour

Un contrôle automatisé, exécuté dans le pipeline de déploiement interne, peut vérifier que le champ `MCP Adapter` est bien présent dans l'en-tête avant d'autoriser la publication d'une nouvelle version de l'extension sur le dépôt privé de l'agence, évitant qu'un badge obsolète subsiste après une refonte majeure.

## En résumé

Un simple champ d'en-tête et un filtre sur `plugin_row_meta` suffisent à rendre visible, en quelques minutes de développement, un état de compatibilité qui autrement resterait dispersé entre mémoires individuelles et documents externes. Sur un parc d'extensions conséquent, ce badge devient rapidement un outil de pilotage aussi utile que le numéro de version affiché à côté.