Inglés | 한국어

Arquitectura objetivo

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 de 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 proporcione 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 independiente de sampling/createMessage de MCP para cada trabajo, guarda el archivo de ese trabajo y solo entonces avanza al siguiente trabajo. Una aplicación web local separada le 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.

Related MCP server: Refero MCP

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

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 color representativas 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 asignan 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"]

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]

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 con un total de 816.9 KB decimales y registró 96 mediciones de color representativas. Produjo tres documentos DESIGN_INDEX con un total de 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

Figura 3. Un rastro cualitativo preservado desde el visor de evidencia de GDWEB hasta el DESIGN_INDEX de Korean Air generado y luego a 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 o 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

Clone el repositorio cuando también necesite el visor local o quiera 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

Establezca 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

Abra 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 de 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, reemplace command y args con "command": "node" y "args": ["/ruta/absoluta/a/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 MCP stdio 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 de 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 de Codex, proceso, directorio de trabajo, archivo de respuesta o historial de mensajes 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 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 capaz de muestrear; debe usar un tiempo de espera de llamada de 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 /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 sola vez. El servidor MCP realiza la búsqueda y separa internamente las solicitudes LLM por obra.

El formato manual de llamada a la herramienta 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 tampoco existe, usa el directorio design-index bajo el directorio de trabajo del servidor.

maxTokens es un presupuesto de salida por obra, no un presupuesto compartido por la ejecución ni un presupuesto dividido equitativamente entre páginas. Una sola obra puede contener múltiples páginas o rutas visibles, y cada página debe repetir las partes específicas de la página del contrato de 19 secciones. Por lo tanto, el valor predeterminado y el mínimo son 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; las obras no comparten un único 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 esa obra como fallida 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 los documentos por obra y la URL del visor web.

Ejemplo de extremo a extremo: de las especificaciones de GDWEB a un sitio web de aviación en 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 obra mediante una solicitud LLM independiente y luego aplicó la estructura de la referencia de Korean Air a un sitio web de proyecto de aviación en Godot.

El sitio web terminado AEROFLOW 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 responsivo 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 de AEROFLOW: http://127.0.0.1:4320

1. Resultados de especificaciones por obra

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

2. Imágenes de evidencia y mediciones

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

3. Contrato de solicitud LLM independiente

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 responsiva y los criterios de aceptación. Este contrato evita que el resultado termine como un resumen de ambiente superficial y lo convierte en una especificación de implementación que otro LLM puede usar.

4. Proceso de generación

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

5. Primera vista de AEROFLOW impulsada por la 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.

6. Destacados del proyecto

La estructura de tarjetas de reserva y promoción se reutilizó para el contenido principal del proyecto: regiones de vuelo, cabina de vidrio y clima en tiempo real.

7. Registro de desarrollo y accesos directos

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

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.

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 comerciales, 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 responsiva 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 para un proyecto nuevo, no para reproducir la fuente píxel por píxel.

Especificación y contrato de solicitud

• Especificación del DESIGN_INDEX de Korean Air

• Contrato de solicitud LLM independiente

• Manifiesto de ejecución

• Código fuente del sitio web generado

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 la ejecución y navegación local.

Arquitectura de ejecución principal

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 LLM mutuamente independientes.

• Cada solicitud de muestreo usa includeContext: none.

• Una solicitud de muestreo contiene solo los metadatos y los mosaicos de imágenes 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 se devuelven al anfitrión las rutas de los archivos generados, el modelo utilizado y el estado de éxito o fracaso.

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-<número-de-obra>

• 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 administrar 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 exclusión 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 vuelva a ser elegible 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 pase por alto detalles estructurales finos.

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

• Carga la imagen de registro de escritorio de GDWEB con sgbn=1

• Carga la imagen de registro móvil de GDWEB con sgbn=3

• Redimensiona la imagen de escritorio a un ancho máximo de 1200px

• Divide una página larga en mosaicos verticales superpuestos de 1600px de alto

• Conserva la imagen móvil como evidencia separada

• Comprime la evidencia como JPEG para reducir el tamaño de la solicitud de muestreo MCP

• Registra las dimensiones originales y preparadas del lienzo, el factor de escala, las coordenadas preparadas x/y/width/height, las coordenadas del espacio de origen y la URL de origen para cada mosaico

• Mide ocho colores representativos de cada mosaico y registra 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 de pantalla normalizadas. Son evidencia precisa para la comparación visual, pero no deben presentarse como las variables CSS del sitio de origen 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 los 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 establecer de 1 a 10.

Metadatos de la obra

Especificación de 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 trabajo, 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 de una captura de desplazamiento largo con páginas separadas; solo divide páginas cuando el collage de evidencia muestra visiblemente pantallas separadas.

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

Cada juicio importante se marca con uno de los siguientes niveles de evidencia.

• OBSERVED: directamente visible en una imagen o metadato 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 puede verificarse a partir de evidencia estática y no debe afirmarse como hecho

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

Herramientas Expuestas

El servidor expone actualmente cinco herramientas MCP.

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

Estructura de la 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 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 ni solicitudes de muestreo posteriores.

• El contrato de especificación contiene requisitos por página, de navegación, de coordenadas y de color.

• La evidencia del manifiesto de ejecución registra coordenadas de teselas y paletas medidas.

Variables de Entorno en Tiempo de Ejecución

Documentación

• Documentación de la API de MCP

• Lista de sitios de concursos y premios de diseño

• Registro de reverificación de clonación limpia

• Yeong Coffee DESIGN_INDEX, salida histórica en coreano

• Yorien DESIGN_INDEX, salida histórica en coreano

• Ggublack Chicken DESIGN_INDEX, salida histórica en coreano

• Especificación de Korean Air DESIGN_INDEX, salida histórica en coreano

• Contrato de solicitud independiente de Korean Air

Trabajo Relacionado y Referencias

Secret MCP se posiciona como un artefacto de implementación adyacente a la comprensión multimodal de interfaces de usuario y a la investigación de captura de pantalla a código. Aún no se ha 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.

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. Introduce una evaluación de conversión de capturas de pantalla a código en el mundo real con métricas visuales y a nivel de elementos. 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. Estudia representaciones que combinan captura de pantalla, texto, estructura y semántica de la interfaz de usuario. 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. Establece la importancia y la dificultad de la evaluación de agentes web con base visual. Paper

4. Model Context Protocol. Sampling specification. Define sampling/createMessage mediado por el cliente, incluidos los mensajes de solicitud, las preferencias de modelo, los presupuestos de tokens y los controles de contexto. Specification

Cita

Secret MCP es actualmente software con una nota de investigación en curso, 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}
}