Acho que a trava mais concreta aí é o escopo do cliente novo. Se o agente só consulta metadado, pede só drive.metadata.readonly (ou drive.file, que limita aos arquivos que o próprio app abriu ou criou). Na API REST do Drive isso já faz qualquer escrita voltar 403 por escopo insuficiente, e imagino que o MCP faça a mesma checagem em cima do token. Aí o teste negativo que você descreveu também confere o token, além da lista de ferramentas exposta.
1
1
Bem lembrado! Limitar o escopo no OAuth (drive.metadata.readonly ou drive.file) é sem dúvida a barreira mais sólida na base, garantindo que o próprio Google barre qualquer escrita indevida com um 403.
O ponto de combinar isso com a restrição da lista de ferramentas no MCP (ou via proxy) entra quando o escopo ainda é amplo demais para a tarefa. Por exemplo, se o agente precisar criar um relatório (drive.file), mas você não quiser que ele apague ou sobrescreva outros arquivos que o app criou. Nesse cenário, o escopo garante a fronteira no token e a lista enxuta de ferramentas trava a operação específica. No fim, o teste negativo acaba validando as duas camadas!
1
sim, nesse caso do drive.file faz sentido, porque o escopo deixa apagar qualquer arquivo que o app criou e só a lista de ferramentas segura o delete.