Articles

DS MCP: как дать AI-агенту знание о вашей дизайн-системе

DS MCP решает проблему "галлюцинаций" AI-агента: вместо выдумывания несуществующих компонентов агент получает точные данные о реальных элементах дизайн-системы через Model Context Protocol.

· 2 мин чтения · · AI и LLM

TL;DR

  • DS MCP решает проблему "галлюцинаций" AI-агента: вместо выдумывания несуществующих компонентов агент получает точные данные о реальных элементах дизайн-системы через Model Context Protocol.
  • ChromaDB с embeddings + RAG позволяют агенту находить компоненты по семантическому описанию (не по названию), а препроцессор структурирует свойства, варианты и ограничения каждого компонента.
  • Figma MCP извлекает макеты, DS MCP — правила сборки из React, Jetpack Compose или SwiftUI; вместе они дают агенту полный контекст для верстки реальными компонентами.

Разбор

Основная боль: AI-агент видит макет в Figma, умеет писать код, но не знает, какие компоненты из вашей дизайн-системы использовать. Он генерирует Button, хотя в проекте есть PrimaryButton с props variant, size, icon. Или рисует кастомный Card, когда есть готовый CardContainer с preset-стилями. Figma MCP решает только половину задачи — он вытаскивает визуальные данные из макета. Вторую половину закрывает DS MCP: он подключается к вашей дизайн-системе через Model Context Protocol и передает агенту точные спецификации компонентов.

Как это работает на практике. Сначала вы запускаете препроцессор, который сканирует код дизайн-системы (React, Jetpack Compose, SwiftUI) и генерирует структурированное описание: для каждого компонента — имя, props, варианты, ограничения, примеры использования. Эти данные отправляются в ChromaDB с embeddings (например, text-embedding-ada-002). Когда агент получает задачу "сверстать карточку товара с фото, ценой и кнопкой", он формирует запрос, RAG дополняет его контекстом из ChromaDB — и агент находит CardProduct, PriceLabel, AddToCartButton. Без RAG он бы просто сгенерировал <div> с кнопкой.

Главные грабли: embeddings работают плохо, если названия компонентов не отражают их назначение (например, DSButton вместо PrimaryButton). Решение — добавить в препроцессор синонимы и описания на естественном языке. Вторая проблема: Figma MCP часто отдает сырые данные без учета токенов дизайн-системы (цвета, отступы, типографика). Тут помогает связка: Figma MCP → DS MCP, где второй маппит визуальные атрибуты на токены из кода. Пример конфигурации DS MCP для React:

{
  "mcpServers": {
    "ds-mcp": {
      "command": "npx",
      "args": ["-y", "@ds/mcp-server"],
      "env": {
        "DS_PATH": "./src/components",
        "EMBEDDING_MODEL": "text-embedding-ada-002",
        "CHROMA_DB_PATH": "./chroma_db"
      }
    }
  }
}

Выводы

  • DS MCP + RAG с ChromaDB — это не "еще один инструмент", а способ заставить AI-агента работать с реальной кодовой базой, а не с абстрактными представлениями.
  • Препроцессор — критический компонент: без качественного описания компонентов (свойства, варианты, ограничения) embeddings будут давать мусорные результаты.
  • Figma MCP и DS MCP должны быть сконфигурированы как единая цепочка: макет → визуальные данные → маппинг на токены → генерация кода реальными компонентами.

Нужна такая автоматизация? Обсудить проект в Telegram: https://t.me/Cvister0

FAQ

С чего начать?

Смотрите раздел «Разбор» и блок «Выводы».

Обсудить проект в Telegram