Bubble MCP Account-Wide vs Per-App: How to Read This Week’s Feedback Thread So an Agent Doesn’t Jump Apps
When you connect Bubble MCP to build an MVP with AI agents, the agent gets your whole account, not a single app. Here's how I read the community feedback, where the cross-app risk is, and how I'd protect your projects.
When I launch an MVP with nocode tools and vibe-coding, speed matters most. I want to test the idea, get first feedback, and iterate fast. The official Bubble MCP lets you connect external AI agents like Claude or Cursor straight to your workspace. It's easy to assume the agent only sees the project you're building. Right now that assumption is wrong. A closer look: From the AMA: Conversational Generation.
This week's digest pointed me to a community thread on the Bubble forum about this exact choice: account-wide access or per-app scoping. Same topic: Bubble Community on Price Transparency.
How Official Bubble MCP Authenticates Today
The official Bubble documentation says the MCP server authenticates as the signed-in Bubble user, not as one isolated app. The list_apps tool returns every app that user can access. That includes shared client apps and team projects where you're a collaborator.
For multi-app accounts, the docs offer one guardrail, and it's operational: name the target app explicitly in your prompt. Production has no server-enforced per-app OAuth scope and no app-specific MCP endpoint.
Reading the Feedback Thread
In the official "Bubble MCP Feedback" forum thread, developers raised concerns right away. If an account holds dozens of apps, relying only on prompt instructions leaves room for the model to get it wrong. People asked for granular controls in an app's settings, so you could restrict scope by app, data type, or field.
Bubble staff replied that the team is working on improvements. Separately, in a security Q&A thread, someone asked whether an MCP connection could be limited to a single app or set to read-only. Bubble staff answered: "Not yet, but we’re looking into adding that with per-app configuration!" I don't read that as a final verdict or a shipped feature. It's an acknowledged direction on the roadmap. The current release is still account-wide. Same topic: Bubble MCP: A First-Connection Checklist.
Where the Actual Risk Lies
If you're a non-technical founder, the useful thing is knowing what an agent can and can't touch:
- Live database isolation. The official MCP record-editing tools work on the development database. They can't directly change live user records. Deploying to live is still a manual step in Bubble.
- Cross-app dev changes. With an ambiguous prompt or a confused model, an agent can pick the wrong app identifier. Its permissions mirror your user access, so it could change editor workflows, database structures, or UI components in the development branch of a project you never meant to touch.
My Practical Rules for Solo Builders
Here's how I'd move fast without putting existing apps at risk:
- Start in a sandbox MVP. Test your MCP workflows on an isolated test app, where a mistake has zero blast radius.
- Use account boundaries for production safety. If your main Bubble account holds production systems or client workspaces, think about a dedicated second account that's invited only to the MVP you're vibe-coding.
- Go account-wide only on purpose. Keep broad account access only when your workflow really needs context from several apps. Then always tell the agent clearly which app it's allowed to touch.