Les jetons et les portées

Un agent n'a jamais un pouvoir à lui : il agit avec le jeton nommé qu'on lui a donné, et ce jeton porte les mêmes règles que n'importe quel jeton créé à la main dans Réglages › Connexions et agents › Accès avancés.

Lecture et écriture

Un jeton porte une ou deux portées : read et write.

• read laisse lire — tous les GET, et les appels d'écriture passés en simulation (dry_run). C'est la portée d'un agent à qui l'on ne veut confier que la lecture d'un planning, un rapport d'avancement, un export.
• write est nécessaire pour tout le reste — chaque tool qui pose un bloc, déplace une ligne, répond à un commentaire. Un jeton en lecture seule qui tente un de ces tools reçoit un refus explicite (SCOPE_INSUFFICIENT), pas un succès silencieux.

Un jeton nommé né d'un POST /oauth/authorize porte les portées demandées par le client au moment de l'autorisation (le formulaire de consentement les affiche) — Claude Code demande en général les deux.

Un jeton par client

Chaque client OAuth qui s'enregistre (Claude Code, Claude Desktop s'il passait par cette porte, un autre agent) obtient son propre jeton, nommé d'après lui — « MCP · Claude Code », « MCP · <nom du client> ». Ce n'est pas un jeton partagé : deux agents différents ont deux jetons différents, deux lignes différentes dans Réglages › Connexions et agents › Applications connectées, et deux attributions différentes dans le journal du planning (« Claude (vous) », ou « Claude (Anne) » si le jeton agit pour un autre utilisateur que le propriétaire de l'instance).

Durée : trente jours, avec un rafraîchissement automatique valable quatre-vingt-dix jours — un rafraîchissement à usage unique, remplacé par une paire neuve à chaque utilisation ; le jeton d'accès change de secret, mais reste le même jeton nommé (le même identifiant, la même ligne dans les préférences) tant que le client continue de se rafraîchir à temps.

La révocation

• Depuis Réglages › Connexions et agents › Applications connectées : révoquer un jeton nommé le coupe immédiatement, et ferme sur-le-champ toute session /mcp vivante qu'il portait — ses flux, ses abonnements aux resources compris. Un agent qui tentait un appel au même moment reçoit un 401, pas une session qui traîne.
• Par le protocole OAuth lui-même : POST /oauth/revoke (RFC 7009) révoque un jeton d'accès, ou toute une famille de rafraîchissements à la fois — le point que Claude Code utilise pour se déconnecter proprement.
• Un jeton rejoué (un code d'autorisation ou un rafraîchissement présenté deux fois) est traité comme un vol probable : toute la famille de jetons qui en découle est révoquée sur l'instant.

Ce qu'un agent peut faire, et ce qu'il ne peut pas

Un agent peut tout ce que les 101 tools couvrent : construire, modifier, analyser, partager, publier, exporter et importer des plannings — et, depuis 0.22.0, poser ou lire ses propres absences (list_absences, add_absence, remove_absence, get_schedule_risks). C'est volontairement large — c'est le produit.

Un agent ne peut pas :

• gérer les jetons (/api/v1/me/tokens) ni les sessions de l'écran (/api/v1/me/sessions) — un client MCP ne crée pas ses propres jetons, ni ceux d'un autre ;
• changer le mot de passe, dénouer Google, ou écrire sur le profil (/api/v1/me/password, /api/v1/me/google, PUT /api/v1/me) — ces routes sont réservées à une session d'utilisateur (le cookie de l'écran), refusées à tout jeton nommé avec un refus qui le dit explicitement (« les jetons se gèrent avec le jeton de l'écran, pas avec un jeton nommé ») ;
• exporter ou supprimer le compte lui-même, ni changer qui vous êtes. Ce n'est pas une restriction ajoutée après coup : il n'existe, parmi les 101 tools, aucun tool qui touche aux réglages du compte (mot de passe, profil, Google, export, suppression) — ceux-là restent réservés à une session d'utilisateur, comme ci-dessus. Seules vos absences (depuis 0.22.0) sont une donnée personnelle qu'un tool peut poser ou lire, parce qu'un agent doit pouvoir dire « je suis absent » comme vous le diriez vous-même — jamais celles d'un autre compte que le vôtre, et jamais un motif médical (le schéma le refuse). Le droit à l'export et à l'effacement du compte entier (RGPD) reste à la personne ; ce n'est pas une capacité qu'on délègue à un agent qui agit en son nom, même avec un jeton write.

(Point de vigilance pour ce dépôt : les routes API de l'export et de la suppression d'un compte, ajoutées au sprint 16, ne sont pas présentes dans la lignée de branches d'où ce guide est écrit — voir la clôture du sprint pour ce que cela signifie sur l'état de docs/agents/. L'absence de tout tool MCP dédié au compte, elle, est vérifiable dans le catalogue actuel indépendamment de ce point.)

Une vue embarquée n'est pas un jeton nommé

Dans un hôte MCP Apps, la vue embarquée (show_schedule) n'a aucun jeton à elle : elle lit et écrit par l'hôte, sous le jeton nommé (ou l'OAuth) du connecteur. Pour un client qui n'affiche pas les MCP Apps (Claude Code), show_schedule rend une adresse portant un jeton d'une heure, plafonné au planning affiché et au rôle de qui l'a demandée, en lecture seule sauf editable: true — un mécanisme différent des jetons nommés de cette page, jamais visible ni révocable dans Réglages › Connexions et agents › Applications connectées. Sous ce jeton, la liste des membres ne porte pas d'adresse e-mail, et l'agenda pas de motif d'absence. Il expire de lui-même ; rien à retenir de plus ici.