Secret MCP

Análise de design web fundamentada em evidências a partir de referências recentes do GDWEB, produzindo especificações DESIGN_INDEX prontas para implementação por meio de solicitações de amostragem MCP isoladas.

GitHubExperimente este MCPPatrocinado

Documentação

English | 한국어

Arquitetura Alvo

Secret MCP target architecture

Secret MCP

Um servidor MCP fundamentado em evidências para análise de design web, fluxos de trabalho de screenshot para especificação e planejamento de reconstrução de frontend.

npx -y secret-design-mcp

Secret MCP é um servidor local do Model Context Protocol (MCP) que pesquisa no GDWEB referências de design recentes e cria uma solicitação LLM separada e um arquivo DESIGN_INDEX separado para cada resultado de pesquisa. Cada arquivo contém layouts específicos de página e rota, navegação, coordenadas de pixels, cores, componentes e especificações responsivas rastreáveis até a evidência visual fornecida.

O nome Secret MCP não significa que o projeto fornece recursos secretos ou dados privados. Foi o nome do projeto usado durante experimentos em um repositório privado com a ideia de construir um servidor MCP em torno de sites de design. O propósito atual do projeto é extrair evidências estruturais reproduzíveis de referências de design públicas e transformá-las em uma especificação por trabalho que um LLM possa aplicar a um novo projeto.

Imagens e descrições de vários trabalhos nunca são combinadas em um único contexto ou documento LLM. O servidor processa os resultados da pesquisa sequencialmente dentro do servidor, cria uma solicitação MCP sampling/createMessage independente para cada trabalho, salva o arquivo desse trabalho e só então avança para o próximo trabalho. Um aplicativo web local separado permite selecionar um trabalho por vez, inspecionar suas evidências de origem, cores e coordenadas medidas, contrato LLM, log de geração e documento final, e gerenciar a lista de exclusão para pesquisas subsequentes.

Nota de Pesquisa

Análise de Design Multimodal Isolada por Evidências através de Amostragem MCP

Artigo de trabalho e relatório de implementação · Secret MCP v0.6.0 · não revisado por pares

Resumo

Secret MCP implementa um pipeline auditável para converter capturas de tela de páginas web públicas em especificações de design orientadas à implementação. O sistema prepara evidências visuais para desktop e mobile, registra coordenadas de recorte e cores de pixel representativas, e invoca amostragem MCP do lado do cliente uma vez por referência. Diferente de fluxos de trabalho que concatenam várias referências de design em um único prompt, Secret MCP trata a identidade da referência como um limite de solicitação e um limite de artefato: uma referência produz uma solicitação de amostragem, um contrato de solicitação e um documento DESIGN_INDEX. Cada solicitação pede includeContext: none e aplica o mesmo contrato de especificação de 19 seções cobrindo rotas, geometria, componentes, tokens de design, comportamento responsivo, acessibilidade, tarefas de implementação, critérios de aceitação e incerteza. Este relatório avalia o isolamento em nível de protocolo e a produção de artefatos; não afirma que um modelo de linguagem, prompt ou método de reconstrução supera outro. Um teste de fumaça ao vivo verifica o limite de solicitação, enquanto uma execução preservada de três referências fornece medições descritivas e um caso de implementação qualitativo.

Perguntas de Pesquisa

Pergunta	Evidência atual	Status
RQ1. Uma ferramenta de análise de design MCP pode manter isolamento de uma referência por solicitação?	Teste de fumaça de amostragem ao vivo com inspeção de ID de referência cruzada e verificações de arquivos de saída	Verificado dentro do escopo do teste
RQ2. Evidências de captura de tela podem ser transformadas em artefatos espaciais, de cor e documentais auditáveis?	Execução preservada de três referências com manifestos de evidências, contratos e documentos gerados	Verificado descritivamente
RQ3. A especificação resultante pode guiar uma implementação de frontend distinta?	Estudo de caso qualitativo AEROFLOW	Preliminar; sem comparação controlada

Modelo Formal do Sistema

Para a referência r_i, o conjunto de evidências preparado contém blocos de imagem I, limites de recorte B, medições de cores representativas P e metadados de origem M. O contrato de especificação fixo é C; a solicitação independente e o documento resultante são q_i e 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

Coordenadas medidas dentro de um bloco preparado mapeiam de volta para a captura de tela original da seguinte forma.

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

Este é um invariante de isolamento operacional, não uma afirmação de independência estatística. O servidor e o teste de fumaça podem inspecionar conteúdos de solicitação e artefatos; eles não podem provar o que um provedor de modelo externo arbitrário pode reter fora da mensagem MCP.

Resultados Empíricos

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

Solicitação de amostragem	`gdweb-26522` presente	`gdweb-24516` presente	Documentos de saída
Solicitação 1	1	0	1
Solicitação 2	0	1	1

Figura 1. Teste de fumaça ao vivo registrado em 2026-08-22 usando a consulta 금융 (n = 2 referências amostradas após excluir gdweb-26905). Cada solicitação continha seu próprio ID de referência e evidência visual, nenhum outro ID de referência amostrado, e includeContext: none; a execução produziu dois arquivos Markdown distintos. O teste verifica a composição observável da solicitação e a separação de arquivos, não o comportamento de memória do modelo fora do protocolo.

Medições da Execução 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]

Referência	Altura da fonte desktop	Imagens preparadas	Payload de imagem	Medições de cor	Tokens do documento	Tamanho do documento	Cabeçalhos necessários
`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. Medições descritivas da execução preservada 2026-07-29T15-54-10-483Z-5c70317e (n = 3 referências). A execução preparou 12 imagens de evidência totalizando 816,9 KB decimais e registrou 96 medições de cores representativas. Produziu três documentos DESIGN_INDEX totalizando 27.391 tokens separados por espaços em branco e 187,0 KB decimais. Todos os três contêm cabeçalhos 1–19; a presença de cabeçalhos não estabelece correção semântica.

Estudo de Caso Qualitativo

(a) Evidências e medições	(b) `DESIGN_INDEX` por referência	(c) Implementação orientada por especificação

Figura 3. Um rastro qualitativo preservado do visualizador de evidências GDWEB para o DESIGN_INDEX da Korean Air gerado e depois para AEROFLOW. AEROFLOW introduz intencionalmente nova marca, conteúdo, imagens e funcionalidade; este exemplo ilustra o uso de especificação e não é uma comparação controlada de fidelidade visual.

Interpretação e Limitações

O resultado de isolamento ao vivo tem n = 2; a análise de artefatos registrada tem n = 3. Nenhum deles suporta afirmações amplas sobre qualidade de design ou desempenho de modelo.
A avaliação atual não tem grupo de controle, classificação humana, tentativas repetidas, intervalos de confiança ou comparação com linhas de base de screenshot para código.
Cores representativas são medidas após redimensionamento, normalização JPEG e quantização de canal. Elas são evidência de captura de tela, não prova dos tokens CSS do site de origem.
O resultado 19/19 mede a presença de cabeçalhos necessários. Um benchmark futuro deve avaliar separadamente fundamentação factual, erro de coordenadas, diferença de cor, comportamento responsivo e fidelidade de implementação.
A implementação qualitativa é um exemplo de existência, não evidência de que Secret MCP melhora a qualidade da reconstrução.

Uso

1. Instalar e Construir

Node.js 20.19 ou posterior é necessário.

O servidor MCP publicado pode ser iniciado com:

npx -y secret-design-mcp

Clone o repositório quando você também precisar do visualizador local ou quiser trabalhar no código-fonte:

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

2. Iniciar o Aplicativo Web

Defina DESIGN_INDEX_OUTPUT_DIR para o mesmo valor para o servidor MCP e o aplicativo web para que ambos os processos leiam o mesmo diretório de saída.

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

Abra o seguinte endereço em um navegador.

http://127.0.0.1:4317

O aplicativo web exibe a lista de execuções de geração, progresso por trabalho, imagens de evidência GDWEB, coordenadas e paletas medidas, o contrato de especificação enviado ao LLM, o Markdown final e carimbos de data/hora de geração. Documentos e evidências são somente leitura; apenas Exclude from search e Remove exclusion alteram o filtro usado por pesquisas subsequentes.

3. Registrar o 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 um checkout do código-fonte, substitua command e args por "command": "node" e "args": ["/absolute/path/to/secret_mcp/dist/index.js"].

O cliente MCP deve suportar sampling/createMessage. Quando um cliente não suporta amostragem, o servidor retorna um erro explícito em vez de executar um fallback que coloca vários trabalhos no mesmo contexto.

O próprio servidor MCP stdio não abre uma porta HTTP. O cliente inicia node dist/index.js como um processo filho e troca mensagens JSON-RPC via stdio. Apenas o processo separado do visualizador web usa a porta 4317 por padrão.

Cliente de Amostragem Direta para Hosts Sem Amostragem

O servidor não precisa ser modificado quando o host MCP externo não pode responder a sampling/createMessage. Um cliente de protocolo MCP separado pode conectar-se diretamente a dist/index.js, anunciar sampling: {} e lidar com cada solicitação de amostragem iniciando um novo processo LLM Codex em um novo espaço de trabalho temporário.

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

O manipulador de amostragem deve copiar apenas os blocos de texto e imagens de evidência da solicitação atual para esse espaço de trabalho. Ele não deve reutilizar uma conversa, processo, diretório de trabalho, arquivo de resposta ou histórico de mensagens do Codex de outro trabalho. O espaço de trabalho inicia um novo processo Codex, aguarda sua resposta Markdown completa, retorna essa resposta para a chamada de amostragem MCP pendente e pode então ser removido após o servidor salvar o contrato, evidências e documento do trabalho.

O servidor ainda controla a fila sequencial: o trabalho 2 não é preparado até que o trabalho 1 tenha retornado e sido salvo. Isso torna o processo e o espaço de trabalho novos um equivalente em nível de execução do limite includeContext: none em nível de protocolo, sem adicionar um fallback combinado ao servidor. O cliente direto torna-se o host MCP com capacidade de amostragem; ele deve usar um tempo limite de chamada de ferramenta longo o suficiente para o orçamento de saída por trabalho e nunca deve responder a múltiplas solicitações de amostragem através de uma conversa LLM persistente.

4. Perguntar ao LLM

Um comando de barra /web-design separado não é necessário.

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.

O LLM host chama a ferramenta generate-gdweb-design-indexes uma vez. O servidor MCP realiza a pesquisa e separa as solicitações LLM por trabalho internamente.

O formato manual de chamada de ferramenta é mostrado abaixo.

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

Se outputDirectory for omitido, a ferramenta usa a variável de ambiente DESIGN_INDEX_OUTPUT_DIR. Se essa variável também estiver ausente, ela usa o diretório design-index sob o diretório de trabalho do servidor.

maxTokens é um orçamento de saída por trabalho, não um orçamento compartilhado pela execução e não um orçamento dividido igualmente entre páginas. Um único trabalho pode conter múltiplas páginas ou rotas visíveis, e cada página deve repetir as partes específicas da página do contrato de 19 seções. O padrão e o mínimo são, portanto, 131072 tokens. Os clientes podem solicitar até 262144 tokens para conjuntos de evidências multi-página excepcionalmente grandes.

Com limit: 3, a execução padrão pode solicitar até três saídas independentes de 131072 tokens; os trabalhos não compartilham um pool de 131072 tokens. O cliente de amostragem conectado e o modelo selecionado devem suportar o tamanho de saída solicitado. Se o modelo retornar stopReason: maxTokens, o servidor trata esse trabalho como falho em vez de salvar um DESIGN_INDEX truncado como completo.

Quando a ferramenta conclui, ela retorna o ID da execução, o caminho do manifesto da execução, os caminhos dos documentos por trabalho e a URL do visualizador web.

Exemplo de Ponta a Ponta: Das Especificações GDWEB a um Site de Aviação Godot

Para o exemplo real, Secret MCP encontrou três vencedores de aviação registrados no GDWEB em 2026 e 2025, criou um DESIGN_INDEX para cada trabalho através de uma solicitação LLM independente e, em seguida, aplicou a estrutura da referência Korean Air a um site de projeto de aviação Godot. O site AEROFLOW finalizado não é um clone do site da Korean Air. Ele usa a hierarquia de informações, navegação, painel de ações, organização de seções e princípios responsivos da especificação, ao mesmo tempo em que introduz uma nova marca, textos, imagens de aviação e conteúdo. Este exemplo demonstra que mesmo quando o design resultante difere da referência, evidências estruturais mensuráveis ainda podem produzir um site refinado com identidade própria.

Como Executar o Exemplo

# 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

Após iniciar os processos, abra as seguintes telas.

Visualizador web da especificação por trabalho: http://127.0.0.1:4317/?run=2026-07-29T15-54-10-483Z-5c70317e
Site de resultado AEROFLOW: http://127.0.0.1:4320

1. Resultados da Especificação por Trabalho

Selecione os trabalhos um a um na lista de execução à esquerda. O lado direito exibe apenas o DESIGN_INDEX final do trabalho selecionado, sem misturar conteúdo de outros trabalhos.

Secret MCP web viewer with the Korean Air DESIGN_INDEX open

2. Imagens de Evidência e Medições

A aba Evidence mostra as imagens de desktop e mobile enviadas à solicitação independente de LLM, coordenadas dos tiles, taxas de redução e cores representativas.

GDWEB desktop and mobile evidence images with representative colors

3. Contrato da Solicitação Independente de LLM

O Request Contract registra separação de páginas, navegação, limites de seções, cores HEX/RGB/HSL, componentes, a matriz responsiva e critérios de aceite. Este contrato impede que o resultado termine como um resumo superficial de clima visual e o transforma em uma especificação de implementação que outro LLM pode usar.

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

4. Processo de Geração

O Generation Log mostra a sequência desde a busca e preparação de evidências, passando pela solicitação independente de LLM por trabalho, salvamento do documento e conclusão da execução completa. Esta execução processou todos os três trabalhos com solicitações includeContext: none separadas.

Generation log from search through independent LLM requests and document saves

5. Primeira Visão do AEROFLOW Orientada por Especificação

O portal de aviação claro e a estrutura de painel de ações observados na referência da Korean Air foram adaptados para um projeto Godot. A marca, as imagens de aeronaves, os textos e as funcionalidades foram criados especificamente para este resultado.

AEROFLOW first view and flight-build selection panel

6. Destaques do Projeto

A estrutura de cartões de reserva e promoção foi reaproveitada para o conteúdo central do projeto: regiões de voo, cockpit de vidro e clima em tempo real.

Project highlights and new aviation image cards

7. Registro de Desenvolvimento e Atalhos

Os avisos e atalhos de serviço da referência foram reestruturados em histórico de build, progresso de desenvolvimento, modelos de voo, aviônicos, mídia, controles e navegação de roadmap.

AEROFLOW development log and project shortcuts

8. Mídia e Rodapé

A área final contém links de mídia do projeto, desenvolvimento, suporte e licença, seguidos por um rodapé de projeto independente.

AEROFLOW flight-test media and footer

O Que Este Resultado Demonstra

Um novo projeto pode usar uma hierarquia de informações validada e relações de layout sem copiar o logotipo, marcas registradas, textos ou imagens da referência.
Converter capturas de tela estáticas em navegação, limites de pixels, tokens de cores, componentes e uma matriz responsiva dá a outro LLM detalhes suficientes para criar um plano de implementação concreto.
Mesmo com as mesmas evidências estruturais, conteúdo, marca e ativos visuais recém-criados podem gerar uma identidade distinta que difere da fonte.
O Secret MCP tem como objetivo extrair evidências estruturais de bons designs e usá-las para construir um site refinado adequado a um novo projeto, não para reproduzir a fonte pixel por pixel.

Especificação e Contrato de Solicitação

Estes links apontam diretamente para os arquivos reais incluídos no repositório. Os mesmos artefatos também são agrupados em tmp/showcase/aviation-godot por meio de links simbólicos relativos para execução e navegação locais.

Arquitetura Central de Execução

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

Os seguintes limites são essenciais.

Imagens ou corpos de especificação de vários trabalhos nunca são retornados ao LLM host externo em um único lote.
Com limit: 3, o servidor realiza exatamente até três solicitações de amostragem de LLM mutuamente independentes.
Cada solicitação de amostragem usa includeContext: none.
Uma solicitação de amostragem contém apenas os metadados e tiles de imagem de um único trabalho.
O ID, as imagens e o documento de análise do trabalho anterior nunca são passados para a solicitação do trabalho seguinte.
Trabalhos excluídos no visualizador web são removidos dos resultados de busca antes de qualquer solicitação de amostragem ser criada.
O servidor inicia o próximo trabalho somente após salvar a resposta de amostragem atual em um arquivo.
Ao final, apenas os caminhos dos arquivos gerados, o modelo usado e o status de sucesso ou falha são retornados ao host.

Em outras palavras, esta não é a arquitetura anterior em que o LLM host lê todos os resultados de uma vez e produz um resumo combinado.

Visualizador Web

O visualizador web lê DESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runs a cada 2,5 segundos. Não há banco de dados separado ou conexão de depuração entre o processo de geração MCP e o servidor web.

A interface contém as seguintes áreas.

Execuções de geração: consulta, quantidade solicitada, anos permitidos e status geral
Lista de trabalhos: progresso e quantidade de imagens de evidência para cada gdweb-<work-number>
Detalhes do trabalho: especificação, imagens de evidência e medições, contrato de solicitação e registro de geração de um trabalho selecionado
Exclusões de busca: excluir o trabalho selecionado de buscas futuras, incluí-lo novamente e gerenciar a lista completa de exclusões

Quando uma execução contém três trabalhos, ela também produz três documentos, conforme mostrado abaixo.

.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 não é um arquivo que combina corpos de documentos de vários trabalhos. É um manifesto do visualizador contendo apenas caminhos de arquivos por trabalho, status, carimbos de data/hora, modelo e listas de evidências.

Lista de Exclusão de Busca

Selecionar Exclude from search no visualizador web salva o número do trabalho no seguinte arquivo.

DESIGN_INDEX_OUTPUT_DIR/.secret-mcp/exclusions.json

Execuções históricas e documentos gerados nunca são excluídos.
Novas execuções de generate-gdweb-design-indexes e search-gdweb-designs filtram os números dos trabalhos antes da seleção.
Para evitar retornar poucos resultados devido a exclusões, a busca lê candidatos adicionais do GDWEB e seleciona o limit solicitado entre os trabalhos não excluídos.
Selecionar Remove exclusion torna o trabalho elegível novamente a partir da próxima busca.
O servidor MCP e o visualizador web devem usar o mesmo DESIGN_INDEX_OUTPUT_DIR para compartilhar a mesma lista de exclusões.

Processamento de Imagens

As capturas completas de desktop do GDWEB podem ser extremamente altas e ter vários megabytes. Enviar os dados base64 originais diretamente em uma solicitação de amostragem pode exceder os limites de transporte do MCP ou fazer com que um modelo de visão perca detalhes estruturais finos.

Antes de criar a solicitação para cada trabalho, o gdweb-sampling-images.ts realiza as seguintes operações.

Carrega a imagem de registro de desktop do GDWEB com sgbn=1
Carrega a imagem de registro de mobile do GDWEB com sgbn=3
Redimensiona a imagem de desktop para uma largura máxima de 1200px
Divide uma página longa em tiles verticais sobrepostos de 1600px de altura
Preserva a imagem de mobile como evidência separada
Comprime as evidências como JPEG para reduzir o tamanho da solicitação de amostragem do MCP
Registra as dimensões originais e preparadas do canvas, o fator de escala, as coordenadas x/y/width/height preparadas, as coordenadas no espaço de origem e a URL de origem de cada tile
Mede oito cores representativas de cada tile e registra HEX, RGB, HSL e cobertura de pixels

Vários tiles de um trabalho são incluídos na mesma solicitação de amostragem específica do trabalho. Tiles de trabalhos diferentes nunca são incluídos na mesma solicitação.

As cores representativas são medições amostradas de pixels normalizados de capturas de tela. São evidências precisas para comparação visual, mas não devem ser apresentadas como variáveis CSS do site de origem, pois o erro JPEG e o conteúdo da imagem afetam os valores. O contrato de geração distingue cores MEASURED de tokens de implementação INFERRED.

O servidor não abre o site de produção ao vivo do trabalho nem rastreia seu DOM. As evidências visuais são limitadas às imagens e metadados registrados no GDWEB.

Busca no GDWEB

A busca de design não usa automação de navegador, Bing, Brave ou 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 Atualidade

Se year for omitido, o ano atual da execução é usado.
includePreviousYear tem como padrão true.
Quando executado em 2026, apenas trabalhos registrados em 2026 e 2025 são permitidos por padrão.
Com includePreviousYear: false, apenas o ano alvo é permitido.
awardOnly tem como padrão true, portanto trabalhos sem nome de prêmio são excluídos.
limit pode ser definido de 1 a 10.

Metadados do Trabalho

Campo	Descrição
`strNo`	Número do trabalho no GDWEB, também usado no nome do arquivo do documento
`txtFgbn`	Valor da categoria do trabalho no GDWEB
`title`	Título do trabalho
`gdwebUrl`	Página de detalhes do trabalho no GDWEB
`registeredDate` / `registeredYear`	Data de registro e o ano usado para filtragem
`award`	Nome do prêmio
`concept`	Conceito de design
`primaryColor`	Cor primária
`productionCompany`	Empresa produtora
`desktopImageUrl`	Captura de desktop do GDWEB (`sgbn=1`)
`mobileImageUrl`	Captura de mobile do GDWEB (`sgbn=3`)

Especificação DESIGN_INDEX

Cada solicitação independente de amostragem inclui o contrato secret-mcp/design-index/v2. O nome de arquivo resultante é DESIGN_INDEX_gdweb-<strNo>.md.

Há um arquivo por trabalho, mas cada arquivo começa com um inventário de páginas e rotas e repete uma subseção completa para cada página verificada. O contrato não confunde seções em uma captura longa com rolagem com páginas separadas; ele divide páginas apenas quando a colagem de evidências contém visivelmente telas separadas.

Todo documento deve conter todas as 19 seções numeradas abaixo.

Área	Especificação obrigatória
Objetivo da reconstrução	ID de referência, fidelidade alvo, rotas, viewports alvo e não objetivos
Evidências e sistema de coordenadas	IDs de imagem, dimensões originais/preparadas, escala, coordenadas de tile, coordenadas no espaço de origem e método de remoção de sobreposição
Mapa do site	Páginas e rotas verificadas, finalidade, imagens de evidência, shell compartilhado, menu ativo e confiança
Shell compartilhado do aplicativo	Fundo global, contêiner, gutters, sobreposições, chrome da página e contexto de empilhamento
Navegação	Alturas para desktop e mobile, coordenadas de logo/menu, espaçamentos, áreas de toque e estados ativo/hover/foco/aberto
Especificação por página e tabela de coordenadas	Modelo de canvas, ordem das seções, x/y/largura/altura, layout, estados, dados e nível de evidência para cada página
Análise aprofundada do layout	DOM, grid/flex, tracks, min/max, proporções, espaçamentos, overflow, sticky, absoluto e z-index
Abstração de componentes	Árvore de componentes vinculada à página, props, variantes, slots, estado, eventos e contratos de dados
Tokens e cores exatas	HEX/RGB/HSL/alpha, uso, coordenadas de medição, confiança, tolerância e variáveis CSS
Tipografia	Família de fonte por função, px/rem, peso, altura de linha, espaçamento entre letras, alinhamento, truncamento e valores responsivos
Assets e ícones	Página e seção, tamanho de exibição, proporção, corte, ponto focal, object-fit, carregamento e estratégia de fallback
Matriz responsiva	Contêineres, colunas, ordem, visibilidade, navegação e espaçamento em 1440/1280/1024/768/390/360px
Interação e movimento	Cor, opacidade, transform, duração, easing, teclado e comportamento de movimento reduzido para cada estado
Acessibilidade	Landmarks por página, cabeçalhos, foco, semântica de menu, rótulos, texto alternativo, contraste e alvos de toque
Dados e conteúdo	Entidades por página, campos, contagens, ordenação, formatos, localização e fixtures de carregamento/vazio/erro
Arquitetura de frontend	Rotas, diretórios, módulos de página/compartilhados, tokens, assets, estado e limites servidor/cliente
Grafo de tarefas de implementação	Medição, shell, navegação, IDs de tarefas por página, dependências, entregáveis e critérios de conclusão
Critérios de aceite por página	Tolerâncias de coordenadas, cores e tipografia; comparação de viewport; overflow; assets; teclado; e desempenho
Incertezas e decisões	UNKNOWNs por página e seção, valores adotados, alternativas, confiança e evidências adicionais necessárias

Cada julgamento importante é marcado com um dos seguintes níveis de evidência.

OBSERVED: diretamente visível em uma imagem GDWEB ou metadados
MEASURED: verificado numericamente a partir de coordenadas de pixel fornecidas ou da paleta medida
INFERRED: razoavelmente inferido para reproduzir o mesmo resultado
UNKNOWN: não pode ser verificado a partir de evidências estáticas e não deve ser afirmado como fato

Outro LLM deve ser capaz de derivar a árvore de componentes, tokens, regras responsivas, assets, ordem de implementação e itens de validação apenas a partir do documento concluído.

Ferramentas Expostas

O servidor atualmente expõe cinco ferramentas MCP.

Ferramenta	Finalidade
`generate-gdweb-design-indexes`	Pesquisar no GDWEB, fazer uma solicitação LLM isolada por resultado e salvar documentos
`search-gdweb-designs`	Retornar uma lista de referências do GDWEB sem gerar especificações
`full-web-search`	Pesquisar na web geral e extrair o conteúdo completo da página
`get-web-search-summaries`	Retornar títulos, URLs e descrições de uma pesquisa geral
`get-single-web-page-content`	Extrair o conteúdo completo de uma página web geral conhecida

Use generate-gdweb-design-indexes para planejamento de design, análise de layout, especificações de implementação e solicitações DESIGN_INDEX. Use search-gdweb-designs apenas para solicitações de listas leves.

Estrutura da Fonte

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

Desenvolvimento e Validação

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

O teste de fumaça de isolamento conecta um cliente MCP simulado que suporta amostragem e verifica o seguinte comportamento.

O número de resultados de pesquisa é igual ao número de solicitações de amostragem.
Cada solicitação de amostragem contém exatamente um ID de referência.
Nenhum ID de outro trabalho é misturado em uma solicitação.
Cada solicitação usa includeContext: none.
Cada solicitação inclui imagens GDWEB.
Cada resultado cria um arquivo Markdown separado.
Um trabalho excluído não entra em resultados de pesquisa subsequentes ou solicitações de amostragem.
O contrato de especificação contém requisitos por página, navegação, coordenadas e cores.
A evidência do manifesto de execução registra coordenadas de tile e paletas medidas.

Variáveis de Ambiente em Tempo de Execução

Nome	Padrão	Descrição
`DESIGN_INDEX_OUTPUT_DIR`	`./design-index`	Diretório onde os documentos gerados são armazenados
`SECRET_MCP_WEB_ORIGIN`	`http://127.0.0.1:4317`	Endereço do visualizador web incluído nos resultados MCP
`SECRET_MCP_WEB_HOST`	`127.0.0.1`	Endereço de bind do servidor web
`SECRET_MCP_WEB_PORT`	`4317`	Porta do servidor web
`MCP_SAMPLING_TIMEOUT_MS`	`1800000`	Tempo limite para cada solicitação LLM independente por trabalho em milissegundos
`MAX_CONTENT_LENGTH`	`500000`	Comprimento máximo do corpo da página extraído de uma página web geral
`DEFAULT_TIMEOUT`	`6000`	Tempo limite para solicitações HTTP gerais e de navegador
`MAX_BROWSERS`	`3`	Número máximo de navegadores usados para extração geral
`BROWSER_TYPES`	`chromium,firefox`	Navegadores usados para pesquisa e extração gerais
`BROWSER_HEADLESS`	`true`	Se o Playwright executa em modo headless
`FORCE_MULTI_ENGINE_SEARCH`	`false`	Se deve comparar cada mecanismo durante a pesquisa geral
`DEBUG_BROWSER_LIFECYCLE`	`false`	Se deve imprimir logs do ciclo de vida do navegador

Documentação

Trabalhos Relacionados e Referências

Secret MCP está posicionado como um artefato de implementação adjacente à compreensão multimodal de UI e à pesquisa de screenshot-para-código. Ainda não foi avaliado nos conjuntos de dados ou métricas usados pelos artigos abaixo, portanto, seus resultados não devem ser interpretados como resultados do Secret MCP.

Chenglei Si, Yanzhe Zhang, Ryan Li, Zhengyuan Yang, Ruibo Liu e Diyi Yang. Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering. NAACL 2025. Apresenta avaliação de screenshot-para-código do mundo real com métricas visuais e de nível de elemento. Paper
Bryan Wang, Gang Li, Xin Zhou, Zhourong Chen, Tovi Grossman e Yang Li. Screen2Words: Automatic Mobile UI Summarization with Multimodal Learning. UIST 2021. Estuda representações que combinam screenshot, texto, estrutura e 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 e Daniel Fried. VisualWebArena: Evaluating Multimodal Agents on Realistic Visually Grounded Web Tasks. ACL 2024. Estabelece a importância e a dificuldade da avaliação de agentes web com base visual. Paper
Model Context Protocol. Especificação de amostragem. Define sampling/createMessage mediado pelo cliente, incluindo mensagens de solicitação, preferências de modelo, orçamentos de tokens e controles de contexto. Especificação

Citação

Secret MCP é atualmente um software com uma nota de pesquisa funcional, não uma publicação 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}
}