Current plan level (Free, Team, Business, or Enterprise: Pricing | Retool):
Monthly/Annual (if Team or Business):
Version of Retool (if self-hosted):
Question / Description:
MCP was disabled for our instance due to security concerns about the level of access available through the integration. We’re now considering re-enabling it for a limited group of users.
Any guidance on the recommended configuration would be appreciated.
After disabling Retool's MCP server org-wide over concerns about the breadth of access it grants, there's interest in re-enabling it for only a limited group of users, and guidance on the recommended configuration is being requested (Cloud instance, Business plan).
AI Response
Access through Retool's MCP server is already governed by each user's existing permissions rather than being all-or-nothing. When a user authenticates via OAuth, they select scopes (mcp:read, mcp:write, mcp:admin), and a user can never be granted a scope beyond what their Retool account already permits — MCP only exposes objects (apps, resources, workflows) the user can already view, and only organization administrators can obtain the mcp:admin scope. To limit MCP to a select group, scope down those users' existing permission groups/roles accordingly, and note some admin tools (e.g., audit logs) require Business/Enterprise while a few (groups) are Enterprise-only. Tightening the underlying permission groups is the recommended way to control what any enabled user can reach through MCP.
Sources
MCP tools | Retool Docs
Confirms MCP access is scope-based and can never exceed a user's existing account permissions, so MCP exposure is controlled through each user's permission groups and roles. MCP server for Retool
Official Retool announcement of the MCP server that outlines how it is enabled, authenticated, and scoped to a user's existing organization permissions.
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a , , or . Or by marking this post as the "Solution"! Let us know if you have any feedback here.
Since these are personal emails, please send them to me by DM here rather than in this thread. I’ll turn it on for those users and let you know when it’s done!
What happens to an already-authorized MCP client when someone is removed from that per-user allowlist? Does its next tool call get rejected immediately, or is token/session revocation a separate step?
The linked tools reference explains scopes and existing account permissions, but I couldn’t find the offboarding behavior. That seems worth clarifying alongside the rollout instructions, especially while admins need support to change the list.
Great question! When a user is removed from the list, their existing MCP connection stops working on its own, usually within about 5 minutes. The connection’s access is re-checked regularly, so there’s no separate revocation step. Let me know if you have any other questions!