A què pot arribar
El límit real.
El teu rol decideix quines eines existeixen
El servidor actua com tu, contra la connexió que has activat. No hi ha cap compte de servei separat ni cap accés més ampli que el teu. Des que van arribar els rols, tampoc no hi ha cap accés més ampli que el teu ROL. La llista d'eines que rep un client es construeix a partir dels permisos que tens a l'espai de treball actiu, de manera que el client d'algú amb el rol Viewer no llista en absolut sendEmail, createRule ni sendWithTemplate.
Això és una cosa més forta que rebutjar la crida. Una eina que no és a la llista no és una eina sobre la qual el model raona, no consumeix context, i no es pot intentar en nom d'algú per després demanar-ne disculpes. També vol dir que un client que sembla buit sol ser un permís que no tens i no una funcionalitat que falta en aquest servidor, que és exactament el que whoAmI existeix per dir-te.
El registre i la invocació són dues barreres, i només la segona aguanta. La llista es construeix una sola vegada, quan s'obre la sessió, i setActiveConnection pot moure aquesta sessió a una bústia on pots fer menys coses, de manera que la llista queda desactualitzada per construcció i el protocol no té cap manera de retirar una eina a mitja sessió. Per això cada eina protegida torna a resoldre el teu rol contra la connexió ACTUAL abans d'executar-se. El registre és la cortesia; la invocació és el límit.
Un rebuig indica totes dues meitats, com a Refused (missing_permission): your role in this mailbox is Viewer, which does not include "Send email", de manera que un agent ho pot explicar a la persona per a qui treballa i deixar d'intentar-ho, en lloc de reintentar un error opac fins que algú es rendeix. Un rol canviat per un administrador mentre hi ha una sessió oberta arriba igual, ja a la crida següent.
Les adreces són l'altre eix i res d'això no les afecta. Un rol diu què pots fer; les adreces que t'han concedit diuen a quines bústies ho pots fer, i totes dues coses han de coincidir abans que surti un missatge.
El token en si continua sense scope
El que NO ha canviat és la concessió. El token que rep una aplicació arriba a tot el que permet el teu rol i no a un subconjunt que hagis triat en aprovar-lo, de manera que aprovar un client és aprovar-lo per a tot el que pots fer en aquest espai de treball. Se't mostra qui ho demana abans de concedir res, i Compte → Aplicacions connectades ho retira després, esborrant tots els tokens que té i l'aprovació que hi ha al darrere, però triar «només lectura, per a aquesta aplicació» no està construït.
Així, el sostre d'un client MCP és el TEU sostre. Restringir el que pot fer una aplicació vol dir restringir el rol de la persona que l'ha connectada, cosa que també restringeix el que aquesta persona pot fer dins l'aplicació. Aquesta és la forma honesta que té avui, i el motiu pel qual encara val la pena construir un scope per concessió.
El vocabulari ja és compartit: els permisos d'un rol i els scopes d'una clau API surten d'un mateix alfabet, que és el que fa que l'autoritat d'una clau es pugui calcular com la intersecció de tots dos. Un scope MCP per concessió s'expressarà amb les mateixes paraules quan arribi.