English | 한국어

Целевая архитектура

Secret MCP

MCP-сервер, основанный на фактических данных, для анализа веб-дизайна, рабочих процессов «от скриншота к спецификации» и планирования восстановления фронтенда.

npx -y secret-design-mcp

Secret MCP — это локальный сервер Model Context Protocol (MCP), который выполняет поиск по GDWEB в поисках свежих дизайн-референсов и создаёт отдельный LLM-запрос и отдельный файл DESIGN_INDEX для каждого результата поиска. Каждый файл содержит послойную разметку страниц и маршрутов, навигацию, пиксельные координаты, цвета, компоненты и адаптивные спецификации, которые можно проследить до предоставленных визуальных доказательств.

Название Secret MCP не означает, что проект предоставляет секретные функции или приватные данные. Это было рабочее название проекта, использовавшееся при экспериментах в приватном репозитории с идеей создания MCP-сервера вокруг дизайнерских веб-сайтов. Текущая цель проекта — извлекать воспроизводимые структурные доказательства из публичных дизайн-референсов и превращать их в одну спецификацию на каждую работу, которую LLM может применить к новому проекту.

Изображения и описания из нескольких работ никогда не объединяются в одном LLM-контексте или документе. Сервер обрабатывает результаты поиска последовательно внутри себя, создаёт независимый MCP-запрос sampling/createMessage для каждой работы, сохраняет файл этой работы и только затем переходит к следующей. Отдельное локальное веб-приложение позволяет выбрать одну работу за раз, просмотреть её исходные доказательства, измеренные цвета и координаты, LLM-контракт, журнал генерации и итоговый документ, а также управлять списком исключений для последующих поисков.

Related MCP server: Refero MCP

Исследовательская заметка

Мультимодальный анализ дизайна с изоляцией доказательств через MCP Sampling

Рабочий документ и отчёт о внедрении · Secret MCP v0.6.0 · не рецензировался

Аннотация

Secret MCP реализует аудируемый конвейер преобразования публичных скриншотов веб-страниц в ориентированные на реализацию спецификации дизайна. Система подготавливает визуальные доказательства для десктопа и мобильных устройств, записывает координаты обрезки и репрезентативные цвета пикселей и вызывает клиентский MCP sampling один раз на каждый референс. В отличие от рабочих процессов, которые объединяют несколько дизайн-референсов в один промпт, Secret MCP рассматривает идентичность референса и как границу запроса, и как границу артефакта: один референс порождает один sampling-запрос, один контракт запроса и один документ DESIGN_INDEX. Каждый запрос использует includeContext: none и применяет один и тот же контракт спецификации из 19 разделов, охватывающий маршруты, геометрию, компоненты, дизайн-токены, адаптивное поведение, доступность, задачи реализации, критерии приёмки и неопределённость. Этот отчёт оценивает изоляцию на уровне протокола и производство артефактов; он не утверждает, что одна языковая модель, промпт или метод восстановления превосходит другой. Живой smoke-тест проверяет границу запроса, а сохранённый прогон с тремя референсами предоставляет описательные измерения и качественный пример реализации.

Вопросы исследования

Формальная модель системы

Для референса r_i подготовленный набор доказательств содержит тайлы изображений I, границы обрезки B, репрезентативные измерения цветов P и метаданные источника M. Фиксированный контракт спецификации — это C; независимый запрос и итоговый документ — это q_i и D_i.

E_i = { I_i,k, B_i,k, P_i,k, M_i }
q_i = sampling/createMessage(C, E_i; includeContext = none)
D_i = G_theta(q_i)

References(q_i) = { r_i }
For every i != j: referenceId(r_j) is absent from q_i

Координаты, измеренные внутри подготовленного тайла, сопоставляются с исходным скриншотом следующим образом.

x_source = (cropLeft + x_tile) / scaleX
y_source = (cropTop  + y_tile) / scaleY

Это инвариант операционной изоляции, а не утверждение статистической независимости. Сервер и smoke-тест могут проверять содержимое запросов и артефактов; они не могут доказать, что произвольный внешний поставщик моделей сохраняет за пределами MCP-сообщения.

Эмпирические результаты

Изоляция протокола

flowchart LR
    R1["gdweb-26522"] --> Q1["Request 1<br/>5 evidence images<br/>includeContext: none"] --> D1["DESIGN_INDEX_gdweb-26522.md"]
    R2["gdweb-24516"] --> Q2["Request 2<br/>4 evidence images<br/>includeContext: none"] --> D2["DESIGN_INDEX_gdweb-24516.md"]

Рисунок 1. Живой smoke-тест, записанный 22.08.2026, с использованием запроса 금융 (n = 2 отобранных референсов после исключения gdweb-26905). Каждый запрос содержал собственный ID референса и визуальные доказательства, без других отобранных ID референсов и с includeContext: none; прогон создал два отдельных Markdown-файла. Тест проверяет наблюдаемый состав запросов и разделение файлов, а не поведение памяти модели за пределами протокола.

Измерения сохранённого прогона

xychart-beta
    title "Prepared evidence images per reference"
    x-axis ["gdweb-27294", "gdweb-25378", "gdweb-24234"]
    y-axis "Evidence images" 0 --> 5
    bar [3, 4, 5]

Рисунок 2. Описательные измерения сохранённого прогона 2026-07-29T15-54-10-483Z-5c70317e (n = 3 референса). Прогон подготовил 12 изображений доказательств общим объёмом 816,9 десятичных КБ и записал 96 измерений репрезентативных цветов. Он создал три документа DESIGN_INDEX общим объёмом 27 391 токенов с разделителями-пробелами и 187,0 десятичных КБ. Все три содержат заголовки 1–19; наличие заголовков не подтверждает семантическую корректность.

Качественный пример

Рисунок 3. Сохранённый качественный след от просмотра доказательств GDWEB к сгенерированному DESIGN_INDEX для Korean Air и затем к AEROFLOW. AEROFLOW намеренно вводит новый брендинг, контент, изображения и функциональность; этот пример иллюстрирует использование спецификации и не является контролируемым сравнением визуального соответствия.

Интерпретация и ограничения

• Живой результат изоляции имеет n = 2; сохранённый анализ артефактов имеет n = 3. Ни то, ни другое не подтверждает широких утверждений о качестве дизайна или производительности модели.

• Текущая оценка не имеет контрольной группы, оценки человеком, повторных прогонов, доверительных интервалов или сравнения с базовыми показателями «скриншот-в-код».

• Репрезентативные цвета измеряются после изменения размера, нормализации JPEG и квантования каналов. Это доказательства на основе скриншотов, а не подтверждение CSS-токенов исходного веб-сайта.

• Результат 19/19 измеряет наличие требуемых заголовков. Будущий бенчмарк должен отдельно оценивать фактическую обоснованность, ошибку координат, разницу цветов, адаптивное поведение и точность реализации.

• Качественная реализация — это пример существования, а не доказательство того, что Secret MCP улучшает качество восстановления.

Использование

1. Установка и сборка

Требуется Node.js 20.19 или новее.

Опубликованный MCP-сервер можно запустить с помощью:

npx -y secret-design-mcp

Клонируйте репозиторий, если вам также нужен локальный просмотрщик или вы хотите работать с исходным кодом:

git clone https://github.com/yyeongjin/secret_mcp.git
cd secret_mcp
npm install
npm run build

2. Запуск веб-приложения

Установите для DESIGN_INDEX_OUTPUT_DIR одно и то же значение для MCP-сервера и веб-приложения, чтобы оба процесса читали одну и ту же выходную директорию.

DESIGN_INDEX_OUTPUT_DIR=/absolute/path/to/design-index npm run web

Откройте следующий адрес в браузере.

http://127.0.0.1:4317

Веб-приложение отображает список прогонов генерации, прогресс по каждой работе, изображения доказательств GDWEB, измеренные координаты и палитры, контракт спецификации, отправленный LLM, итоговый Markdown и временные метки генерации. Документы и доказательства доступны только для чтения; только Exclude from search и Remove exclusion изменяют фильтр, используемый последующими поисками.

3. Регистрация MCP-сервера

{
  "mcpServers": {
    "secret-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "secret-design-mcp"
      ],
      "env": {
        "DESIGN_INDEX_OUTPUT_DIR": "/absolute/path/to/design-index",
        "SECRET_MCP_WEB_ORIGIN": "http://127.0.0.1:4317"
      }
    }
  }
}

Для исходного кода из репозитория замените command и args на "command": "node" и "args": ["/absolute/path/to/secret_mcp/dist/index.js"].

MCP-клиент должен поддерживать sampling/createMessage. Если клиент не поддерживает sampling, сервер возвращает явную ошибку вместо выполнения запасного варианта, который помещает несколько работ в один контекст.

Сам MCP-сервер stdio не открывает HTTP-порт. Клиент запускает node dist/index.js как дочерний процесс и обменивается JSON-RPC-сообщениями через stdio. Только отдельный процесс веб-просмотрщика по умолчанию использует порт 4317.

Прямой sampling-клиент для хостов без поддержки sampling

Сервер не нужно модифицировать, когда внешний MCP-хост не может ответить на sampling/createMessage. Отдельный MCP-клиент протокола может подключиться напрямую к dist/index.js, объявить sampling: {} и обрабатывать каждый sampling-запрос запуском нового процесса Codex LLM в новой временной рабочей области.

const client = new Client(
  { name: 'secret-mcp-sampling-client', version: '1.0.0' },
  { capabilities: { sampling: {} } }
);

client.setRequestHandler(CreateMessageRequestSchema, async request => {
  const workspace = await mkdtemp('secret-mcp-sampling-');
  const response = await launchFreshCodex({
    workspace,
    messages: request.params.messages,
    systemPrompt: request.params.systemPrompt,
  });

  return {
    model: response.model,
    role: 'assistant',
    content: { type: 'text', text: response.markdown },
  };
});

Обработчик sampling должен копировать в эту рабочую область только текстовые блоки и изображения доказательств текущего запроса. Он не должен повторно использовать беседу Codex, процесс, рабочий каталог, файл ответа или историю сообщений от другой работы. Рабочая область запускает один новый процесс Codex, ожидает его полный Markdown-ответ, возвращает этот ответ ожидающему вызову MCP sampling и может быть удалена после того, как сервер сохранит контракт, доказательства и документ работы.

Сервер по-прежнему управляет последовательной очередью: работа 2 не подготавливается, пока работа 1 не вернулась и не была сохранена. Это делает свежий процесс и рабочую область эквивалентом на уровне исполнения границы includeContext: none на уровне протокола, без добавления комбинированного запасного варианта на сервер. Прямой клиент становится MCP-хостом с поддержкой sampling; он должен использовать таймаут вызова инструмента, достаточно длинный для бюджета вывода на одну работу, и никогда не должен отвечать на несколько sampling-запросов через один постоянный разговор с LLM.

4. Запрос к LLM

Отдельная слэш-команда /web-design не требуется.

Find three recent design references on GDWEB that are suitable for a Godot project website.
Analyze every search result through a completely independent LLM request,
and create one reproducible DESIGN_INDEX document for each result.
Inside each document, separate every visible page into its own page specification,
and specify everything from navigation and section coordinates to exact color formats and responsive values.

Хост-LLM вызывает инструмент generate-gdweb-design-indexes один раз. MCP-сервер выполняет поиск и внутренне разделяет LLM-запросы по каждой работе.

Формат ручного вызова инструмента показан ниже.

{
  "name": "generate-gdweb-design-indexes",
  "arguments": {
    "query": "game portfolio",
    "limit": 3,
    "awardOnly": true,
    "includePreviousYear": true,
    "language": "English",
    "outputDirectory": "/absolute/path/to/design-index",
    "maxTokens": 131072
  }
}

Если outputDirectory не указан, инструмент использует переменную окружения DESIGN_INDEX_OUTPUT_DIR. Если и эта переменная отсутствует, используется каталог design-index в рабочем каталоге сервера.

maxTokens — это бюджет вывода на одну работу, а не общий бюджет запуска и не бюджет, разделяемый поровну между страницами. Одна работа может содержать несколько видимых страниц или маршрутов, и каждая страница должна повторять полные части контракта из 19 разделов, относящиеся к конкретной странице. Поэтому значение по умолчанию и минимальное значение равны 131072 токенам. Клиенты могут запрашивать до 262144 токенов для исключительно больших многостраничных наборов доказательств.

При limit: 3 запуск по умолчанию может запросить до трёх независимых выходных данных по 131072 токенов; работы не используют один общий пул на 131072 токена. Подключённый клиент сэмплирования и выбранная модель должны поддерживать запрошенный размер вывода. Если модель возвращает stopReason: maxTokens, сервер считает эту работу неудачной, а не сохраняет усечённый DESIGN_INDEX как завершённый.

Когда инструмент завершает работу, он возвращает идентификатор запуска, путь к манифесту запуска, пути к документам по каждой работе и URL веб-просмотрщика.

Сквозной пример: от спецификаций GDWEB до веб-сайта авиационного проекта на Godot

В реальном примере Secret MCP нашёл три работы-победителя авиационной премии, зарегистрированные на GDWEB в 2026 и 2025 годах, создал DESIGN_INDEX для каждой работы с помощью независимого LLM-запроса, а затем применил структуру эталонного сайта Korean Air к веб-сайту авиационного проекта на Godot.

Готовый веб-сайт AEROFLOW не является клоном сайта Korean Air. Он использует иерархию информации, навигацию, панель действий, расположение разделов и принципы адаптивности из спецификации, добавляя при этом новый бренд, тексты, авиационные изображения и контент. Этот пример демонстрирует, что даже когда итоговый дизайн отличается от эталона, измеримые структурные доказательства всё равно позволяют создать качественный веб-сайт с узнаваемой индивидуальностью.

Запустите пример

# 1. Build
npm install
npm run build

# 2. Per-work document web viewer
DESIGN_INDEX_OUTPUT_DIR="$PWD/tmp/design-index/aviation-godot-20260730" npm run web

# 3. Specification-driven result website
python3 -m http.server 4320 \
  --bind 127.0.0.1 \
  --directory tmp/showcase/aviation-godot/generated-site

После запуска процессов откройте следующие экраны.

• Веб-просмотрщик спецификаций по каждой работе: http://127.0.0.1:4317/?run=2026-07-29T15-54-10-483Z-5c70317e

• Веб-сайт результата AEROFLOW: http://127.0.0.1:4320

1. Результаты спецификаций по каждой работе

Выбирайте работы по одной из списка запусков слева. Правая сторона отображает только итоговый DESIGN_INDEX для выбранной работы, не смешивая его с содержимым других работ.

2. Доказательные изображения и измерения

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

3. Контракт независимого LLM-запроса

Request Contract фиксирует разделение страниц, навигацию, границы разделов, цвета HEX/RGB/HSL, компоненты, адаптивную матрицу и критерии приёмки. Этот контракт не позволяет результату превратиться в поверхностное описание настроения и делает его спецификацией реализации, которую может использовать другая LLM.

4. Процесс генерации

Generation Log показывает последовательность от поиска и подготовки доказательств до независимого LLM-запроса по каждой работе, сохранения документа и завершения полного запуска. Этот запуск обработал все три работы с отдельными запросами includeContext: none.

5. Первый экран AEROFLOW на основе спецификации

Яркий авиационный портал и структура панели действий, наблюдаемые в эталонном сайте Korean Air, были адаптированы для проекта на Godot. Бренд, изображения самолётов, тексты и функциональность были созданы специально для этого результата.

6. Основные моменты проекта

Структура карточек бронирования и акций была перепрофилирована под основной контент проекта: регионы полётов, стеклянную кабину и погоду в реальном времени.

7. Журнал разработки и ярлыки

Уведомления и служебные ярлыки исходного эталона были перестроены в историю сборок, прогресс разработки, модели самолётов, авионику, медиа, управление и навигацию по дорожной карте.

8. Медиа и подвал

В финальной области находятся ссылки на медиа проекта, разработку, поддержку и лицензии, а затем подвал независимого проекта.

Что демонстрирует этот результат

• Новый проект может использовать проверенную иерархию информации и взаимосвязи макета, не копируя логотип, товарные знаки, тексты или изображения эталона.

• Преобразование статических скриншотов в навигацию, границы в пикселях, цветовые токены, компоненты и адаптивную матрицу даёт другой LLM достаточно деталей для создания конкретного плана реализации.

• Даже с одними и теми же структурными доказательствами заново созданные контент, брендинг и визуальные материалы могут сформировать отличительную индивидуальность, которая отличается от источника.

• Secret MCP предназначен для извлечения структурных доказательств из хорошего дизайна и использования их для создания качественного веб-сайта под новый проект, а не для воспроизведения источника пиксель в пиксель.

Спецификация и контракт запроса

• Спецификация DESIGN_INDEX Korean Air

• Контракт независимого LLM-запроса

• Манифест запуска

• Исходный код сгенерированного веб-сайта

Эти ссылки ведут непосредственно к фактическим файлам, включённым в репозиторий. Те же артефакты также сгруппированы в tmp/showcase/aviation-godot через относительные символические ссылки для локального запуска и просмотра.

Базовая архитектура выполнения

flowchart TD
    User["User request"] --> Host["Host LLM"]
    Host --> Tool["One generate-gdweb-design-indexes call"]
    Tool --> Exclusions["Load the exclusion list managed in the web viewer"]
    Exclusions --> Search["Search GDWEB internally and filter work IDs"]
    Search --> Queue["Keep results inside the server"]
    Queue --> R1["Work 1 images + specification contract"]
    R1 --> S1["Independent sampling/createMessage request 1"]
    S1 --> F1["Save DESIGN_INDEX_gdweb-1.md"]
    F1 --> R2["Work 2 images + specification contract"]
    R2 --> S2["Independent sampling/createMessage request 2"]
    S2 --> F2["Save DESIGN_INDEX_gdweb-2.md"]
    F2 --> More["Repeat sequentially for every work"]
    More --> Manifest["Record per-work evidence and status in run.json"]
    Manifest --> Web["Inspect one work at a time in the local web viewer"]
    Manifest --> Status["Return only file paths and statuses to the host"]

Следующие границы обязательны.

• Изображения или тела спецификаций из нескольких работ никогда не возвращаются внешней хост-LLM одним пакетом.

• При limit: 3 сервер выполняет не более трёх взаимно независимых LLM-запросов сэмплирования.

• Каждый запрос сэмплирования использует includeContext: none.

• Запрос сэмплирования содержит только метаданные одной работы и тайлы изображений.

• Идентификатор предыдущей работы, её изображения и аналитический документ никогда не передаются в запрос следующей работы.

• Работы, исключённые в веб-просмотрщике, удаляются из результатов поиска до создания любого запроса сэмплирования.

• Сервер начинает следующую работу только после сохранения текущего ответа сэмплирования в файл.

• В конце хост-LLM возвращаются только пути к сгенерированным файлам, использованная модель и статус успеха или неудачи.

Иными словами, это не прежняя архитектура, в которой хост-LLM читает все результаты сразу и создаёт объединённую сводку.

Веб-просмотрщик

Веб-просмотрщик читает DESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runs каждые 2,5 секунды. Между процессом генерации MCP и веб-сервером нет отдельной базы данных или отладочного соединения.

Интерфейс содержит следующие области.

• Запуски генерации: запрос, запрошенное количество, разрешённые годы и общий статус

• Список работ: прогресс и количество доказательных изображений для каждого gdweb-<work-number>

• Детали работы: спецификация, доказательные изображения и измерения, контракт запроса и журнал генерации для одной выбранной работы

• Исключения поиска: исключить выбранную работу из будущих поисков, снова включить её и управлять полным списком исключений

Когда запуск содержит три работы, он также создаёт три документа, как показано ниже.

.secret-mcp-runs/<run-id>/
├── run.json
├── contracts/
│   ├── gdweb-26905.md
│   ├── gdweb-26522.md
│   └── gdweb-xxxxx.md
├── evidence/
│   ├── gdweb-26905_desktop_01-of-05.jpg
│   ├── gdweb-26522_desktop_01-of-04.jpg
│   └── ...
└── documents/
    ├── DESIGN_INDEX_gdweb-26905.md
    ├── DESIGN_INDEX_gdweb-26522.md
    └── DESIGN_INDEX_gdweb-xxxxx.md

run.json — это не файл, объединяющий тела документов из нескольких работ. Это манифест просмотрщика, содержащий только пути к файлам по каждой работе, статус, временные метки, модель и списки доказательств.

Список исключений поиска

Выбор Exclude from search в веб-просмотрщике сохраняет номер работы в следующий файл.

DESIGN_INDEX_OUTPUT_DIR/.secret-mcp/exclusions.json

• Исторические запуски и сгенерированные документы никогда не удаляются.

• Новые запуски generate-gdweb-design-indexes и search-gdweb-designs фильтруют номера работ перед выбором.

• Чтобы избежать слишком малого количества результатов из-за исключений, поиск читает дополнительные кандидаты GDWEB и выбирает запрошенный limit из неисключённых работ.

• Выбор Remove exclusion делает работу снова доступной, начиная со следующего поиска.

• MCP-сервер и веб-просмотрщик должны использовать один и тот же DESIGN_INDEX_OUTPUT_DIR, чтобы использовать общий список исключений.

Обработка изображений

Полные снимки рабочего стола GDWEB могут быть чрезвычайно высокими и иметь размер в несколько мегабайт. Отправка исходных данных base64 непосредственно в запросе сэмплирования может превысить лимиты транспорта MCP или привести к тому, что модель зрения пропустит мелкие структурные детали.

Перед созданием запроса для каждой работы gdweb-sampling-images.ts выполняет следующие операции.

• Загружает изображение регистрации рабочего стола GDWEB с sgbn=1

• Загружает изображение регистрации мобильного устройства GDWEB с sgbn=3

• Изменяет размер изображения рабочего стола до максимальной ширины 1200px

• Разбивает длинную страницу на перекрывающиеся вертикальные тайлы высотой 1600px

• Сохраняет мобильное изображение как отдельное доказательство

• Сжимает доказательства в JPEG для уменьшения размера запроса сэмплирования MCP

• Записывает исходные и подготовленные размеры холста, коэффициент масштабирования, подготовленные координаты x/y/width/height, координаты в исходном пространстве и исходный URL для каждого тайла

• Измеряет восемь характерных цветов из каждого тайла и записывает HEX, RGB, HSL и покрытие в пикселях

Несколько тайлов из одной работы включаются в один и тот же запрос сэмплирования для конкретной работы. Тайлы из разных работ никогда не включаются в один запрос.

Характерные цвета — это измерения, полученные из нормализованных пикселей скриншотов. Они являются точным доказательством для визуального сравнения, но их нельзя представлять как CSS-переменные исходного сайта, поскольку ошибки JPEG и содержимое изображения влияют на значения. Контракт генерации различает цвета MEASURED и токены реализации INFERRED.

Сервер не открывает живой производственный веб-сайт работы и не обходит его DOM. Визуальные доказательства ограничены изображениями и метаданными, зарегистрированными на GDWEB.

Поиск по GDWEB

Поиск дизайнов не использует автоматизацию браузера, Bing, Brave или DuckDuckGo.

Query
  -> POST https://www.gdweb.co.kr/sub/search.asp
  -> form field: Txt_word=<query>
  -> parse the GDWEB result HTML
  -> collect work number, category, and registration year
  -> retain only the current and previous year
  -> load GDWEB detail metadata and registered images

Политика актуальности

• Если year не указан, используется текущий год выполнения.

• includePreviousYear по умолчанию равен true.

• При запуске в 2026 году по умолчанию разрешены только работы, зарегистрированные в 2026 и 2025 годах.

• При includePreviousYear: false разрешён только целевой год.

• awardOnly по умолчанию равен true, поэтому работы без названия награды исключаются.

• limit может быть установлен от 1 до 10.

Метаданные работы

Спецификация DESIGN_INDEX

Каждый независимый запрос на выборку включает контракт secret-mcp/design-index/v2. Имя результирующего файла — DESIGN_INDEX_gdweb-<strNo>.md.

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

Каждый документ должен содержать все 19 пронумерованных разделов, перечисленных ниже.

Каждое важное суждение помечается одним из следующих уровней доказательств.

• OBSERVED: непосредственно видно на изображении или в метаданных GDWEB

• MEASURED: численно проверено по предоставленным пиксельным координатам или измеренной палитре

• INFERRED: обоснованно выведено для воспроизведения того же результата

• UNKNOWN: невозможно проверить по статическим доказательствам и не должно утверждаться как факт

Другая LLM должна иметь возможность вывести дерево компонентов, токены, адаптивные правила, ресурсы, порядок реализации и элементы проверки только из заполненного документа.

Доступные инструменты

Сервер в настоящее время предоставляет пять MCP-инструментов.

Используйте generate-gdweb-design-indexes для планирования дизайна, анализа макета, спецификаций реализации и запросов DESIGN_INDEX. Используйте search-gdweb-designs только для легковесных запросов списков.

Структура исходного кода

secret_mcp/
├── src/
│   ├── index.ts                         MCP tool registration and sampling requests
│   ├── dashboard-server.ts              Local web server and document/exclusion APIs
│   ├── design-index-run-store.ts         Run manifest and per-work artifact records
│   ├── design-exclusion-store.ts         Add/remove persistent search exclusions
│   ├── design-index-paths.ts             Shared MCP/viewer output-path resolution
│   ├── gdweb-design-search.ts           GDWEB search, year filtering, and registered-image loading
│   ├── gdweb-design-index-generator.ts  Sequential per-work generation and Markdown saving
│   ├── gdweb-sampling-images.ts         Long-capture resizing, tiling, and compression
│   ├── design-spec-contract.ts          Required DESIGN_INDEX specification contract
│   ├── search-engine.ts                 General Bing, Brave, and DuckDuckGo search
│   ├── enhanced-content-extractor.ts    General webpage content extraction
│   ├── browser-pool.ts                  Browser pool for general content extraction
│   ├── rate-limiter.ts                  General-search request limits
│   ├── types.ts                         Search and tool types
│   └── utils.ts                         URL, text, and timestamp utilities
├── web/
│   ├── index.html                       Web viewer interface
│   ├── styles.css                       Desktop and mobile layout
│   └── app.js                           Run refresh and per-work document switching
├── .github/workflows/
│   ├── ci.yml                           Build, lint, and package validation
│   ├── gdweb-smoke.yml                  Live GDWEB search and image validation
│   └── release.yml                      Release-package generation
├── tmp/DESIGN_CONTEST_SITES.md          Design competition and award website list
├── tmp/reconstructions/
│   └── gdweb-27294-godot/               Specification-driven AEROFLOW static website
├── tmp/showcase/aviation-godot/
│   ├── DESIGN_INDEX.md                   Relative symbolic link to the per-work specification
│   ├── REQUEST_CONTRACT.md               Relative symbolic link to the independent request contract
│   ├── RUN_MANIFEST.json                 Relative symbolic link to the run manifest
│   ├── generated-site/                   Relative symbolic link to the result website
│   └── screenshots/                      Run and result screens used by this README
├── mcp.json                             MCP registration example
└── package.json

Разработка и проверка

npm run build
npm run lint
npm run smoke:gdweb-isolation
npm run web

Изоляционный смоук-тест подключает макетный MCP-клиент, поддерживающий выборку, и проверяет следующее поведение.

• Количество результатов поиска равно количеству запросов на выборку.

• Каждый запрос на выборку содержит ровно один идентификатор ссылки.

• Идентификатор другой работы не смешивается с запросом.

• Каждый запрос использует includeContext: none.

• Каждый запрос включает изображения GDWEB.

• Каждый результат создает отдельный файл Markdown.

• Исключенная работа не попадает в последующие результаты поиска или запросы на выборку.

• Контракт спецификации содержит требования к страницам, навигации, координатам и цветам.

• Доказательства манифеста запуска фиксируют координаты тайлов и измеренные палитры.

Переменные среды выполнения

Документация

• Документация MCP API

• Список сайтов дизайн-конкурсов и наград

• Запись повторной проверки свежего клона

• Yeong Coffee DESIGN_INDEX, исторический вывод на корейском

• Yorien DESIGN_INDEX, исторический вывод на корейском

• Ggublack Chicken DESIGN_INDEX, исторический вывод на корейском

• Спецификация Korean Air DESIGN_INDEX, исторический вывод на корейском

• Контракт независимого запроса Korean Air

Связанные работы и ссылки

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

1. Chenglei Si, Yanzhe Zhang, Ryan Li, Zhengyuan Yang, Ruibo Liu, and Diyi Yang. Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering. NAACL 2025. Представляет оценку преобразования реальных скриншотов в код с визуальными и элементными метриками. Paper

2. Bryan Wang, Gang Li, Xin Zhou, Zhourong Chen, Tovi Grossman, and Yang Li. Screen2Words: Automatic Mobile UI Summarization with Multimodal Learning. UIST 2021. Исследует представления, объединяющие скриншот, текст, структуру и семантику интерфейса. Paper

3. Jing Yu Koh, Robert Lo, Lawrence Jang, Vikram Duvvur, Ming Chong Lim, Po-Yu Huang, Graham Neubig, Shuyan Zhou, Ruslan Salakhutdinov, and Daniel Fried. VisualWebArena: Evaluating Multimodal Agents on Realistic Visually Grounded Web Tasks. ACL 2024. Устанавливает важность и сложность оценки веб-агентов на основе визуального восприятия. Paper

4. Model Context Protocol. Sampling. Определяет опосредованное клиентом создание выборки samplingCreateMessage, включая запросы, предпочтения моделей, лимиты токенов и управление контекстом. Specification

Цитирование

Secret MCP — это программное обеспечение с рабочей исследовательской заметкой, а не рецензируемая публикация.

@software{jo2026secretmcp,
  author  = {{조영진}},
  title   = {Secret MCP: Evidence-Isolated Multimodal Design Analysis through MCP Sampling},
  year    = {2026},
  version = {0.6.0},
  url     = {https://github.com/yyeongjin/secret_mcp},
  note    = {Software artifact and working implementation report}
}