Le client IA trouve un outil WordPress, mais l’action est refusée
La découverte d’un outil prouve sa découvrabilité, pas son autorisation. Son exécution peut encore être refusée par le schéma, la politique du serveur, l’authentification WordPress, le contrôle de permission d’une Ability, le contrôle d’un point de terminaison REST ou les capacités de l’utilisateur propriétaire.
Causes probables
- L’utilisateur WordPress authentifié ne possède pas la capacité exigée par le point de terminaison ou l’outil.
- La fonction de permission du point de terminaison refuse l’utilisateur authentifié pour l’opération demandée.
- Le flux demande une écriture alors que l’identité WordPress est volontairement limitée à la lecture.
- Le serveur ou l’extension n’expose volontairement qu’un sous-ensemble d’outils pour l’identité ou la configuration active.
- L’identifiant est associé à un autre utilisateur WordPress que celui attendu par le client.
Séquence de diagnostic
- Demandez la liste des outils MCP et consignez les noms et schémas réellement exposés par le serveur.
- Comparez le nom et les entrées de l’outil demandé avec le schéma retourné par le serveur MCP actif.
- Utilisez un contrôle d’identité authentifié minimal pour confirmer l’utilisateur WordPress représenté par la requête.
- Comparez les capacités de l’utilisateur authentifié avec l’action exigée par la route ou l’outil.
- Répétez une lecture étroite et connue qui devrait être autorisée pour cette identité.
- Tentez une écriture volontairement interdite pour confirmer que la limite la refuse toujours.
Appliquer le correctif minimal
- Choisissez le niveau d’accès WordPress le plus faible permettant l’action approuvée.
- Créez une identité WordPress dédiée au lieu de réutiliser l’administrateur humain.
- Corrigez le point de terminaison, le transport, le nom d’outil ou la référence d’identifiant sans élargir les permissions WordPress.
- Remplacez les instructions périmées par une documentation correspondant au client, à l’extension et à la version installés.
- Transmettez des preuves assainies et versionnées au soutien lorsque le comportement demeure propre à l’extension.
Vérifier le résultat
- Le serveur MCP actif liste l’outil WordPress attendu et son schéma d’entrée courant.
- La requête authentifiée correspond à l’utilisateur WordPress dédié prévu.
- La lecture étroite approuvée réussit avec une réponse reproductible.
- L’outil demeure visible, mais WordPress refuse correctement l’action dépassant la capacité de l’identité.
Ce qu’il ne faut pas faire
- N’accordez pas un accès administrateur uniquement pour réussir un test de connexion.
- Ne considérez pas tout code 403 comme une connexion brisée ; il peut s’agir du refus de permission attendu.
- Ne confondez pas authentification réussie et permission d’exécuter toutes les actions WordPress.
- Ne passez pas d’une identité limitée à Pleine puissance sans flux approuvé distinct, environnement de test et retour arrière.
- Ne placez jamais un mot de passe d’application, un en-tête Authorization, un jeton ou un témoin dans une invite, un billet, un extrait de journal ou une capture.
Guides connexes
- MCP est connecté, mais aucun outil WordPress n’apparaît
- WordPress renvoie 403 après l’authentification par mot de passe d’application
- Quelles permissions possède un mot de passe d’application WAP ?
- Quel niveau d’accès WordPress devriez-vous donner à une IA ?
- API REST WordPress vs MCP : laquelle utiliser ?
Sources et vérification
Cette page a été vérifiée à partir des sources primaires suivantes. Dernière révision des sources: .
- Model Context Protocol: Tools · Model Context Protocol
- Abilities API · WordPress Developer Resources
- Roles and Capabilities · WordPress Developer Resources
- Routes and Endpoints · WordPress Developer Resources