Fonctionnement de l’adaptateur MCP officiel de WordPress

L’adaptateur MCP officiel de WordPress traduit les WordPress Abilities en outils ou ressources MCP que les clients d’IA compatibles peuvent découvrir. Une Ability définit une unité de fonctionnalité nommée avec des entrées typées, des sorties, un callback d’exécution et un callback de permission. L’adaptateur n’expose pas automatiquement chaque action WordPress.

Les outils exacts disponibles dépendent des Abilities enregistrées et de la configuration de l’adaptateur. Les callbacks de permission et l’utilisateur WordPress authentifié demeurent essentiels.

En une phrase : l’adaptateur transforme les WordPress Abilities explicitement enregistrées en primitives MCP tout en préservant les contrôles de permission côté WordPress.

Ce que ce guide vous aide à accomplir

Ce guide prépare une personne expérimentée à évaluer ou à tester l’adaptateur officiel sans exagérer ce que le cœur de WordPress expose actuellement. Il définit aussi les preuves que le site doit recueillir avant de publier un tutoriel d’intégration.

Un flux de travail d’IA utile ne se définit pas seulement par la qualité de la réponse. Il dépend aussi des données auxquelles l’assistant peut accéder, des actions qu’il est autorisé à accomplir, des preuves que vous pouvez examiner par la suite et de la facilité avec laquelle l’accès peut être révoqué.

Pourquoi c’est important

L’API Abilities fournit à WordPress un registre normalisé pour les actions découvrables. L’adaptateur MCP peut ensuite exposer ces actions aux clients agentiques. Cette architecture est plus solide que d’inventer un outil distinct et non documenté pour chaque fonction d’extension.

Cependant, l’existence de l’adaptateur ne signifie pas qu’un site possède une API complète d’administration par IA. Seules les Abilities enregistrées et configurées apparaissent, et leur maturité évolue selon les versions de WordPress.

Résultat attendu

Une exécution réussie devrait produire :

  • Un inventaire des WordPress Abilities enregistrées.
  • Une correspondance entre les Abilities et les outils ou ressources MCP exposés.
  • Un enregistrement des callbacks de permission et de l’identité authentifiée.
  • Un test de découverte et d’exécution côté client.
  • Une liste des écarts entre les tâches souhaitées et les Abilities disponibles.

Les Abilities comme couche source

Chaque Ability possède un identifiant unique, des métadonnées descriptives, des schémas d’entrée et de sortie, un callback d’exécution et un callback de permission. WordPress peut exposer certaines Abilities par REST lorsqu’elles sont configurées. L’adaptateur convertit ces unités déclarées en MCP plutôt que d’extraire des fonctions arbitraires.

Comportement par défaut de l’adaptateur

La documentation officielle décrit un serveur par défaut et des outils permettant de découvrir les Abilities, de récupérer leurs renseignements et d’exécuter une Ability. Les Abilities doivent être explicitement mises à la disposition de l’adaptateur ; la publication ne doit pas présumer que toute Ability enregistrée est exposée.

Permission et identité

Le callback de permission de l’Ability devrait évaluer l’utilisateur authentifié et le contexte pertinent. La couche MCP ne devrait pas contourner ce contrôle. Un test utile s’authentifie avec deux identités ayant des capacités différentes et confirme qu’un même appel d’outil produit des résultats d’autorisation différents.

Développement et débogage

Utilisez les commandes WP-CLI Ability ou l’interface REST pour lister, inspecter, valider et exécuter les Abilities indépendamment du client MCP. Cela permet d’isoler si une défaillance concerne l’enregistrement de l’Ability, l’autorisation WordPress, le mappage de l’adaptateur, le transport ou le comportement du client.

Un flux de travail sûr

  1. Créez un environnement WordPress jetable exécutant une version prise en charge.
  2. Installez l’adaptateur MCP officiel actuel à partir de sa source de publication principale.
  3. Listez les Abilities enregistrées et consignez leurs schémas et callbacks de permission.
  4. Configurez seulement les Abilities requises pour le serveur de test.
  5. Authentifiez-vous au moyen d’une identité WordPress dédiée et limitée.
  6. Connectez un client pris en charge et inspectez les outils découverts.
  7. Exécutez une Ability connue en lecture seule et une Ability refusée.
  8. Consignez toutes les versions, tous les schémas, les résultats et les étapes de nettoyage.

Limite d’accès recommandée

Le niveau approprié dépend de l’action demandée. Commencez sans connexion ou en mode Read Only, puis passez à Draft ou Content Editor seulement lorsque la tâche ne peut pas être accomplie de manière sûre au niveau inférieur.

Ce flux de travail peut influencer des décisions éditoriales ou créer des modifications non publiées. Gardez une portée restreinte et examinez chaque changement proposé.

Le niveau d’accès constitue une recommandation initiale, et non un droit universel. Les capacités WordPress exactes dont dispose une identité doivent être établies à partir de la version installée du produit et de sa couverture publiée, et non à partir de ce seul article.

Ce qui doit demeurer hors de la tâche

  • Ne laissez pas entendre que le cœur de WordPress expose de vastes Abilities de gestion de contenu à moins que la version testée ne le fasse réellement.
  • N’enregistrez pas une Ability sans callback de permission significatif.
  • N’exposez pas d’Abilities personnalisées destructrices durant le premier test d’intégration.
  • Ne publiez pas de commandes copiées d’une ancienne version sans reproduction.

Comment WP Agent Control s’intègre

Obtenez des informations structurées sur le site et examinez des pages publiées après la connexion. Cette lecture publique ne nécessite aucune tâche temporaire. Vous pouvez aussi consulter les pages publiques sans le plugin ; Agent Control ajoute un accès structuré et la continuité vers du travail WordPress autorisé.

Autorisez une tâche de brouillon et sélectionnez les contenus de référence. L’assistant peut créer et réviser les brouillons créés par cette tâche. Les références existantes restent en lecture seule, même si ce sont elles-mêmes des brouillons. Vérifiez le résultat dans WordPress.

Avec Solo, Pro ou Agency, autorisez une tâche de proposition pour les contenus et champs sélectionnés. Examinez la comparaison complète dans WordPress et sélectionnez les propositions approuvées. L’approbation est liée à l’objet, aux champs et au contenu courant ; une source ou une tâche modifiée peut l’invalider. Approuver un changement de contenu n’autorise pas sa publication. Avec Solo, Pro ou Agency, il faut aussi une tâche de publication qui couvre l’approbation encore valide. Vérifiez vous-même le résultat publié.

Connecter votre IA : docs first profile · Voir les fonctions et la compatibilité : coverage

Liste de vérification

  • Les versions de WordPress, de l’adaptateur et du client sont consignées.
  • Les Abilities enregistrées et exposées sont inventoriées séparément.
  • Les callbacks de permission sont inspectés.
  • Une identité limitée est utilisée.
  • L’exécution directe d’Ability et l’exécution MCP sont toutes deux testées.
  • Le guide indique les comportements indisponibles ou expérimentaux.

Modes d’échec courants

  • Présumer la couverture du cœur : la disponibilité de l’infrastructure est confondue avec une vaste bibliothèque d’Abilities prêtes pour la production.
  • Déboguer uniquement par l’agent : une défaillance ne peut pas être localisée entre les couches WordPress, adaptateur et client.
  • Callbacks de permission faibles : le schéma de l’Ability est précis, mais l’autorité ne l’est pas.
  • Publier des cibles mouvantes : un comportement expérimental ou spécifique à une version est présenté comme universel.

Note avancée

La future intégration la plus solide traiterait les Abilities comme des interfaces gouvernées et versionnées, avec des identifiants sémantiques, des vérifications de compatibilité de schéma et des fixtures de test. MCP deviendrait alors une projection de cette couche d’autorité, et non une source de vérité indépendante.

Guides connexes

Continuer

Prochaine étape : ouvrez Quel niveau d’accès WordPress devriez-vous donner à une IA ?, choisissez le plus petit niveau d’accès adéquat, puis suivez le guide de connexion pertinent. Lorsque vous êtes prêt à créer une identité distincte et révocable, consultez Produit ou commencez l’essai Solo de 7 jours.

Sources et vérification

Cette page a été vérifiée à partir des sources primaires suivantes. Dernière révision des sources: .