Hasta dónde llega
El límite honesto.
Tu rol decide qué herramientas existen
El servidor actúa como tú, sobre la conexión que hayas activado. No hay una cuenta de servicio aparte ni un acceso más amplio que el tuyo. Desde que existen los roles, tampoco hay un acceso más amplio que tu ROL. La lista de herramientas que recibe un cliente se construye a partir de los permisos que tienes en el espacio de trabajo activo, así que el cliente de quien tiene el rol Viewer no enumera sendEmail, createRule ni sendWithTemplate en absoluto.
Eso es algo más fuerte que rechazar la llamada. Una herramienta ausente de la lista no es una herramienta sobre la que el modelo razone, no consume contexto y no se puede intentar en nombre de alguien para luego disculparse. También significa que un cliente que parece vacío suele ser un permiso que no tienes y no una función que le falte a este servidor, que es exactamente lo que whoAmI existe para decirte.
El registro y la invocación son dos barreras, y solo la segunda aguanta. La lista se construye una vez, al abrirse la sesión, y setActiveConnection puede mover esa sesión a un buzón donde puedas hacer menos cosas, así que la lista queda desactualizada por construcción y el protocolo no tiene forma de retirar una herramienta a mitad de sesión. Por eso cada herramienta protegida vuelve a resolver tu rol contra la conexión ACTUAL antes de ejecutarse. El registro es la cortesía; la invocación es el límite.
Un rechazo nombra las dos mitades, como en Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”, para que un agente pueda explicárselo a la persona para la que trabaja y dejar de intentarlo, en vez de reintentar un error opaco hasta que alguien se rinda. Un rol que un administrador cambia mientras hay una sesión abierta llega igual, en la siguiente llamada.
Las direcciones son el otro eje y nada de esto las afecta. Un rol dice lo que puedes hacer; las direcciones que te han concedido dicen sobre qué buzones puedes hacerlo, y ambos tienen que coincidir antes de que salga un mensaje.
El token en sí sigue sin scopes
Lo que NO ha cambiado es la concesión. El token que recibe una aplicación alcanza todo lo que permite tu rol y no un subconjunto que tú eligieras al aprobarlo, así que aprobar un cliente es aprobarlo para todo lo que puedas hacer en ese espacio de trabajo. Se te muestra qué lo está pidiendo antes de conceder nada, y Cuenta → Aplicaciones conectadas lo elimina después, borrando todos los tokens que tiene y la aprobación que hay detrás, pero elegir «solo lectura, para esta aplicación» no está construido.
Así que el techo de un cliente MCP es TU techo. Reducir lo que puede hacer una aplicación significa reducir el rol de la persona que la conectó, lo que reduce también lo que esa persona puede hacer en la aplicación. Esa es la forma honesta que tiene hoy, y la razón por la que un scope por concesión sigue mereciendo la pena.
El vocabulario ya es común: los permisos de un rol y los scopes de una clave de API salen de un mismo alfabeto, que es lo que hace que la autoridad de una clave sea calculable como la intersección de ambos. Un scope MCP por concesión se expresará con las mismas palabras cuando llegue.