Comment exposer une Ability WordPress personnalisée par MCP

Une Ability WordPress personnalisée peut être projetée par un adaptateur MCP, mais son exposition de transport ne doit pas élargir son contrat de permission, de validation, d’effets secondaires ou de preuve.

L’IA est ici surtout utile comme organisatrice de preuves, moteur de comparaison et assistante de rédaction. Elle peut faciliter l’examen d’une tâche WordPress complexe, mais elle ne peut pas créer une autorité manquante, certifier des faits qu’elle n’a pas observés ou convertir silencieusement une recommandation en permission d’agir.

En une phrase : une Ability WordPress personnalisée peut être projetée par un adaptateur MCP, mais son exposition de transport ne doit pas élargir son contrat de permission, de validation, d’effets secondaires ou de preuve.

Ce que ce guide vous aide à accomplir

Préparer et vérifier une Ability personnalisée pour la découverte et l’exécution par MCP au moyen de schémas explicites, de permissions limitées, de tests négatifs et d’une validation propre au client.

• Une Ability personnalisée testée avec un contrat stable.
• Une décision d’exposition MCP et un relevé de configuration.
• Des preuves de test pour la découverte, l’exécution, le refus et les entrées mal formées.
• Des notes de configuration propres au client qui ne laissent pas entendre une compatibilité universelle.

L’artefact final doit être compréhensible par la personne responsable de la décision et reproductible par une personne qui n’a pas participé au prompt initial. Une réponse fluide ne suffit pas. Chaque conclusion importante nécessite une source, une portée et un chemin de vérification. Lorsque les preuves ne peuvent pas établir un élément, la sortie correcte est un inconnu explicite ou une hypothèse testable.

Preuves et entrées à préparer

• Une Ability WordPress enregistrée et testée.
• La documentation actuelle de l’adaptateur MCP WordPress et du client.
• La configuration d’authentification et d’identité WordPress.
• Des fixtures locales ou de préproduction sûres.
• La couverture WP Agent Control installée lorsqu’elle fournit l’identité WordPress.

Avant de fournir des preuves à un assistant, supprimez les identifiants, les valeurs secrètes et les renseignements personnels non liés. Conservez les identifiants, versions, horodatages, paramètres régionaux, unités et libellés de source nécessaires pour interpréter ce qui reste. Une capture d’écran sans URL, état ou date peut fournir un contexte utile, mais elle constitue rarement une autorité suffisante pour une décision de production.

Ne commencez pas par une demande générale telle que « examinez ceci », « corrigez ceci » ou « améliorez ceci ». Définissez la décision que le travail doit appuyer, la population incluse, la source qui fait autorité pour chaque champ, les opérations autorisées et les actions qui demeurent interdites. Un accès WordPress authentifié ou une exportation contrôlée est requis pour cette tâche.

MCP est un transport et une couche de découverte

Il aide un client à comprendre et à appeler des outils. Il ne remplace pas l’autorisation WordPress, la validation de l’Ability ni l’approbation responsable.

La prise en charge du client est spécifique

Claude Code, Codex et d’autres clients peuvent différer quant à la configuration, à la présentation des outils, à l’UX d’approbation et à la prise en charge du transport. Testez chaque chemin nommé.

Un refus fait partie du contrat

Une exécution non autorisée devrait échouer de manière prévisible et être documentée. N’élargissez pas l’identité WordPress pour faire réussir une démonstration.

Gardez séparées l’observation, l’inférence et l’autorité

Une révision contrôlée devrait distinguer au moins quatre états :

1. Observé : présent directement dans un enregistrement, fichier, réponse, page rendue ou test exécuté nommé.
2. Inféré : une interprétation plausible appuyée par des preuves, mais non établie directement.
3. Recommandé : une décision humaine proposée ou une prochaine action.
4. Autorisé et vérifié : un changement approuvé séparément, exécuté puis contrôlé selon des critères d’acceptation.

La sortie d’IA commence habituellement dans les trois premiers états. Elle ne devient pas autorisée simplement parce qu’elle est détaillée, cohérente sur le plan interne ou techniquement convaincante. Préservez cette distinction dans les tableaux, rapports, tickets et études de cas publiques.

Un flux de travail sûr

1. Complétez et testez l’Ability sous-jacente avant son exposition par MCP.
2. Confirmez la version de l’adaptateur, le transport et le chemin d’authentification.
3. Exposez uniquement l’Ability et les métadonnées prévues.
4. Connectez un client sûr à une identité WordPress dédiée.
5. Testez la découverte et une fixture valide en lecture seule ou limitée.
6. Testez les requêtes non autorisées, non valides et hors portée.
7. Consignez les versions du client, du modèle, de l’adaptateur, de WordPress et de l’extension.
8. Révoquez l’identité de test et conservez des preuves reproductibles.

Cette séquence place délibérément une révision responsable entre l’analyse et l’implémentation. Si une étape ultérieure exige un accès plus large, créez une nouvelle tâche, une nouvelle identité ou une modification explicite de permission. N’améliorez pas discrètement l’identité analytique parce qu’elle a atteint une limite correcte.

Modèle de prompt

Remplacez chaque valeur entre crochets avant d’utiliser le prompt. Ne collez pas de mots de passe, clés API, témoins d’authentification, dossiers clients privés ou renseignements personnels non liés.

Vous examinez [TASK SCOPE] pour [SITE, REPOSITORY OR DATASET] en utilisant uniquement les preuves fournies.

Objectif :
Préparer et vérifier une Ability personnalisée pour la découverte et l’exécution par MCP au moyen de schémas explicites, de permissions limitées, de tests négatifs et d’une validation propre au client.

Retournez les champs suivants :
- Ability
- Version de l’adaptateur
- Client
- Transport
- Identité
- Permission
- Résultat de la découverte
- Exécution valide
- Exécution refusée
- Entrée non valide
- Preuve
- Limite connue

Règles :
1. N’exposez pas d’Abilities avant que leurs tests directs réussissent.
2. Préservez exactement les noms, schémas et identifiants des Abilities.
3. Ne prétendez pas à une compatibilité avec des clients ou versions non testés.
4. N’utilisez pas Full Power pour contourner un refus.
5. N’incluez pas d’identifiants dans les exemples de configuration.

Pour chaque constat :
- identifiez la source, l’enregistrement, l’URL, le fichier, la ligne, l’ID d’objet, l’état ou la ligne d’ensemble de données exacts ;
- préservez les dates, versions, unités, paramètres régionaux, identifiants et dénominateurs ;
- séparez l’observation, l’inférence, la recommandation et l’inconnu ;
- indiquez quelles preuves n’étaient pas disponibles ;
- ne modifiez pas WordPress, le code source, les données commerciales, l’analytique, les systèmes externes ou le contenu publié.

Pourquoi ce prompt est structuré ainsi

Le prompt crée un contrat de preuve avant de demander des recommandations. Il rend les données manquantes visibles, réduit le risque qu’un modèle complète un enregistrement incomplet avec une prose plausible et produit une sortie qui peut être examinée systématiquement. Les champs structurés facilitent aussi la comparaison d’exécutions répétées ou la transmission d’un sous-ensemble approuvé à un flux de travail d’implémentation ultérieur.

Une implémentation de production peut ajouter un schéma JSON, des entrées d’outils typées ou une validation automatisée. Ces mécanismes améliorent la cohérence, mais ils n’établissent pas que la preuve source est vraie, complète ou actuelle. Une révision humaine et une vérification propre au système demeurent requises.

Limite d’accès recommandée

Utilisez Dépend de l’étape autorisée séparément pour l’étape décrite dans ce guide. Les capacités exactes offertes à une identité doivent provenir de la version installée du produit, du contrat de couverture publié et de la méthode de connexion réellement utilisée.

Ce qui doit demeurer hors de cette tâche

• Exécution de production
• Divulgation d’identifiants
• Exposition étendue d’outils
• Élévation de permission
• Revendications de compatibilité universelle

Une action refusée peut constituer une preuve utile que la limite de contrôle fonctionne. Ne répondez pas à un refus attendu en accordant un compte administrateur étendu ou Full Power. Déterminez d’abord si l’action appartient au mandat actuel. Si c’est le cas, créez une étape autorisée séparément avec la capacité nécessaire la plus limitée.

Comment WP Agent Control s’intègre

Le dossier privé guidé pour Claude Code ou Codex utilise l’API REST WordPress et un mot de passe d’application avec un profil dédié en lecture seule. Les profils Read Only, Draft, Content Editor et Publisher existants restent dans les options avancées. Ils ne sont pas automatiquement convertis à OAuth et ne reprennent pas le modèle de tâches distantes et d’approbation exacte.

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é.

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

Liste de vérification

• ☐ La tâche, la population, la période, l’environnement et la décision sont explicites.
• ☐ Chaque observation importante est liée à une preuve exacte ou étiquetée comme une hypothèse.
• ☐ Les ID stables, URL, versions, dates, unités, paramètres régionaux et dénominateurs sont préservés.
• ☐ Les preuves manquantes et les limites de couverture demeurent visibles.
• ☐ L’identité analytique ou de recherche n’a effectué aucune mutation interdite.
• ☐ Un propriétaire qualifié a examiné les implications de sécurité, d’accessibilité, juridiques, commerciales ou de publication, le cas échéant.
• ☐ Toute implémentation dispose d’un mandat distinct, d’un niveau d’accès, d’une sauvegarde et d’un plan de vérification.
• ☐ Les identités temporaires, fixtures et preuves sensibles sont révoquées, réinitialisées ou éliminées après la tâche.

Modes d’échec courants

• Développement axé d’abord sur le transport : l’équipe débogue MCP alors que le contrat de l’Ability sous-jacente demeure instable.
• Dépassement du compte de démonstration : une identité administrateur étendue masque les défauts de permission et crée une documentation non sécuritaire.
• Confusion entre clients : une configuration testée dans un client est copiée vers un autre ayant une sémantique de configuration différente.
• Effets secondaires silencieux : un outil décrit comme analytique modifie WordPress ou un système externe.

Un échec transversal récurrent est la dérive de permission : la tâche initiale rencontre une limite, et l’opérateur élargit l’accès avant de déterminer si l’opération manquante est nécessaire, prise en charge ou sûre. Cela détruit la valeur probante du refus et rend les résultats ultérieurs difficiles à attribuer.

Note avancée

Traitez MCP comme une projection d’un contrat d’Ability gouverné. Les métadonnées de découverte, l’autorisation d’exécution et la restitution observée devraient être testées comme des couches distinctes afin qu’un changement de transport ne puisse pas élargir silencieusement l’autorité opérationnelle.

Guides connexes

• Guide de l’API Abilities de WordPress pour les flux de travail avec l’IA
• Comment créer une matrice de test des autorisations WordPress pour les agents IA
• Comment connecter Claude Code à WordPress
• Comment connecter Codex à WordPress

Continuer

Poursuivez avec le guide de soutien le plus pertinent et utilisez le guide des niveaux d’accès avant toute tâche authentifiée. Lorsque l’accès WordPress temporaire n’est plus nécessaire, terminez par la révocation de l’identité.