До чего он достаёт
Честная граница.
Ваша роль решает, какие инструменты существуют
Сервер действует от вашего имени, над тем подключением, которое вы сделали активным. Отдельной служебной учётной записи нет, и доступа шире вашего собственного тоже нет. С появлением ролей нет и доступа шире вашей РОЛИ. Список инструментов, который получает клиент, строится из разрешений, которыми вы обладаете в активном рабочем пространстве, поэтому у клиента участника с ролью Viewer sendEmail, createRule и sendWithTemplate вообще не перечислены.
Это сильнее, чем отказ на вызове. Инструмент, которого нет в списке, — это инструмент, о котором модель не рассуждает, который не ест контекст и который нельзя попытаться применить от чьего-то имени, а потом за это извиняться. Это также значит, что пустоватый на вид клиент — обычно разрешение, которого у вас нет, а не функция, которой у этого сервера нет; ровно для того, чтобы сказать вам это, и существует whoAmI.
Регистрация и вызов — два заслона, и держит только второй. Список строится один раз, при открытии сессии, а setActiveConnection может перевести эту сессию в почтовый ящик, где вам позволено меньше, поэтому список устаревает по построению, а у протокола нет способа отозвать инструмент посреди сессии. Поэтому каждый закрытый разрешением инструмент перед запуском заново разрешает вашу роль относительно ТЕКУЩЕГО подключения. Регистрация — это вежливость; вызов — это граница.
Отказ называет обе половины, как в Refused (missing_permission): your role in this mailbox is Viewer, which does not include "Send email", чтобы агент мог объяснить это человеку, на которого работает, и перестать пытаться, а не повторять непрозрачную ошибку, пока кто-нибудь не сдастся. Роль, изменённая администратором при открытой сессии, доходит так же — на самом следующем вызове.
Адреса — вторая ось, и всё это их не касается. Роль говорит, что вам можно делать; выданные вам адреса — к каким почтовым ящикам вы можете это делать, и оба должны совпасть, прежде чем письмо уйдёт.
Сам токен по-прежнему без скоупов
Что НЕ изменилось — это выдача доступа. Токен, который получает приложение, достаёт до всего, что позволяет ваша роль, а не до подмножества, выбранного вами при одобрении, поэтому одобрить клиент — значит одобрить ему всё, что вы можете делать в этом рабочем пространстве. Перед тем как что-либо выдать, вам показывают, кто запрашивает, а раздел Аккаунт → Подключённые приложения затем удаляет приложение, удаляя все его токены и стоящее за ними одобрение, но выбора «только чтение, для этого приложения» не построено.
Так что потолок MCP-клиента — это потолок ВАС САМИХ. Сузить то, что может приложение, значит сузить роль человека, который его подключил, а это сузит и то, что он может в самом приложении. Такова честная форма этого сегодня и причина, по которой скоуп на конкретную выдачу всё ещё стоит построить.
Словарь уже общий: разрешения роли и скоупы ключа API взяты из одного алфавита — именно это делает полномочия ключа вычислимыми как пересечение этих двух. Скоуп MCP на конкретную выдачу, когда появится, будет выражен теми же словами.