Worauf es zugreifen kann
Die ehrliche Grenze.
Ihre Rolle entscheidet, welche Tools existieren
Der Server handelt als Sie, gegen die Verbindung, die Sie aktiv gesetzt haben. Es gibt kein separates Dienstkonto und keinen weiter reichenden Zugriff als Ihren eigenen. Seit es Rollen gibt, auch keinen weiter reichenden als Ihre ROLLE. Die Tool-Liste, die ein Client bekommt, wird aus den Berechtigungen gebaut, die Sie im aktiven Workspace haben; der Client einer Person mit der Rolle Viewer führt sendEmail, createRule oder sendWithTemplate daher überhaupt nicht auf.
Das ist stärker, als den Aufruf abzulehnen. Ein Tool, das nicht in der Liste steht, ist kein Tool, über das das Modell nachdenkt, es frisst keinen Kontext, und es kann nicht für jemanden versucht und danach entschuldigt werden. Es heißt außerdem: Ein leer wirkender Client liegt meist an einer Berechtigung, die Sie nicht haben, und nicht an einer Funktion, die diesem Server fehlt – und genau dafür gibt es whoAmI.
Registrierung und Aufruf sind zwei Tore, und nur das zweite hält. Die Liste wird einmal gebaut, beim Öffnen der Sitzung, und setActiveConnection kann diese Sitzung in ein Postfach versetzen, in dem Sie weniger dürfen; die Liste ist also bauartbedingt veraltet, und das Protokoll kann ein Tool mitten in der Sitzung nicht zurückziehen. Jedes abgesicherte Tool löst deshalb vor der Ausführung Ihre Rolle erneut gegen die AKTUELLE Verbindung auf. Die Registrierung ist die Höflichkeit; der Aufruf ist die Grenze.
Eine Ablehnung nennt beide Hälften, etwa Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”, sodass ein Agent es der Person erklären kann, für die er arbeitet, und aufhört – statt einen undurchsichtigen Fehler so lange zu wiederholen, bis jemand aufgibt. Eine Rolle, die ein Admin bei offener Sitzung ändert, schlägt genauso durch, beim allernächsten Aufruf.
Adressen sind die andere Achse und von all dem unberührt. Eine Rolle sagt, was Sie dürfen; die Adressen, die Ihnen zugeteilt wurden, sagen, in welchen Postfächern Sie es dürfen, und beide müssen übereinstimmen, bevor eine Nachricht hinausgeht.
Das Token selbst ist weiterhin ohne Scope
Was sich NICHT geändert hat, ist der Grant. Das Token, das eine App erhält, reicht an alles, was Ihre Rolle erlaubt, und nicht an eine Teilmenge, die Sie beim Zustimmen gewählt hätten; einem Client zuzustimmen heißt also, ihm zu allem zuzustimmen, was Sie in diesem Workspace können. Sie sehen, wer anfragt, bevor irgendetwas gewährt wird, und Account → Connected apps entfernt es hinterher und löscht jedes Token, das die App hält, samt der Zustimmung dahinter – aber „nur lesen, für diese App“ zu wählen, ist nicht gebaut.
Die Obergrenze eines MCP-Clients ist also Ihre eigene. Einzuschränken, was eine App darf, heißt, die Rolle der Person einzuschränken, die sie verbunden hat – und damit auch das, was sie selbst in der App darf. So sieht es heute ehrlicherweise aus, und genau deshalb lohnt ein Scope pro Grant weiterhin den Aufwand.
Das Vokabular ist bereits gemeinsam: Die Berechtigungen einer Rolle und die Scopes eines API-Keys stammen aus einem Alphabet, und genau deshalb lässt sich die Befugnis eines Keys als Schnittmenge beider berechnen. Ein MCP-Scope pro Grant wird in denselben Worten ausgedrückt sein, wenn er kommt.