Bubble MCP: контрольний список першого підключення

Агент на зразок Claude або ChatGPT, під'єднаний просто до no-code проєкту, швидко править логіку і структуру сторінок. Для стартапу чи першого MVP це дуже спокусливо. Можна перевірити гіпотезу, зібрати відгуки або показати демо інвесторам, і для цього не треба наймати технічну команду. Вайбкодинг і ШІ-агенти саме про таку швидкість.

Але швидкість не повинна шкодити проєкту. Офіційний сервер Bubble працює за адресою https://mcp.bubble.io/mcp, і через нього модель отримує широкі важелі всередині редактора. Без технічного бекграунду легко помилитися й випадково затерти налаштування робочих процесів. Тому перед першою сесією з bubble mcp я проходжу цей чекліст. Схожий розбір: Скільки коштує Bubble для MVP:.

1. Створіть тестову копію застосунку або ізольовану гілку

Моє головне правило: агент ніколи не торкається єдиного робочого екземпляра продукту.

Окрема тестова копія: на стартовому тарифі я роблю дублікат застосунку (Duplicate project) спеціально для експериментів з агентом. В інструкціях Bubble є попередження: дублювання може скопіювати і тестову, і живу базу даних. Тож переконайтеся, що в копії немає конфіденційних даних реальних користувачів.
Ізольована гілка: якщо ваш тариф підтримує розширений контроль версій, створіть від Main окрему гілку, наприклад feature/ai-experiment. Середовища Development і Live у Bubble й так суворо розділені. Окрема гілка додатково захищає основну версію розробки.
Чітко вказуйте ціль у промптах: клієнт обирає інструменти сам. Тому я завжди прямо пишу в запиті назву застосунку й гілки, щоб агент нічого не зробив на хибному проєкті. Схожий розбір: Bubble MCP server: три значення.

2. Перевірте обліковий запис та обмеження OAuth

До офіційного сервера підключаються через браузерну авторизацію OAuth/CIMD. Перед тим як її завершити, я дивлюся, як влаштовані права доступу:

Сервер діє від імені вашого облікового запису в Bubble. Він обмежений вашими правами колаборатора й лімітами тарифного плану застосунку.
Авторизація прив'язується до всього профілю Bubble, а не до одного проєкту. Якщо інструкції надто розмиті, агент через системні інструменти може побачити список інших застосунків, до яких у вас є доступ.
Під час першого входу давайте лише той мінімум доступу до даних, який запитує інтерфейс підключення. Якщо є можливість, беріть окремий тестовий акаунт колаборатора з мінімальними правами.
Якщо ви працюєте з інструментами командного рядка, наприклад Claude Code, на спільній машині, не ставте глобальний прапорець --scope user. Інакше доступ пошириться на всі проєкти системи. Схожий розбір: Claude Artifacts «beta upgrade» у.

3. Сховайте секретні ключі та захистіть API Connector

У MVP часто підключають платіжні системи або сторонні сервіси через API Connector. Тут одна з головних вразливостей:

Значення параметрів в API Connector, які не позначені як Private, агент може прочитати, коли досліджує структуру застосунку.
Я перевіряю всі заголовки й параметри запитів. Кожен секретний токен, ключ авторизації чи пароль має бути з увімкненою позначкою Private, або лежати в захищеному сховищі плагінів, звідки ключі не видаються у відкритому вигляді.
Платні плагіни треба купити до того, як агент їх встановить. Складні OAuth2-плагіни все одно доведеться налаштовувати вручну.
Згенеровані посилання для попереднього перегляду чи тестування мають обмежений термін дії, але достроково їх не відкличеш. Я ставлюся до них як до секретних даних.

4. Зафіксуйте точку відновлення перед початком сесії

Звичний Ctrl+Z (Undo) у візуальному редакторі Bubble не скасовує змін, які агент вніс через MCP. Тому шлях відкату я готую заздалегідь:

Створіть точку відновлення (Savepoint): перед першим завданням для агента вручну створіть точку збереження в історії версій. Скільки історії зберігається, залежить від тарифного плану застосунку.
Інструменти скасування агента: офіційний сервер дозволяє попросити агента відкотити власні дії або відновити збережену точку. Але видалені записи в базі даних так не повернеш.
Робота лише з тестовою базою даних: інструменти для роботи із записами задокументовані тільки для середовища Development. Змінювати записи в живій базі Live вони не призначені. Проте масове видалення чи створення тестових сутностей усе одно може зламати логіку вашого MVP.

5. Спочатку читання, потім модифікація

Я не починаю сесію з прохання переписати сторінку чи робочі процеси з нуля:

Спершу прошу агента про розвідку: перевірити підключення, прочитати список сторінок або отримати схему конкретного типу даних.
Перед тим як затвердити ланцюжок складних змін, уважно читаю, які саме інструменти агент збирається викликати.
Окремо розрізняю офіційний сервер Bubble і сторонні сервери спільноти (community MCP), які працюють через системний BUBBLE_API_TOKEN. Такі сервери часто мають прямий доступ до Data API / Workflow API. Якщо вказати їм URL продакшну, вони можуть зачепити бойові дані.

6. Фінальний ручний аудит перед релізом

У офіційного сервера Bubble є чіткі вбудовані обмеження: він не може розгортати в Live (deploy), не може зливати гілки (merge) і не читає логи серверних помилок.

Отже, за безпеку фінального релізу відповідаєте тільки ви. Я роблю так:

Особисто відкриваю редактор Bubble.
Переглядаю помилки у вбудованому Issue Checker.
Тестую створені агентом ланцюжки в режимі Preview.
Перевіряю Privacy Rules у вкладці Data, щоб випадково не відкрити доступ до інформації майбутніх користувачів.
Лише після повного ручного тестування зливаю зміни й вручну запускаю розгортання в Live.

Перед початком роботи відкрийте актуальну офіційну документацію Bubble про підтримувані клієнти й статус сервісу. Вимоги до авторизації краще перевіряти там, а не з пам'яті.