Outils MCP

MCP portées et jetons

Émettre des jetons de portée MCP et les révoquer en toute sécurité.

Les jetons Showly MCP permettent aux agents de s'authentifier. Cette page explique comment les émettre, comment les définir de manière précise et comment les faire pivoter ou les révoquer lorsque quelque chose semble bizarre.

Émission d'un jeton

Paramètres de l'espace de travail → MCP clients → Nouveau client.

Vous définirez cinq champs :

Nom du client : apparaît dans les journaux d'audit. Rendez-le descriptif : Claude Code (alice@acme) se lit mieux que token-3.
Portée du projet — Facultatif. Lorsqu'il est défini, le jeton peut uniquement voir et muter les sites/déploiements dans ce projet.
Portées — Choisissez le minimum nécessaire. La valeur par défaut est project:read, site:read, preview:read.
TTL — Durée de validité du jeton. Par défaut 90 jours, maximum 365.
Notes — Free-texte. Utilisez-le pour enregistrer à quoi sert le jeton.

Le jeton est affiché une fois lors de la création. Copiez-le ; nous ne stockons pas le texte brut.

Référence de portée

Les portées sont des chaînes plates, sans niveaux imbriqués. Un jeton contient une liste explicite et l'API n'accepte que les noms exacts ci-dessous.

Portée	Niveau	Permet
`project:read`	lire	`list_projects` — répertorie et inspecte les projets auxquels ce jeton peut accéder
`site:read`	lire	`list_sites`, `get_site_context`, `create_change_plan`, `list_site_versions`, `get_site_files` — lire l'état du site
`site:write`	écrire	`apply_site_patch`, `create_site_from_template` — étapes de modifications (ne se déploie jamais directement)
`site:delete`	écrire	`delete_site` — suppression logicielle en cascade en deux étapes d'un site (niveau administrateur)
`preview:read`	lire	`get_preview_status` — lire l'état du déploiement
`preview:create`	écrire	`create_preview`, `create_github_preview`, `delete_preview` — matérialiser/supprimer un aperçu privé
`checks:run`	écrire	`run_checks` — lire l'état lint/typecheck/build/audit
`publish:request`	écrire	`request_publish` — ouvrir une ligne d'approbation pour une publication de production
`publish:confirm`	écrire	`publish_site` — confirmation et publication en deux étapes en production (confirmation humaine en conversation ; plans solo/non-approbation)
`rollback:confirm`	écrire	`rollback_to_version` — production en rouleau en deux étapes vers une version antérieure (niveau administrateur, direct vers la production)
`logs:read`	lire	`get_deployment_logs` — journaux de construction capturés en queue ; `diagnose_deployment` expose également les diagnostics client/agent limités
`template:read`	lire	`list_templates` — liste des modèles de sites disponibles
`template:create`	écrire	`create_site_from_template` — matérialiser un nouveau site à partir d'un template

Il n'y a pas d'échelle d'implication. Accorder publish:request n'accorde pas preview:create ; choisissez exactement les étendues dont un client a besoin. Le panneau « MCP jeton » de l'interface utilisateur Web présente cette liste sous forme de cases à cocher ; la même constante alimente le générateur de rôles pour les rôles RBAC personnalisés.

L'ancien verbe rollback_deployment n'est pas exposé MCP quelles que soient les portées ; publish_site est MCP appelable uniquement avec publish:confirm et une confirmation en deux étapes dans la conversation. Voir la référence de l'outil pour la justification.

À quoi ressemble un jeton à portée étroite

Pour un agent _content-only_ qui ne doit jamais toucher à l'infrastructure :

Liste verte : uniquement le site marketing-site.
Portées : site:read, site:write. L'agent peut transférer des correctifs mais ne peut pas créer d'aperçus ni les publier.
TTL : 30 jours.

Pour un _deploy-bot_ dans CI :

Liste verte : uniquement le site de production qu'il déploie.
Portées : preview:read, preview:create, checks:run, publish:request. Non site:write — les correctifs proviennent du flux de travail enregistré de CI, pas du bot.
TTL : 14 jours, en rotation par CI.

Pour un _bot d'intégration basé sur un modèle_ :

Liste verte : tout projet auquel le bot est invité.
Portées : project:read, template:read, template:create, site:write, preview:read, preview:create. Permet au robot de choisir un modèle, de créer le site et de regarder la première version d'aperçu.
TTL : 7 jours.

Rotation

Deux chemins :

Manuel — Cliquez sur Rotation sur un client. L'ancien jeton est révoqué instantanément ; copiez le nouveau et mettez à jour la configuration de votre shell.
Planifié : définissez une cadence de rotation dans Paramètres de l'espace de travail → Politique de jeton. Showly envoie un e-mail au propriétaire du client avant l'expiration.

Révocation

Cliquez sur Révoquer pour supprimer un jeton immédiatement. Tout appel d'outil en cours utilisant le jeton révoqué obtient un 401. Le nom du client reste dans les journaux d'audit (avec un indicateur revoked), de sorte que les entrées historiques sont toujours résolues.

Si vous pensez qu'un jeton est compromis, révoquer d'abord, enquêter ensuite. Un jeton compromis avec une portée publish:request peut ouvrir une approbation de publication, mais il ne peut toujours pas contourner l'approbateur humain ou la confirmation de publication liée au déploiement.

Visibilité des audits

Chaque appel d'outil écrit une ligne d'audit contenant l'identifiant client (pas le jeton). Tu peux:

Interroger tous les appels d'un client : client_id eq <id>.
Interrogez tous les appels en écrivant un verbe : action eq mcp.request_publish.
Examiner et exporter les enregistrements uniquement via les surfaces d'audit activées pour le

espace de travail.

Ce que les jetons ne peuvent pas faire

Lectures multi-locataires. Le jeton est lié à un espace de travail.
Contourner les approbations. Une portée publish:request accorde la _capacité d'ouvrir_ une approbation ; les règles d'approbation s'appliquent toujours.
Écrivez à la facturation ou au RBAC. Ceux-ci nécessitent un rôle humain + administrateur + une session de navigateur.
Invoquez l'ancien verbe rollback_deployment — il n'est pas du tout enregistré sur le serveur MCP. (publish_site nécessite la portée publish:confirm plus une confirmation explicite en deux étapes.)

La publication directe Free/Pro utilise également publish:confirm, qui est inclus dans l'autorisation d'agent d'édition recommandée et nécessite toujours l'autorisation confirmation de deuxième appel de courte durée. Portées de suppression et de restauration destructives rester opt-in.