Secret MCP

Análisis de diseño web fundamentado en evidencia a partir de referencias recientes de GDWEB, que produce especificaciones DESIGN_INDEX listas para implementación mediante solicitudes de muestreo MCP aisladas.

GitHubPrueba este MCPPatrocinado

Documentación

English | 한국어

Arquitectura objetivo

Secret MCP target architecture

Secret MCP

Un servidor MCP basado en evidencia para análisis de diseño web, flujos de trabajo de captura de pantalla a especificación y planificación de reconstrucción frontend.

npx -y secret-design-mcp

Secret MCP es un servidor local del Protocolo de Contexto de Modelo (MCP) que busca en GDWEB referencias de diseño recientes y crea una solicitud LLM separada y un archivo DESIGN_INDEX separado para cada resultado de búsqueda. Cada archivo contiene diseños específicos de página y ruta, navegación, coordenadas de píxeles, colores, componentes y especificaciones responsivas trazables hasta la evidencia visual proporcionada.

El nombre Secret MCP no significa que el proyecto ofrezca funciones secretas o datos privados. Fue el nombre del proyecto utilizado mientras se experimentaba en un repositorio privado con la idea de construir un servidor MCP en torno a sitios web de diseño. El propósito actual del proyecto es extraer evidencia estructural reproducible de referencias de diseño públicas y convertirla en una especificación por trabajo que un LLM pueda aplicar a un nuevo proyecto.

Las imágenes y descripciones de múltiples trabajos nunca se combinan en un solo contexto o documento LLM. El servidor procesa los resultados de búsqueda secuencialmente dentro del servidor, crea una solicitud MCP sampling/createMessage independiente para cada trabajo, guarda el archivo de ese trabajo y solo entonces avanza al siguiente trabajo. Una aplicación web local separada te permite seleccionar un trabajo a la vez, inspeccionar su evidencia fuente, colores y coordenadas medidos, contrato LLM, registro de generación y documento final, y gestionar la lista de exclusión para búsquedas posteriores.

Nota de investigación

Análisis de diseño multimodal aislado por evidencia mediante muestreo MCP

Documento de trabajo e informe de implementación · Secret MCP v0.6.0 · no revisado por pares

Resumen

Secret MCP implementa un pipeline auditable para convertir capturas de pantalla de páginas web públicas en especificaciones de diseño orientadas a la implementación. El sistema prepara evidencia visual de escritorio y móvil, registra coordenadas de recorte y colores de píxeles representativos, e invoca el muestreo MCP del lado del cliente una vez por referencia. A diferencia de los flujos de trabajo que concatenan varias referencias de diseño en un solo prompt, Secret MCP trata la identidad de la referencia como un límite de solicitud y un límite de artefacto: una referencia produce una solicitud de muestreo, un contrato de solicitud y un documento DESIGN_INDEX. Cada solicitud pide includeContext: none y aplica el mismo contrato de especificación de 19 secciones que cubre rutas, geometría, componentes, tokens de diseño, comportamiento responsivo, accesibilidad, tareas de implementación, criterios de aceptación e incertidumbre. Este informe evalúa el aislamiento a nivel de protocolo y la producción de artefactos; no afirma que un modelo de lenguaje, prompt o método de reconstrucción supere a otro. Una prueba de humo en vivo verifica el límite de solicitud, mientras que una ejecución preservada de tres referencias proporciona mediciones descriptivas y un caso de implementación cualitativo.

Preguntas de investigación

Pregunta	Evidencia actual	Estado
RQ1. ¿Puede una herramienta de análisis de diseño MCP mantener el aislamiento de una referencia por solicitud?	Prueba de humo de muestreo en vivo con inspección de ID entre referencias y verificaciones de archivos de salida	Verificado dentro del alcance de la prueba
RQ2. ¿Puede la evidencia de capturas de pantalla transformarse en artefactos espaciales, de color y documentales auditables?	Ejecución preservada de tres referencias con manifiestos de evidencia, contratos y documentos generados	Verificado descriptivamente
RQ3. ¿Puede la especificación resultante guiar una implementación frontend distinta?	Estudio de caso cualitativo AEROFLOW	Preliminar; sin comparación controlada

Modelo formal del sistema

Para la referencia r_i, el conjunto de evidencia preparado contiene mosaicos de imagen I, límites de recorte B, mediciones de colores representativos P y metadatos de fuente M. El contrato de especificación fijo es C; la solicitud independiente y el documento resultante son q_i y 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

Las coordenadas medidas dentro de un mosaico preparado se mapean de vuelta a la captura de pantalla original de la siguiente manera.

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

Este es un invariante de aislamiento operativo, no una afirmación de independencia estadística. El servidor y la prueba de humo pueden inspeccionar el contenido de las solicitudes y los artefactos; no pueden probar lo que un proveedor de modelos externo arbitrario pueda retener fuera del mensaje MCP.

Resultados empíricos

Aislamiento de protocolo

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"]

Solicitud de muestreo	`gdweb-26522` presente	`gdweb-24516` presente	Documentos de salida
Solicitud 1	1	0	1
Solicitud 2	0	1	1

Figura 1. Prueba de humo en vivo registrada el 2026-08-22 usando la consulta 금융 (n = 2 referencias muestreadas después de excluir gdweb-26905). Cada solicitud contenía su propio ID de referencia y evidencia visual, ningún otro ID de referencia muestreado y includeContext: none; la ejecución produjo dos archivos Markdown distintos. La prueba verifica la composición observable de la solicitud y la separación de archivos, no el comportamiento de la memoria del modelo fuera del protocolo.

Mediciones de la ejecución registrada

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]

Referencia	Altura de fuente de escritorio	Imágenes preparadas	Carga útil de imágenes	Mediciones de color	Tokens del documento	Tamaño del documento	Encabezados requeridos
`gdweb-27294`	2,675px	3	126.6KB	24	7,921	54.0KB	19/19
`gdweb-25378`	7,043px	4	302.5KB	32	9,953	69.8KB	19/19
`gdweb-24234`	7,832px	5	387.8KB	40	9,517	63.2KB	19/19

Figura 2. Mediciones descriptivas de la ejecución preservada 2026-07-29T15-54-10-483Z-5c70317e (n = 3 referencias). La ejecución preparó 12 imágenes de evidencia que totalizan 816.9 KB decimales y registró 96 mediciones de colores representativos. Produjo tres documentos DESIGN_INDEX que totalizan 27,391 tokens separados por espacios y 187.0 KB decimales. Los tres contienen los encabezados 1–19; la presencia de encabezados no establece la corrección semántica.

Estudio de caso cualitativo

(a) Evidencia y mediciones	(b) `DESIGN_INDEX` por referencia	(c) Implementación impulsada por especificación

Figura 3. Un rastro cualitativo preservado desde el visor de evidencia GDWEB hasta el DESIGN_INDEX de Korean Air generado y luego hasta AEROFLOW. AEROFLOW introduce intencionalmente nueva marca, contenido, imágenes y funcionalidad; este ejemplo ilustra el uso de la especificación y no es una comparación controlada de fidelidad visual.

Interpretación y limitaciones

El resultado de aislamiento en vivo tiene n = 2; el análisis de artefactos registrado tiene n = 3. Ninguno respalda afirmaciones amplias sobre la calidad del diseño o el rendimiento del modelo.
La evaluación actual no tiene grupo de control, calificación humana, ensayos repetidos, intervalos de confianza ni comparación con líneas base de captura de pantalla a código.
Los colores representativos se miden después del redimensionamiento, la normalización JPEG y la cuantificación de canales. Son evidencia de captura de pantalla, no prueba de los tokens CSS del sitio web fuente.
El resultado 19/19 mide la presencia de encabezados requeridos. Un benchmark futuro debe evaluar por separado el fundamento factual, el error de coordenadas, la diferencia de color, el comportamiento responsivo y la fidelidad de implementación.
La implementación cualitativa es un ejemplo de existencia, no evidencia de que Secret MCP mejore la calidad de reconstrucción.

Uso

1. Instalar y compilar

Se requiere Node.js 20.19 o posterior.

El servidor MCP publicado se puede lanzar con:

npx -y secret-design-mcp

Clona el repositorio cuando también necesites el visor local o quieras trabajar en el código fuente:

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

2. Iniciar la aplicación web

Establece DESIGN_INDEX_OUTPUT_DIR al mismo valor para el servidor MCP y la aplicación web para que ambos procesos lean el mismo directorio de salida.

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

Abre la siguiente dirección en un navegador.

http://127.0.0.1:4317

La aplicación web muestra la lista de ejecuciones de generación, el progreso por trabajo, las imágenes de evidencia GDWEB, las coordenadas y paletas medidas, el contrato de especificación enviado al LLM, el Markdown final y las marcas de tiempo de generación. Los documentos y la evidencia son de solo lectura; solo Exclude from search y Remove exclusion cambian el filtro utilizado por búsquedas posteriores.

3. Registrar el servidor 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"
      }
    }
  }
}

Para una copia del código fuente, reemplaza command y args con "command": "node" y "args": ["/absolute/path/to/secret_mcp/dist/index.js"].

El cliente MCP debe admitir sampling/createMessage. Cuando un cliente no admite el muestreo, el servidor devuelve un error explícito en lugar de ejecutar un respaldo que coloque múltiples trabajos en el mismo contexto.

El servidor stdio MCP en sí no abre un puerto HTTP. El cliente lanza node dist/index.js como un proceso hijo e intercambia mensajes JSON-RPC a través de stdio. Solo el proceso del visor web separado usa el puerto 4317 por defecto.

Cliente de muestreo directo para hosts sin muestreo

El servidor no necesita modificarse cuando el host MCP externo no puede responder a sampling/createMessage. Un cliente de protocolo MCP separado puede conectarse directamente a dist/index.js, anunciar sampling: {} y manejar cada solicitud de muestreo lanzando un proceso LLM Codex nuevo en un espacio de trabajo temporal nuevo.

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 },
  };
});

El manejador de muestreo debe copiar solo los bloques de texto y las imágenes de evidencia de la solicitud actual en ese espacio de trabajo. No debe reutilizar una conversación, proceso, directorio de trabajo, archivo de respuesta o historial de mensajes de Codex de otro trabajo. El espacio de trabajo lanza un nuevo proceso de Codex, espera su respuesta completa en Markdown, devuelve esa respuesta a la llamada de muestreo MCP pendiente y luego puede eliminarse después de que el servidor haya guardado el contrato, la evidencia y el documento del trabajo.

El servidor aún controla la cola secuencial: el trabajo 2 no se prepara hasta que el trabajo 1 haya regresado y se haya guardado. Esto hace que el proceso y el espacio de trabajo nuevos sean un equivalente a nivel de ejecución del límite includeContext: none a nivel de protocolo sin agregar un respaldo combinado al servidor. El cliente directo se convierte en el host MCP con capacidad de muestreo; debe usar un tiempo de espera de llamada a herramienta lo suficientemente largo para el presupuesto de salida por trabajo y nunca debe responder múltiples solicitudes de muestreo a través de una conversación LLM persistente.

4. Preguntar al LLM

No se requiere un comando de barra diagonal /web-design separado.

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.

El LLM anfitrión llama a la herramienta generate-gdweb-design-indexes una vez. El servidor MCP realiza la búsqueda y separa las solicitudes LLM por trabajo internamente.

El formato de llamada a herramienta manual se muestra a continuación.

{
  "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
  }
}

Si se omite outputDirectory, la herramienta usa la variable de entorno DESIGN_INDEX_OUTPUT_DIR. Si esa variable también está ausente, usa el directorio design-index bajo el directorio de trabajo del servidor.

maxTokens es un presupuesto de salida por trabajo, no un presupuesto compartido por la ejecución ni un presupuesto dividido equitativamente entre páginas. Un solo trabajo puede contener múltiples páginas o rutas visibles, y cada página debe repetir las partes específicas de página completas del contrato de 19 secciones. El valor predeterminado y el mínimo son, por lo tanto, 131072 tokens. Los clientes pueden solicitar hasta 262144 tokens para conjuntos de evidencia multipágina excepcionalmente grandes.

Con limit: 3, la ejecución predeterminada puede solicitar hasta tres salidas independientes de 131072 tokens; los trabajos no comparten un grupo de 131072 tokens. El cliente de muestreo conectado y el modelo seleccionado deben admitir el tamaño de salida solicitado. Si el modelo devuelve stopReason: maxTokens, el servidor trata ese trabajo como fallido en lugar de guardar un DESIGN_INDEX truncado como completo.

Cuando la herramienta se completa, devuelve el ID de ejecución, la ruta del manifiesto de ejecución, las rutas de documentos por trabajo y la URL del visor web.

Ejemplo de extremo a extremo: De especificaciones GDWEB a un sitio web de aviación Godot

Para el ejemplo real, Secret MCP encontró tres ganadores de premios de aviación registrados en GDWEB en 2026 y 2025, creó un DESIGN_INDEX para cada trabajo a través de una solicitud LLM independiente y luego aplicó la estructura de la referencia de Korean Air a un sitio web de proyecto de aviación Godot. El sitio web AEROFLOW terminado no es un clon del sitio web de Korean Air. Utiliza la jerarquía de información, la navegación, el panel de acciones, la disposición de secciones y los principios de diseño responsive de la especificación, al tiempo que introduce una nueva marca, textos, imágenes de aviación y contenido. Este ejemplo demuestra que incluso cuando el diseño resultante difiere de la referencia, la evidencia estructural medible puede producir un sitio web pulido con una identidad distintiva.

Ejecutar el Ejemplo

# 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

Después de iniciar los procesos, abre las siguientes pantallas.

Visor web de especificaciones por obra: http://127.0.0.1:4317/?run=2026-07-29T15-54-10-483Z-5c70317e
Sitio web de resultados AEROFLOW: http://127.0.0.1:4320

1. Resultados de Especificación por Obra

Selecciona las obras una a la vez desde la lista de ejecución a la izquierda. El lado derecho muestra solo el DESIGN_INDEX final de la obra seleccionada, sin mezclar contenido de otras obras.

Secret MCP web viewer with the Korean Air DESIGN_INDEX open

2. Imágenes de Evidencia y Mediciones

La pestaña Evidence muestra las imágenes de escritorio y móvil enviadas a la solicitud independiente del LLM, las coordenadas de los mosaicos, las proporciones de reducción y los colores representativos.

GDWEB desktop and mobile evidence images with representative colors

3. Contrato de Solicitud Independiente del LLM

El Request Contract registra la separación de páginas, la navegación, los límites de secciones, los colores HEX/RGB/HSL, los componentes, la matriz responsive y los criterios de aceptación. Este contrato evita que el resultado termine como un resumen superficial de ambiente y lo convierte en una especificación de implementación que otro LLM puede usar.

Request contract containing page, coordinate, color, and responsive requirements

4. Proceso de Generación

El Generation Log muestra la secuencia desde la búsqueda y preparación de evidencia hasta la solicitud independiente del LLM por obra, el guardado de documentos y la finalización completa de la ejecución. Esta ejecución procesó las tres obras con solicitudes includeContext: none separadas.

Generation log from search through independent LLM requests and document saves

5. Primera Vista de AEROFLOW Impulsada por Especificación

El portal de aviación brillante y la estructura de panel de acciones observados en la referencia de Korean Air se adaptaron a un proyecto de Godot. La marca, las imágenes de aeronaves, los textos y la funcionalidad se crearon específicamente para este resultado.

AEROFLOW first view and flight-build selection panel

6. Destacados del Proyecto

La estructura de tarjetas de reservas y promociones se reutilizó para el contenido central del proyecto: regiones de vuelo, una cabina de vidrio y clima en tiempo real.

Project highlights and new aviation image cards

7. Registro de Desarrollo y Accesos Directos

Los avisos y accesos directos de servicios de la referencia fuente se reestructuraron en historial de compilación, progreso de desarrollo, modelos de vuelo, aviónica, medios, controles y navegación de hoja de ruta.

AEROFLOW development log and project shortcuts

8. Medios y Pie de Página

El área final contiene enlaces de medios del proyecto, desarrollo, soporte y licencia, seguidos de un pie de página de proyecto independiente.

AEROFLOW flight-test media and footer

Qué Demuestra Este Resultado

Un proyecto nuevo puede usar una jerarquía de información validada y relaciones de diseño sin copiar el logotipo, las marcas registradas, los textos o las imágenes de la referencia.
Convertir capturas de pantalla estáticas en navegación, límites de píxeles, tokens de color, componentes y una matriz responsive le da a otro LLM suficiente detalle para crear un plan de implementación concreto.
Incluso con la misma evidencia estructural, el contenido, la marca y los activos visuales recién diseñados pueden crear una identidad distintiva que difiere de la fuente.
Secret MCP está diseñado para extraer evidencia estructural de un buen diseño y usarla para construir un sitio web pulido adecuado a un proyecto nuevo, no para reproducir la fuente píxel por píxel.

Especificación y Contrato de Solicitud

Estos enlaces apuntan directamente a los archivos reales incluidos en el repositorio. Los mismos artefactos también se agrupan bajo tmp/showcase/aviation-godot mediante enlaces simbólicos relativos para ejecución y navegación local.

Arquitectura Central de Ejecución

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"]

Los siguientes límites son esenciales.

Las imágenes o los cuerpos de especificación de múltiples obras nunca se devuelven al LLM anfitrión externo como un solo lote.
Con limit: 3, el servidor realiza exactamente hasta tres solicitudes de muestreo del LLM mutuamente independientes.
Cada solicitud de muestreo usa includeContext: none.
Una solicitud de muestreo contiene solo los metadatos y los mosaicos de imagen de una obra.
El ID, las imágenes y el documento de análisis de la obra anterior nunca se pasan a la solicitud de la siguiente obra.
Las obras excluidas en el visor web se eliminan de los resultados de búsqueda antes de que se cree cualquier solicitud de muestreo.
El servidor inicia la siguiente obra solo después de guardar la respuesta de muestreo actual en un archivo.
Al final, solo las rutas de archivos generados, el modelo utilizado y el estado de éxito o fracaso se devuelven al anfitrión.

En otras palabras, esta no es la arquitectura anterior en la que el LLM anfitrión lee todos los resultados a la vez y produce un resumen combinado.

Visor Web

El visor web lee DESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runs cada 2,5 segundos. No hay una base de datos separada ni una conexión de depuración entre el proceso de generación MCP y el servidor web.

La interfaz contiene las siguientes áreas.

Ejecuciones de generación: consulta, cantidad solicitada, años permitidos y estado general
Lista de obras: progreso y cantidad de imágenes de evidencia para cada gdweb-<work-number>
Detalles de la obra: especificación, imágenes de evidencia y mediciones, contrato de solicitud y registro de generación para una obra seleccionada
Exclusiones de búsqueda: excluir la obra seleccionada de búsquedas futuras, incluirla nuevamente y gestionar la lista completa de exclusiones

Cuando una ejecución contiene tres obras, también produce tres documentos como se muestra a continuación.

.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 no es un archivo que combine los cuerpos de documentos de múltiples obras. Es un manifiesto del visor que contiene solo rutas de archivos por obra, estado, marcas de tiempo, modelo y listas de evidencia.

Lista de Exclusiones de Búsqueda

Seleccionar Exclude from search en el visor web guarda el número de obra en el siguiente archivo.

DESIGN_INDEX_OUTPUT_DIR/.secret-mcp/exclusions.json

Las ejecuciones históricas y los documentos generados nunca se eliminan.
Las nuevas ejecuciones de generate-gdweb-design-indexes y search-gdweb-designs filtran los números de obra antes de la selección.
Para evitar devolver muy pocos resultados debido a exclusiones, la búsqueda lee candidatos adicionales de GDWEB y selecciona el limit solicitado de las obras no excluidas.
Seleccionar Remove exclusion hace que la obra sea elegible nuevamente a partir de la siguiente búsqueda.
El servidor MCP y el visor web deben usar el mismo DESIGN_INDEX_OUTPUT_DIR para compartir la misma lista de exclusiones.

Procesamiento de Imágenes

Las capturas de escritorio completas de GDWEB pueden ser extremadamente altas y de varios megabytes. Enviar los datos base64 originales directamente en una solicitud de muestreo puede exceder los límites de transporte de MCP o hacer que un modelo de visión pierda detalles estructurales finos.

Antes de crear la solicitud para cada obra, gdweb-sampling-images.ts realiza las siguientes operaciones.

Cargar la imagen de registro de escritorio de GDWEB con sgbn=1
Cargar la imagen de registro móvil de GDWEB con sgbn=3
Redimensionar la imagen de escritorio a un ancho máximo de 1200px
Dividir una página larga en mosaicos verticales superpuestos de 1600px de alto
Conservar la imagen móvil como evidencia separada
Comprimir la evidencia como JPEG para reducir el tamaño de la solicitud de muestreo de MCP
Registrar las dimensiones del lienzo original y preparado, el factor de escala, las coordenadas x/y/width/height preparadas, las coordenadas del espacio fuente y la URL fuente para cada mosaico
Medir ocho colores representativos de cada mosaico y registrar HEX, RGB, HSL y cobertura de píxeles

Múltiples mosaicos de una obra se incluyen en la misma solicitud de muestreo específica de la obra. Los mosaicos de diferentes obras nunca se incluyen en la misma solicitud.

Los colores representativos son mediciones muestreadas de píxeles de capturas normalizadas. Son evidencia precisa para la comparación visual, pero no deben presentarse como las variables CSS del sitio fuente porque el error JPEG y el contenido de la imagen afectan los valores. El contrato de generación distingue los colores MEASURED de los tokens de implementación INFERRED.

El servidor no abre el sitio web de producción en vivo de la obra ni rastrea su DOM. La evidencia visual se limita a las imágenes y metadatos registrados en GDWEB.

Búsqueda en GDWEB

La búsqueda de diseño no usa automatización de navegador, Bing, Brave ni 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

Política de Frescura

Si se omite year, se usa el año de ejecución actual.
includePreviousYear tiene como valor predeterminado true.
Cuando se ejecuta en 2026, solo se permiten por defecto las obras registradas en 2026 y 2025.
Con includePreviousYear: false, solo se permite el año objetivo.
awardOnly tiene como valor predeterminado true, por lo que las obras sin nombre de premio se excluyen.
limit se puede configurar de 1 a 10.

Metadatos de la Obra

Campo	Descripción
`strNo`	Número de obra de GDWEB, también usado en el nombre del archivo del documento
`txtFgbn`	Valor de categoría de obra de GDWEB
`title`	Título de la obra
`gdwebUrl`	Página de detalles de la obra en GDWEB
`registeredDate` / `registeredYear`	Fecha de registro y el año usado para el filtrado
`award`	Nombre del premio
`concept`	Concepto de diseño
`primaryColor`	Color principal
`productionCompany`	Empresa productora
`desktopImageUrl`	Captura de escritorio de GDWEB (`sgbn=1`)
`mobileImageUrl`	Captura móvil de GDWEB (`sgbn=3`)

Especificación DESIGN_INDEX

Cada solicitud de muestreo independiente incluye el contrato secret-mcp/design-index/v2. El nombre de archivo resultante es DESIGN_INDEX_gdweb-<strNo>.md.

Hay un archivo por obra, pero cada archivo comienza con un inventario de páginas y rutas y repite una subsección completa para cada página verificada. El contrato no confunde secciones en una captura de desplazamiento largo con páginas separadas; divide páginas solo cuando el collage de evidencia muestra visiblemente pantallas separadas.

Cada documento debe contener las 19 secciones numeradas a continuación.

Área	Especificación requerida
Objetivo de reconstrucción	ID de referencia, fidelidad objetivo, rutas, viewports objetivo y no objetivos
Evidencia y sistema de coordenadas	IDs de imagen, dimensiones originales/preparadas, escala, coordenadas de teselas, coordenadas en el espacio de origen y método de eliminación de superposiciones
Mapa del sitio	Páginas y rutas verificadas, propósito, imágenes de evidencia, shell compartido, menú activo y confianza
Shell compartido de la aplicación	Fondo global, contenedor, márgenes internos, superposiciones, marco de página y contexto de apilamiento
Navegación	Alturas en escritorio y móvil, coordenadas de logo/menú, espacios, áreas táctiles y estados activo/hover/foco/abierto
Especificación por página y tabla de coordenadas	Modelo de lienzo, orden de secciones, x/y/ancho/alto, diseño, estados, datos y nivel de evidencia para cada página
Análisis profundo del diseño	DOM, grid/flex, pistas, min/max, proporciones, espacios, desbordamiento, sticky, absoluto y z-index
Abstracción de componentes	Árbol de componentes vinculado a páginas, props, variantes, slots, estado, eventos y contratos de datos
Tokens y colores exactos	HEX/RGB/HSL/alfa, uso, coordenadas de medición, confianza, tolerancia y variables CSS
Tipografía	Familia de fuente por rol, px/rem, peso, altura de línea, espaciado entre letras, alineación, truncamiento y valores responsivos
Recursos e iconos	Página y sección, tamaño de visualización, relación de aspecto, recorte, punto focal, object-fit, carga y estrategia de respaldo
Matriz responsiva	Contenedores, columnas, orden, visibilidad, navegación y espaciado en 1440/1280/1024/768/390/360px
Interacción y movimiento	Color, opacidad, transformación, duración, easing, teclado y comportamiento de movimiento reducido para cada estado
Accesibilidad	Landmarks por página, encabezados, foco, semántica de menú, etiquetas, texto alternativo, contraste y objetivos táctiles
Datos y contenido	Entidades de página, campos, conteos, ordenamiento, formatos, localización y fixtures de carga/vacío/error
Arquitectura frontend	Rutas, directorios, módulos de página/compartidos, tokens, recursos, estado y límites servidor/cliente
Grafo de tareas de implementación	Medición, shell, navegación, IDs de tareas por página, dependencias, entregables y criterios de finalización
Criterios de aceptación por página	Tolerancias de coordenadas, color y tipografía; comparación de viewport; desbordamiento; recursos; teclado; y rendimiento
Incertidumbres y decisiones	UNKNOWNs por página y sección, valores adoptados, alternativas, confianza y evidencia adicional requerida

Cada juicio importante está marcado con uno de los siguientes niveles de evidencia.

OBSERVED: directamente visible en una imagen o metadatos de GDWEB
MEASURED: verificado numéricamente a partir de coordenadas de píxeles proporcionadas o de la paleta medida
INFERRED: inferido razonablemente para reproducir el mismo resultado
UNKNOWN: no se puede verificar a partir de evidencia estática y no debe afirmarse como hecho

Otro LLM debe poder derivar el árbol de componentes, tokens, reglas responsivas, recursos, orden de implementación y elementos de validación únicamente del documento completado.

Herramientas Expuestas

El servidor expone actualmente cinco herramientas MCP.

Herramienta	Propósito
`generate-gdweb-design-indexes`	Buscar en GDWEB, hacer una solicitud LLM aislada por resultado y guardar documentos
`search-gdweb-designs`	Devolver una lista de referencias de GDWEB sin generar especificaciones
`full-web-search`	Buscar en la web general y extraer el contenido completo de la página
`get-web-search-summaries`	Devolver títulos, URLs y descripciones de una búsqueda general
`get-single-web-page-content`	Extraer el contenido completo de una página web general conocida

Use generate-gdweb-design-indexes para planificación de diseño, análisis de diseño, especificaciones de implementación y solicitudes de DESIGN_INDEX. Use search-gdweb-designs solo para solicitudes de listas ligeras.

Estructura de Fuente

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

Desarrollo y Validación

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

La prueba de humo de aislamiento conecta un cliente MCP simulado que admite muestreo y verifica el siguiente comportamiento.

El número de resultados de búsqueda es igual al número de solicitudes de muestreo.
Cada solicitud de muestreo contiene exactamente un ID de referencia.
Ningún ID de otro trabajo se mezcla en una solicitud.
Cada solicitud usa includeContext: none.
Cada solicitud incluye imágenes de GDWEB.
Cada resultado crea un archivo Markdown separado.
Un trabajo excluido no entra en resultados de búsqueda posteriores ni en solicitudes de muestreo.
El contrato de especificación contiene requisitos por página, navegación, coordenadas y color.
La evidencia del manifiesto de ejecución registra coordenadas de teselas y paletas medidas.

Variables de Entorno en Tiempo de Ejecución

Nombre	Predeterminado	Descripción
`DESIGN_INDEX_OUTPUT_DIR`	`./design-index`	Directorio donde se almacenan los documentos generados
`SECRET_MCP_WEB_ORIGIN`	`http://127.0.0.1:4317`	Dirección del visor web incluida en los resultados de MCP
`SECRET_MCP_WEB_HOST`	`127.0.0.1`	Dirección de enlace del servidor web
`SECRET_MCP_WEB_PORT`	`4317`	Puerto del servidor web
`MCP_SAMPLING_TIMEOUT_MS`	`1800000`	Tiempo de espera para cada solicitud LLM independiente por trabajo en milisegundos
`MAX_CONTENT_LENGTH`	`500000`	Longitud máxima del cuerpo de página extraído de una página web general
`DEFAULT_TIMEOUT`	`6000`	Tiempo de espera para solicitudes HTTP generales y de navegador
`MAX_BROWSERS`	`3`	Número máximo de navegadores utilizados para extracción general
`BROWSER_TYPES`	`chromium,firefox`	Navegadores utilizados para búsqueda y extracción general
`BROWSER_HEADLESS`	`true`	Si Playwright se ejecuta sin interfaz gráfica
`FORCE_MULTI_ENGINE_SEARCH`	`false`	Si comparar cada motor durante la búsqueda general
`DEBUG_BROWSER_LIFECYCLE`	`false`	Si imprimir registros del ciclo de vida del navegador

Documentación

Trabajo Relacionado y Referencias

Secret MCP se posiciona como un artefacto de implementación adyacente a la comprensión multimodal de UI y la investigación de screenshot-to-code. Aún no ha sido evaluado en los conjuntos de datos o métricas utilizados por los artículos a continuación, por lo que sus resultados no deben interpretarse como resultados de Secret MCP.

Chenglei Si, Yanzhe Zhang, Ryan Li, Zhengyuan Yang, Ruibo Liu y Diyi Yang. Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering. NAACL 2025. Introduce evaluación de screenshot-to-code del mundo real con métricas visuales y a nivel de elementos. Paper
Bryan Wang, Gang Li, Xin Zhou, Zhourong Chen, Tovi Grossman y Yang Li. Screen2Words: Automatic Mobile UI Summarization with Multimodal Learning. UIST 2021. Estudia representaciones que combinan captura de pantalla, texto, estructura y semántica de UI. Paper
Jing Yu Koh, Robert Lo, Lawrence Jang, Vikram Duvvur, Ming Chong Lim, Po-Yu Huang, Graham Neubig, Shuyan Zhou, Ruslan Salakhutdinov y Daniel Fried. VisualWebArena: Evaluating Multimodal Agents on Realistic Visually Grounded Web Tasks. ACL 2024. Establece la importancia y dificultad de la evaluación de agentes web con base visual realista. Paper
Model Context Protocol. Sampling specification. Define el sampling/createMessage mediado por el cliente, incluidos mensajes de solicitud, preferencias de modelo, presupuestos de tokens y controles de contexto. Specification

Citación

Secret MCP es actualmente software con una nota de investigación funcional, no una publicación revisada por pares.

@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}
}