Ao que consegue chegar
A fronteira honesta.
A sua função decide que ferramentas existem
O servidor age em seu nome, sobre a ligação que tornou ativa. Não existe uma conta de serviço separada nem acesso mais amplo do que o seu. Desde que as funções entraram em funcionamento, também não existe acesso mais amplo do que a sua FUNÇÃO. A lista de ferramentas dada a um cliente é construída a partir das permissões que detém no espaço de trabalho ativo, pelo que o cliente de um visualizador não lista de todo sendEmail, createRule ou sendWithTemplate.
Isso é mais forte do que recusar a chamada. Uma ferramenta ausente da lista não é uma ferramenta sobre a qual o modelo raciocine, não consome contexto, e não pode ser tentada em nome de alguém para depois se pedir desculpa. Significa também que um cliente que parece vazio é normalmente uma permissão que não tem, e não uma funcionalidade que falta a este servidor, que é exatamente o que o whoAmI existe para lhe dizer.
O registo e a invocação são duas barreiras, e só a segunda é que segura. A lista é construída uma vez, quando a sessão abre, e o setActiveConnection pode mover essa sessão para uma caixa de correio onde pode fazer menos, pelo que a lista fica desatualizada por construção e o protocolo não tem forma de retirar uma ferramenta a meio da sessão. Por isso, todas as ferramentas protegidas voltam a resolver a sua função contra a ligação ATUAL antes de correrem. O registo é a cortesia; a invocação é a fronteira.
Uma recusa nomeia as duas metades, como em Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”, para que um agente a possa explicar à pessoa para quem trabalha e deixe de tentar, em vez de repetir um erro opaco até alguém desistir. Uma função alterada por um administrador com a sessão aberta chega da mesma forma, logo na chamada seguinte.
Os endereços são o outro eixo e nada disto os afeta. Uma função diz o que pode fazer; os endereços que lhe foram atribuídos dizem em que caixas de correio o pode fazer, e os dois têm de concordar antes de uma mensagem sair.
O token em si continua sem âmbito
O que NÃO mudou foi a autorização. O token que uma aplicação recebe alcança tudo o que a sua função permite, e não um subconjunto que tenha escolhido ao aprová-la, pelo que aprovar um cliente é aprová-lo para tudo o que consegue fazer nesse espaço de trabalho. É-lhe mostrado o que está a pedir antes de algo ser concedido, e Conta → Aplicações ligadas remove-o depois, apagando todos os tokens que detém e a aprovação que está por trás, mas escolher “apenas leitura, para esta aplicação” não está construído.
Por isso, o teto de um cliente MCP é o teto de SI. Restringir o que uma aplicação pode fazer significa restringir a função de quem a ligou, o que também restringe o que essa pessoa pode fazer na aplicação. Esta é a forma honesta disto hoje, e a razão por que vale a pena construir um âmbito por autorização.
O vocabulário já é partilhado: as permissões de uma função e os âmbitos de uma chave de API saem do mesmo alfabeto, que é o que torna a autoridade de uma chave calculável como a interseção das duas. Um âmbito MCP por autorização será expresso nas mesmas palavras quando chegar.