MCP — Model Context Protocol — позволяет AI-агентам делать runtime-вызовы инструментов к внешним сервисам. Figma выпустила официальный MCP-сервер, и сообщество создало ещё несколько. Идея: ваш агент может запрашивать данные дизайна из Figma напрямую, по требованию, в середине разговора. Без шага экспорта. Всегда живые данные.

figmascope делает противоположную архитектурную ставку: экспортировать один раз, отправить бандл, больше никогда не подключаться. Это подлинно разные подходы с разными последствиями. Вот что каждый из них реально стоит и даёт.

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

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

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

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

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

Типичный MCP-рабочий процесс с Figma выглядит так: вы открываете Cursor, начинаете разговор, говорите «реализуй экран оформления заказа из этого файла Figma», и агент вызывает get_file, получает дерево узлов и имеет данные дизайна в контексте. Если потом вы говорите «дизайнер обновил токены кнопки», агент может запросить снова и получить свежие данные.

Эта модель живого подключения реальна и привлекательна для некоторых рабочих процессов. Агент работает с актуальными данными. Вы не управляете артефактами экспорта. Между «дизайнер запушил изменение» и «агент его видит» нет ручного шага.

Где MCP выигрывает

Живые данные, без шага экспорта. Агент запрашивает текущее состояние по требованию. Если дизайн изменился десять минут назад, агент может это увидеть. figmascope требует ручного переэкспорта для фиксации изменений.

Разговорное исследование дизайна. «Какой цвет у CTA-кнопки?» «Сколько экранов ссылается на этот компонент?» С MCP агент может ответить, вызвав Figma. С бандлом ответ актуален только на момент последнего экспорта.

Прямое редактирование Figma. Некоторые MCP-серверы предоставляют операции записи — создание узлов, обновление свойств, публикацию комментариев. Это возможно только с живым подключением. У статичного бандла нет пути записи.

Без ручного рабочего процесса. Для разработчиков, уже использующих агентные установки с MCP, отсутствие шага экспорта означает одну вещь меньше, о которой нужно помнить. Управление контекстом делегируется агенту.

Где MCP проигрывает

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

Состояние, привязанное к сессии. Вызовы MCP происходят в контексте сессии разговора. Данные, которые агент получил в сессии A, недоступны в сессии B без повторного запроса. При начале нового чата агент начинает с нуля. Бандл figmascope сохраняется между сессиями, между разработчиками и между инструментами — это просто файлы.

Непрозрачен для git. Нет артефакта. Нечего коммитить. Контекст дизайна, который определил ваш код, не живёт в репозитории. Через шесть месяцев, если вы захотите понять, как выглядел дизайн при создании компонента, записи нет. С бандлом в репозитории у вас есть история коммитов дизайн-намерения.

Требует подключения. MCP нужен работающий сервер, живое подключение к Figma API и PAT с доступом. Сеть упала, Figma API лежит, PAT истёк — у агента нет контекста. Бандл работает в самолёте.

Зависящий от модели поиск. То, что агент запрашивает через MCP, зависит от того, что он решает запросить. Он может не получить значения токенов. Может не запросить инвентарь компонентов. Может запросить только поддерево узлов, которое считает нужным, упустив пространственный контекст из соседних узлов. Поиск вероятностный, а не детерминированный. figmascope получает всё, каждый раз, с фиксированной схемой.

Труднее тестировать и воспроизводить. «Мой агент построил этот компонент из этих данных Figma в этот момент времени» непроверяемо с MCP. Запрос эфемерен. С бандлом вы можете воспроизвести точно: тот же бандл, тот же агент, тот же промпт — детерминированный вывод. Это важно для отладки, код-ревью и ответственности за релиз.

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

Модель бандла figmascope: захватить один раз, использовать всегда

figmascope экспортирует .zip обычных файлов из Figma REST API — без плагина, без сервера, работает в браузере. Бандл содержит:

После экспорта бандл самодостаточен и неизменен. Он помещается в репозиторий рядом с кодом, который он описывает. Любой агент, любая сессия, любой разработчик, любое CI-задание может его прочитать. Подключение ни к чему не требуется.

Версионируемые diff: сравнение бандлов как кода

Это сильнейший аргумент модели бандла. Поскольку вывод — структурированный JSON и Markdown, его можно делать diff.

Экспортируйте бандл до дизайн-спринта. Экспортируйте ещё один после. Запустите diff на tokens.json:

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

Это ломающее изменение в шкале отступов. Оно видно, поддаётся ревью и трассируется к коммиту. С MCP то же изменение происходит молча — при следующем запросе агент получает новое значение, и нет записи о том, что что-то изменилось.

Это можно запустить как проверку PR: экспортируйте бандл как часть дизайн-хэндоффа, зафиксируйте коммитом, требуйте одобрения дизайнера и разработчика на diff перед началом реализации. Это спецификация дизайна как код. У MCP нет эквивалента.

Аргумент детерминизма

Та же версия файла Figma + тот же экспорт figmascope = тот же бандл. Каждый раз. Схема IR фиксирована. Логика источника токенов детерминирована. Извлечение ключей строк основано на правилах.

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

Для кодогенерации продакшн-UI детерминизм важен. Вы хотите, чтобы спецификация, сгенерировавшая компонент, была воспроизводима. Вы хотите уметь регенерировать компонент из тех же входных данных и получать согласованные результаты. Бандлы это поддерживают. MCP-сессии нет.

Сравнение

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

MCP блистает для «редактировать Figma вживую» — бандлы блистают для «строить продакшн-UI»

Вот честное резюме. Если ваш рабочий процесс — разговорное исследование дизайна («измени этот компонент», «аннотируй этот экран», «каковы цветовые токены на этом фрейме»), живое подключение MCP — правильная модель. Агент является соавтором в процессе дизайна, и для этого ему нужны актуальные данные.

Если ваш рабочий процесс — создание продакшн-UI из финализированного (или почти финализированного) дизайна — реализация компонентов, подключение состояния, написание тестов — модель бандла лучше. Вы хотите, чтобы спецификация была закреплена в репозитории, поддавалась diff по итерациям дизайна, была читаема любым агентом без конфигурации и была достаточно детерминированной для построения на её основе.

Эти две модели дополняют друг друга. Используйте MCP, когда дизайн в процессе разработки и вы итерируете совместно. Экспортируйте бандл figmascope, когда дизайн стабилен и вы передаёте его инженерам для реализации. Бандл становится источником истины, против которого строится реализация — трассируемым, поддающимся ревью, воспроизводимым.