# Une Ability WordPress mal décrite égare un agent IA sur le mauvais outil

> Exposées via le MCP Adapter, deux Abilities WordPress aux descriptions trop proches ont conduit un agent à modifier un événement au lieu de le publier. Diagnostic pour développeurs.

- Auteur : Clément Hadrot
- Publié le : 2026-01-23
- Mis à jour le : 2026-01-23
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/ability-wordpress-mal-decrite-egare-agent-mcp-adapter/

## L’essentiel

- Deux Abilities aux noms proches et aux descriptions génériques se confondent facilement pour un agent
- Le MCP Adapter transmet fidèlement le schéma déclaré, il ne corrige aucune ambiguïté
- Renommer et enrichir les descriptions a suffi, sans toucher au code des callbacks

Sur un site associatif exposant son calendrier d'événements à un agent conversationnel via le MCP Adapter de WordPress, deux Abilities enregistrées séparément, `modifier_evenement` et `publier_evenement`, ont fini par se confondre dans les choix de l'agent : une demande de publication d'un événement en brouillon aboutissait parfois à une simple modification de son titre, sans jamais le faire réellement apparaître sur le site public.

Ce texte s'adresse aux développeurs qui exposent des Abilities WordPress à un agent IA via le MCP Adapter, et détaille le diagnostic de cette confusion précise ainsi que le correctif appliqué. Il ne traite pas du tri de candidatures, sujet parfois abordé ailleurs sur ce blog dans un contexte différent.

## La déclaration initiale des deux Abilities

Les deux Abilities avaient été enregistrées à quelques semaines d'intervalle, par deux personnes différentes de l'équipe, sans relecture croisée de leurs descriptions respectives au moment de leur mise en place.

```
wp_register_ability( 'association/modifier-evenement', array(
    'label'         => 'Modifier un événement',
    'description'   => 'Modifie les informations d\'un événement existant.',
    'input_schema'  => array(
        'type'       => 'object',
        'properties' => array(
            'evenement_id' => array( 'type' => 'integer' ),
            'titre'        => array( 'type' => 'string' ),
            'statut'       => array( 'type' => 'string' ),
        ),
        'required'   => array( 'evenement_id' ),
    ),
    'execute_callback' => 'association_modifier_evenement_callback',
) );

wp_register_ability( 'association/publier-evenement', array(
    'label'         => 'Publier un événement',
    'description'   => 'Publie un événement.',
    'execute_callback' => 'association_publier_evenement_callback',
) );
```

## Comment l'agent a exploité cette ambiguïté

Le schéma de `modifier_evenement` acceptait un champ `statut` optionnel, capable en théorie de faire passer un événement de brouillon à publié. Face à une demande de publication, l'agent choisissait tantôt `publier_evenement`, tantôt `modifier_evenement` avec le champ `statut` renseigné à la bonne valeur, deux chemins qui auraient dû produire le même résultat mais dont l'un, en pratique, ne déclenchait pas la même logique métier côté callback : le passage de statut via `modifier_evenement` ne mettait pas à jour l'index de recherche du site, contrairement à l'exécution de `publier_evenement`.

> L'essentiel à retenir : Deux Abilities aux noms proches et aux descriptions génériques se confondent facilement pour un agent ; Le MCP Adapter transmet fidèlement le schéma déclaré, il ne corrige aucune ambiguïté ; Renommer et enrichir les descriptions a suffi, sans toucher au code des callbacks

## Ce que le MCP Adapter transmettait fidèlement, sans corriger

Le MCP Adapter s'est comporté exactement comme attendu tout au long de cet incident : il a exposé les deux Abilities telles qu'elles avaient été déclarées, avec leurs descriptions et schémas exacts, sans en modifier ni en simplifier le contenu. La confusion ne venait donc à aucun moment d'un défaut du MCP Adapter lui-même, mais entièrement de la déclaration des deux Abilities, pensées indépendamment sans vérifier leur chevauchement fonctionnel une fois exposées ensemble à un même agent.

## Le correctif appliqué

Le correctif a porté sur la déclaration des Abilities, jamais sur les fonctions de callback existantes, laissées inchangées.

1. **Retrait du champ `statut`** du schéma d'entrée de `modifier_evenement`, cette Ability ne devant plus jamais pouvoir changer l'état de publication.
2. **Description enrichie de `publier_evenement`**, précisant explicitement qu'elle seule met à jour l'index de recherche et rend l'événement visible publiquement.
3. **Description enrichie de `modifier_evenement`**, précisant qu'elle ne doit jamais servir à publier un événement, avec un renvoi explicite vers l'Ability dédiée.

```
wp_register_ability( 'association/modifier-evenement', array(
    'label'         => 'Modifier un événement existant',
    'description'   => 'Modifie le titre, la date ou le lieu d\'un événement déjà publié ou en brouillon. '
        . 'Ne modifie jamais son état de publication : utiliser publier_evenement pour cela.',
    'input_schema'  => array(
        'type'       => 'object',
        'properties' => array(
            'evenement_id' => array( 'type' => 'integer' ),
            'titre'        => array( 'type' => 'string' ),
        ),
        'required'   => array( 'evenement_id' ),
    ),
    'execute_callback' => 'association_modifier_evenement_callback',
) );
```

- Deux Abilities aux effets distincts ne doivent jamais partager un même champ capable de produire l'un ou l'autre effet.
- Une description doit préciser ce que l'Ability ne fait pas quand une confusion avec une Ability voisine est possible.
- Le MCP Adapter reste un simple transport fidèle : la clarté attendue se construit entièrement au moment de la déclaration.

> Deux Abilities déclarées séparément par deux personnes différentes doivent toujours être relues ensemble avant leur mise en production commune : chacune seule paraît sans ambiguïté, la confusion n'apparaît qu'à leur rencontre.

## En résumé

Une Ability WordPress mal décrite n'a pas besoin d'être fausse pour égarer un agent : il suffit qu'elle chevauche partiellement une Ability voisine sur un même effet pour que le choix de l'agent devienne imprévisible. Revoir conjointement les descriptions des Abilities exposées à un même agent, plutôt que de les relire isolément, reste le réflexe le plus efficace pour repérer ce type de chevauchement avant qu'il ne cause un incident.