Bubble MCP: account-wide чи per-app — як читати feedback thread, щоб агент не перескочив на інший застосунок
Bubble MCP дає AI-агенту доступ до всього акаунту, а не до одного проєкту. Я розібрав обговорення на форумі: де реальний ризик, коли агент може переплутати застосунки, і яких правил я раджу триматися соло-фаундерам, які швидко збирають MVP.
Коли я збираю MVP на nocode та вайбкодінгу, мені треба одне: перевірити ідею якнайшвидше. Офіційний Bubble MCP тут справді допомагає. Зовнішній AI-агент, наприклад у Claude чи Cursor, бачить ваш проєкт напряму і може вносити в нього зміни. Але на старті легко вирішити, що агент бачить лише той застосунок, з яким ви зараз працюєте. Це не так. Схожий розбір: Bubble MCP server: три значення.
Цього тижня я виніс у дайджесті окремим пунктом тему з офіційного форуму: доступ через Bubble MCP працює на рівні всього акаунта (account-wide), а не одного застосунку (per-app). Поруч із цим: Bubble, Reverse.dev for Teams та.
Як зараз працює офіційний Bubble MCP
За офіційною документацією Bubble, MCP авторизується від імені користувача, який увійшов в акаунт, а не під окремий вибраний застосунок. Інструмент list_apps повертає всі застосунки, до яких у вас є доступ. Сюди входять і спільні проєкти, де ви колаборатор. Схожий розбір: Скільки коштує Bubble для MVP:.
Для акаунтів із кількома застосунками документація пропонує лише один запобіжник, і він текстовий: явно вказувати в промпті назву потрібного застосунку. Окремого per-app OAuth scope чи обмеження на боці сервера для конкретного застосунку в продакшені зараз немає.
Що обговорюють у feedback thread
У гілці про Bubble MCP люди одразу побачили, чим це небезпечно. Коли на акаунті багато проєктів (в одному прикладі 16 різних застосунків), покластися тільки на правильну назву в промпті означає майже не мати захисту. Спільнота прямо просить гранулярні підключення з налаштувань конкретного застосунку: на рівні застосунку, типів даних або полів.
Представники Bubble відповіли, що команда працює над поліпшеннями MCP. Коли їх спитали, чи можна обмежити підключення одним застосунком або режимом read-only, відповідь була така: поки що ні, але варіант із per-app конфігурацією розглядають. Я читаю це як план, а не як готову функцію і не як остаточне рішення платформи.
Де реальний ризик для творця MVP
Якщо ви нетехнічний фаундер, ризик краще оцінювати тверезо, без паніки:
- Live-дані захищені базовими обмеженнями. MCP-інструменти для роботи із записами за замовчуванням працюють з development database. Реальних даних користувачів на продакшені вони напряму не змінюють. Деплой у live теж лишається ручною дією.
- Ризик для dev-версій інших застосунків. Якщо промпт неоднозначний або модель галюцинує, агент може помилитися з ідентифікатором застосунку. Тоді він змінить workflows, інтерфейс чи типи даних зовсім іншого проєкту у вашому акаунті.
Моє практичне правило для соло та вайбкодерів
Я раджу простий підхід, щоб швидко тестувати гіпотези й не зламати те, що вже працює:
- Тестовий застосунок за замовчуванням. Починайте експерименти з MCP на чистому тестовому проєкті, де помилка агента нічого не зруйнує.
- Окремий акаунт для критичних проєктів. Якщо у вашому основному Bubble-акаунті є клієнтські проєкти або бізнес, який уже працює, найнадійніший захист зараз — підключати агента через окремий акаунт із доступом тільки до одного MVP.
- Account-wide тільки свідомо. Широкий доступ я вмикав би лише тоді, коли справді потрібен спільний контекст кількох застосунків одночасно. І в такому разі завжди контролюйте, що саме ви просите в агента.