Wat het kan bereiken
De eerlijke grens.
Je rol bepaalt welke tools bestaan
De server handelt als jou, tegen de connection die je actief hebt gemaakt. Er is geen apart serviceaccount en geen bredere toegang dan de jouwe. Sinds rollen zijn uitgerold, is er ook geen bredere toegang dan je ROL. De toollijst die een client krijgt wordt opgebouwd uit de permissies die jij in de actieve workspace hebt, dus de client van een viewer toont sendEmail, createRule of sendWithTemplate helemaal niet.
Dat is sterker dan de aanroep weigeren. Een tool die niet in de lijst staat is geen tool waarover het model redeneert, vreet geen context, en kan niet namens iemand worden geprobeerd om er daarna excuses voor te maken. Het betekent ook dat een leeg ogende client meestal een permissie is die je niet hebt in plaats van een functie die deze server mist, en precies daarvoor bestaat whoAmI.
Registratie en aanroep zijn twee poorten, en alleen de tweede houdt stand. De lijst wordt één keer opgebouwd, wanneer de sessie opent, en setActiveConnection kan die sessie verplaatsen naar een mailbox waarin je minder mag, dus de lijst is per definitie verouderd en het protocol heeft geen manier om een tool midden in een sessie in te trekken. Elke afgeschermde tool bepaalt daarom je rol opnieuw tegen de HUIDIGE connection voordat hij draait. Registratie is de beleefdheid; de aanroep is de grens.
Een weigering noemt beide helften, zoals in Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”, zodat een agent het kan uitleggen aan de persoon voor wie hij werkt en kan stoppen met proberen, in plaats van een ondoorzichtige fout te blijven herhalen tot iemand het opgeeft. Een rol die een beheerder wijzigt terwijl een sessie open is, landt op dezelfde manier, bij de allereerste volgende aanroep.
Adressen zijn de andere as en worden hier door niets van geraakt. Een rol zegt wat je mag doen; de adressen die aan jou zijn toegekend zeggen op welke mailboxen je het mag doen, en beide moeten het eens zijn voordat een bericht uitgaat.
Het token zelf heeft nog steeds geen scope
Wat NIET is veranderd, is de grant. Het token dat een app krijgt reikt tot alles wat je rol toestaat en niet tot een deelverzameling die je tijdens het goedkeuren hebt gekozen, dus een client goedkeuren is hem goedkeuren voor alles wat jij in die workspace kunt. Je krijgt te zien wat erom vraagt voordat er iets wordt verleend, en Account → Connected apps verwijdert hem achteraf, waarbij elk token dat hij houdt en de goedkeuring erachter worden gewist, maar “alleen lezen, voor deze app” kiezen is niet gebouwd.
Dus het plafond van een MCP-client is jouw plafond. Beperken wat een app kan doen betekent de rol beperken van de persoon die hem heeft verbonden, wat ook beperkt wat diegene in de app kan. Dat is vandaag de eerlijke vorm ervan, en de reden dat een scope per grant nog steeds de moeite waard is om te bouwen.
De woordenschat is al gedeeld: de permissies van een rol en de scopes van een API-key komen uit één alfabet, en dat maakt de bevoegdheid van een key berekenbaar als de doorsnede van de twee. Een MCP-scope per grant zal in dezelfde woorden worden uitgedrukt zodra hij er is.