MCP — Model Context Protocol — дозволяє AI-агентам робити рантаймові виклики інструментів до зовнішніх сервісів. Figma випускає офіційний MCP-сервер, і спільнота створила ще кілька. Ідея: ваш агент може запитувати Figma дані дизайну безпосередньо, на вимогу, прямо в середині розмови. Без кроку з експортом. Завжди живі дані.

figmascope робить протилежний архітектурний вибір: експортуй одного разу, постачай бандл, більше не підключайся. Це справді різні підходи з різними наслідками. Ось що кожен із них реально коштує і що дає.

Що таке MCP-сервер Figma

Model Context Protocol — відкритий стандарт Anthropic для підключення AI-агентів до зовнішніх інструментів через серверний інтерфейс. MCP-сервер надає типізовані інструменти, які агент може викликати: "get_file", "get_node", "get_styles" тощо. Коли агенту потрібен контекст дизайну — він викликає інструмент, MCP-сервер звертається до API Figma, і результат повертається як контекст для поточного промпта.

Офіційний MCP-сервер Figma охоплює читання файлів, інспекцію вузлів, отримання компонентів та доступ до коментарів. Спільнотні MCP-сервери (їх кілька на GitHub) розширюють це кастомними схемами, додатковими трансформаціями або вужчими скоупами, оптимізованими для конкретних воркфлоу агентів.

Для використання будь-якого MCP-сервера Figma ви налаштовуєте його у клієнті агента (Claude Desktop, Cursor, Continue тощо), надаєте PAT Figma, і сервер запускається як локальний процес. Коли агенту потрібен контекст Figma — він викликає інструмент. Нічого явно не експортуєте — агент сам отримує те, що йому потрібно.

Модель MCP на практиці

Типовий воркфлоу Figma з MCP виглядає так: відкриваєте Cursor, починаєте розмову, говорите "реалізуй екран оформлення замовлення з цього файлу Figma" — агент викликає get_file, отримує дерево вузлів і має дані дизайну в контексті. Якщо потім скажете "дизайнер оновив токени кнопки" — агент може знову зробити запит і отримати свіжі дані.

Ця модель живого підключення є реальною і приваблює в деяких воркфлоу. Агент працює з поточними даними. Ви не керуєте артефактами експорту. Між "дизайнер вніс зміни" та "агент їх бачить" немає ручного кроку.

Де MCP виграє

Живі дані без кроку з експортом. Агент отримує поточний стан на вимогу. Якщо дизайн змінився десять хвилин тому — агент може це побачити. figmascope потребує ручного повторного експорту для фіксації змін.

Розмовне дослідження дизайну. "Який колір кнопки CTA?" "Скільки екранів посилаються на цей компонент?" З MCP агент може відповісти, викликавши Figma. З бандлом відповідь актуальна лише на момент останнього експорту.

Редагування Figma напряму. Деякі MCP-сервери надають операції запису — створення вузлів, оновлення властивостей, публікація коментарів. Це можливо лише з живим підключенням. Статичний бандл не має шляху запису.

Без ручного воркфлоу. Для розробників, що вже використовують налаштування агентів із MCP, відсутність кроку з експортом — одна річ менше, про яку треба пам'ятати. Управління контекстом делеговано агенту.

Де MCP програє

Модель живого підключення має архітектурні витрати, які легко недооцінити.

Стан прив'язаний до сесії. Виклики MCP відбуваються в контексті сесії розмови. Дані, отримані агентом у сесії A, недоступні в сесії B без повторного запиту. Починаєте новий чат — агент починає з нуля. Бандл figmascope зберігається між сесіями, між розробниками та між інструментами — це просто файли.

Непрозорий для git. Артефакту немає. Нічого не комітити. Контекст дизайну, що інформував ваш код, не живе у репозиторії. Через шість місяців, якщо захочете зрозуміти, як виглядав дизайн під час створення компонента, — запису немає. З бандлом у репозиторії у вас є git-історія дизайнерського наміру.

Потребує підключення. MCP потребує запущеного сервера, живого підключення до API Figma та PAT із доступом. Мережа впала, API Figma недоступний, PAT прострочений — агент без контексту. Бандл працює в літаку.

Отримання залежить від моделі. Те, що агент запитує через MCP, залежить від того, що він вирішить запитати. Він може не отримати значення токенів. Може не підтягнути інвентар компонентів. Може запросити лише піддерево вузлів, яке вважає за потрібне, пропустивши просторовий контекст сусідніх вузлів. Отримання є ймовірнісним, а не детермінованим. figmascope отримує все, щоразу, за фіксованою схемою.

Складніше тестувати та відтворювати. "Мій агент побудував цей компонент із цих даних Figma в цей момент часу" — з MCP це не верифіковано. Запит є ефемерним. З бандлом можна відтворити точно: той самий бандл, той самий агент, той самий промпт — детермінований вивід. Це важливо для дебагінгу, код-рев'ю та відповідальності за релізи.

Тиск на контекстне вікно. Наївний виклик get_file для складного файлу Figma повертає величезне JSON-дерево. Агенти мають робити вибіркові виклики інструментів, щоб залишатися в межах контекстного бюджету. Це вводить евристики та судження, які можуть помилятися. figmascope попередньо обробляє дерево в структурований IR лише з потрібним, відомого обмеженого розміру.

Бандл-модель figmascope: фіксуй раз, постачай назавжди

figmascope експортує .zip із простих файлів через REST API Figma — без плагінів, без сервера, запускається у вашому браузері. Бандл містить:

Після експорту бандл є самодостатнім і незмінним. Він потрапляє у ваш репозиторій поруч із кодом, який описує. Будь-який агент, будь-яка сесія, будь-який розробник, будь-який CI-джоб може його прочитати. Підключення ні до чого не потрібне.

Версійовані дифи: порівнюємо бандли як код

Це найсильніший аргумент бандл-моделі. Оскільки вивід — структурований JSON та Markdown — його можна дифати.

Експортуйте бандл перед дизайн-спринтом. Експортуйте після. Запустіть diff для tokens.json:

- "spacing.4": "16px"
+ "spacing.4": "14px"

Це порушення у вашій шкалі відступів. Воно видиме, перевіряється і прив'язане до коміту. З MCP та сама зміна відбувається непомітно — наступного разу, коли агент зробить запит, він отримає нове значення, і жодного запису про зміну не буде.

Це можна запустити як gate для PR: експортувати бандл як частину передачі дизайну, закомітити, вимагати погодження дизайнера і розробника на диф перед початком реалізації. Це специфікація дизайну як код. MCP не має еквівалента.

Аргумент детермінізму

Та сама версія файлу Figma + той самий експорт figmascope = той самий бандл. Щоразу. Схема IR фіксована. Логіка пошуку токенів детермінована. Витяг ключів рядків базується на правилах.

Отримання через MCP не є детермінованим. Агент вирішує, що запросити. Різні агенти, різні формулювання промптів, різні контекстні бюджети — різна поведінка при запиті. Вивід залежить від моделі.

Для продуктової UI-кодогенерації детермінізм важливий. Ви хочете, щоб специфікація, що породила компонент, була відтворюваною. Хочете мати змогу перегенерувати компонент із тих самих вхідних даних і отримати консистентний результат. Бандли це підтримують. Сесії MCP — ні.

Порівняльна таблиця

Параметр Figma MCP Бандл figmascope
Актуальність даних Завжди живі — отримує поточний стан Figma Знімок — настільки свіжий, наскільки останній експорт
Потрібен крок із експортом Ні Так — одноразовий на версію дизайну
Версійний контроль Ні — артефакту немає Так — бандл — дифабельний JSON + Markdown
Зберігається між сесіями Ні — потрібно повторно запитувати в кожній сесії Так — файли зберігаються безстроково
Офлайн-режим Ні Так
Детермінований вивід Ні — отримання залежить від моделі Так — однакові вхідні дані → однаковий бандл завжди
Тиск на контекстне вікно Високий — сирий Figma JSON великий і неструктурований Низький — IR попередньо оброблений, обмежений розмір
Операції запису у Figma Так (деякі MCP-сервери) Ні — лише читання
Специфікація дизайну у git-історії Ні Так — комітіть бандл, відстежуєте історію дизайну
Потрібне налаштування агента Так — налаштуйте MCP-сервер для кожного клієнта Ні — підходить будь-який агент, що читає файли
Ключі рядків для i18n Відсутні у базовій схемі Figma MCP Так — stringRef.key у IR + strings.json
Просторовий / компонувальний IR Сире дерево вузлів Figma (без семантичних типів розкладки) Типізований IR: stack / overlay / absolute / leaf
Пошук токенів Variables якщо налаштовано; інакше сирі значення Variables → вивід за частотою → відсутні

MCP сяє для "редагувати Figma наживо" — бандли сяють для "будувати продуктовий UI"

Ось чесне резюме. Якщо ваш воркфлоу — розмовне дослідження дизайну: "змінити цей компонент", "анотувати цей екран", "які кольорові токени на цьому фреймі" — живе підключення MCP є правильною моделлю. Агент є співавтором дизайнерського процесу і потребує поточних даних для цього.

Якщо ваш воркфлоу — будування продуктового UI з фіналізованого (або близького до фінального) дизайну: реалізація компонентів, підключення стану, написання тестів — бандл-модель краща. Ви хочете специфікацію, закріплену у репозиторії, дифабельну між ітераціями дизайну, зрозумілу будь-якому агенту без налаштування та достатньо детерміновану, щоб будувати на її основі.

Обидві моделі є взаємодоповнювальними. Використовуйте MCP, коли дизайн у розробці та ви ітеруєте спільно. Експортуйте бандл figmascope, коли дизайн стабільний і ви передаєте його інженерам для реалізації. Бандл стає джерелом правди, на основі якого будується реалізація — відстежуваним, перевіряємим, відтворюваним.