The MCP server holds no permissions of its own. API_TOKEN is an ordinary API token, and the assistant inherits exactly the access of the account that created it, in one workspace.
So the question is not what the server can do. It is what the token can do.
A token created by an Owner lets an assistant do everything an Owner can, including managing members and billing. Give an assistant a token from an account with the access it actually needs.
Practical advice
Make a token for the purpose. Name it after the assistant rather than the person, so revoking it later is obvious.
Use the least-privileged account you can. If the assistant is meant to answer questions about screens and update content, a User account covers it.
Revoke rather than rotate when in doubt. Deleting the token stops the assistant immediately, and creating another takes seconds.
What the annotations do not do
The destructiveHint flags tell a client which tools change or delete data, so it can ask before calling them. They are advisory. A client that ignores them still gets through, because the enforcement is the token, not the hint.
That is the right way round, but it means a confirmation prompt is a convenience rather than a control.
Scope of the memory
The server remembers which app it published under which name, on that machine. That memory sits next to the token file and is scoped by API host and token, so two workspaces on one machine do not see each other’s.