Ce qu'il peut atteindre
La limite réelle.
C'est votre rôle qui décide des outils qui existent
Le serveur agit en votre nom, sur la connexion que vous avez rendue active. Il n'existe pas de compte de service distinct ni d'accès plus large que le vôtre. Depuis la livraison des rôles, il n'y a pas non plus d'accès plus large que votre RÔLE. La liste d'outils remise à un client est construite à partir des permissions que vous détenez dans l'espace de travail actif : le client d'un Lecteur ne liste donc pas du tout sendEmail, createRule ni sendWithTemplate.
C'est plus fort que de refuser l'appel. Un outil absent de la liste n'est pas un outil sur lequel le modèle raisonne, il ne consomme pas de contexte, et il ne peut pas être tenté au nom de quelqu'un pour être ensuite excusé. Cela signifie aussi qu'un client qui paraît vide correspond le plus souvent à une permission que vous ne détenez pas plutôt qu'à une fonctionnalité qui manquerait à ce serveur, ce qui est exactement ce que whoAmI existe pour vous dire.
L'enregistrement et l'invocation sont deux barrières, et seule la seconde tient. La liste est construite une seule fois, à l'ouverture de la session, et setActiveConnection peut déplacer cette session vers une boîte aux lettres où vous avez le droit d'en faire moins : la liste est donc périmée par construction, et le protocole n'a aucun moyen de retirer un outil en cours de session. Chaque outil protégé re-résout donc votre rôle sur la connexion ACTUELLE avant de s'exécuter. L'enregistrement est la politesse ; l'invocation est la limite.
Un refus nomme les deux moitiés, comme dans Refused (missing_permission): your role in this mailbox is Viewer, which does not include "Send email", afin qu'un agent puisse l'expliquer à la personne pour qui il travaille et cesser d'essayer, plutôt que de réessayer une erreur opaque jusqu'à ce que quelqu'un abandonne. Un rôle modifié par un administrateur pendant qu'une session est ouverte se manifeste de la même façon, dès l'appel suivant.
Les adresses sont l'autre axe et rien de tout cela ne les affecte. Un rôle dit ce que vous avez le droit de faire ; les adresses qui vous ont été accordées disent sur quelles boîtes aux lettres vous pouvez le faire, et les deux doivent concorder avant qu'un message ne parte.
Le jeton lui-même n'a toujours pas de scope
Ce qui n'a PAS changé, c'est l'autorisation. Le jeton qu'une application reçoit atteint tout ce que votre rôle permet, et non un sous-ensemble que vous auriez choisi en l'approuvant : approuver un client, c'est donc l'approuver pour tout ce que vous pouvez faire dans cet espace de travail. On vous montre qui demande l'accès avant que quoi que ce soit ne soit accordé, et Compte → Applications connectées permet de le retirer ensuite, en supprimant chaque jeton qu'il détient et l'approbation qui les fonde ; mais choisir « lecture seule, pour cette application » n'existe pas.
Le plafond d'un client MCP est donc VOTRE plafond. Restreindre ce qu'une application peut faire revient à restreindre le rôle de la personne qui l'a connectée, ce qui restreint aussi ce qu'elle peut faire dans l'application. C'est la forme honnête des choses aujourd'hui, et la raison pour laquelle un scope par autorisation vaut encore la peine d'être construit.
Le vocabulaire est déjà commun : les permissions d'un rôle et les scopes d'une clé API sont tirés d'un même alphabet, ce qui rend l'autorité d'une clé calculable comme l'intersection des deux. Un scope MCP par autorisation s'exprimera dans les mêmes mots lorsqu'il arrivera.