Why
Third-party MCP clients connect with a token that is either read-only or full access, applied to every selected team. Users can't allow an agent to build on one team while keeping it away from another, or allow changes while blocking actions that take effect immediately. This is needed before tools that delete things can be added safely: the user has to opt in explicitly.
What
When connecting an MCP client, the user sets permissions per tool group (Platform, Flow Building) and per category (Read, Write, Destructive), as a default plus optional per-team overrides. Platform includes the platform UI tools. The category of a tool comes from its MCP annotations: readOnlyHint is Read, destructiveHint is Destructive, anything else is Write. Permissions only narrow what the user's team role already allows.
Scope
- In: MCP OAuth tokens created from the MCP connect page.
- Out: plain PATs (keep
readOnly), editing permissions after connecting, per-tool permissions, application-level permissions, enabling agent auto-deploy from the MCP page.
Why
Third-party MCP clients connect with a token that is either read-only or full access, applied to every selected team. Users can't allow an agent to build on one team while keeping it away from another, or allow changes while blocking actions that take effect immediately. This is needed before tools that delete things can be added safely: the user has to opt in explicitly.
What
When connecting an MCP client, the user sets permissions per tool group (Platform, Flow Building) and per category (Read, Write, Destructive), as a default plus optional per-team overrides. Platform includes the platform UI tools. The category of a tool comes from its MCP annotations:
readOnlyHintis Read,destructiveHintis Destructive, anything else is Write. Permissions only narrow what the user's team role already allows.Scope
readOnly), editing permissions after connecting, per-tool permissions, application-level permissions, enabling agent auto-deploy from the MCP page.