English | 한국어

Target Architecture

Secret MCP

An evidence-grounded MCP server for web design analysis, screenshot-to-specification workflows, and frontend reconstruction planning.

npx -y secret-design-mcp

Secret MCP is a local Model Context Protocol (MCP) server that searches GDWEB for recent design references and creates a separate LLM request and a separate DESIGN_INDEX file for every search result. Each file contains page- and route-specific layouts, navigation, pixel coordinates, colors, components, and responsive specifications traceable to the supplied visual evidence.

The name Secret MCP does not mean that the project provides secret features or private data. It was the project name used while experimenting in a private repository with the idea of building an MCP server around design websites. The project's current purpose is to extract reproducible structural evidence from public design references and turn it into one specification per work that an LLM can apply to a new project.

Images and descriptions from multiple works are never combined in a single LLM context or document. The server processes search results sequentially inside the server, creates an independent MCP sampling/createMessage request for each work, saves that work's file, and only then advances to the next work. A separate local web application lets you select one work at a time, inspect its source evidence, measured colors and coordinates, LLM contract, generation log, and final document, and manage the exclusion list for subsequent searches.

Research Note

Evidence-Isolated Multimodal Design Analysis through MCP Sampling

Working paper and implementation report · Secret MCP v0.6.0 · not peer reviewed

Abstract

Secret MCP implements an auditable pipeline for converting public webpage screenshots into implementation-oriented design specifications. The system prepares desktop and mobile visual evidence, records crop coordinates and representative pixel colors, and invokes client-side MCP sampling once per reference. Unlike workflows that concatenate several design references into one prompt, Secret MCP treats reference identity as both a request boundary and an artifact boundary: one reference produces one sampling request, one request contract, and one DESIGN_INDEX document. Each request asks for includeContext: none and applies the same 19-section specification contract covering routes, geometry, components, design tokens, responsive behavior, accessibility, implementation tasks, acceptance criteria, and uncertainty. This report evaluates protocol-level isolation and artifact production; it does not claim that one language model, prompt, or reconstruction method outperforms another. A live smoke test verifies the request boundary, while a preserved three-reference run provides descriptive measurements and a qualitative implementation case.

Research Questions

Formal System Model

For reference r_i, the prepared evidence set contains image tiles I, crop bounds B, representative-color measurements P, and source metadata M. The fixed specification contract is C; the independent request and resulting document are q_i and 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

Coordinates measured inside a prepared tile map back to the original screenshot as follows.

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

This is an operational isolation invariant, not a claim of statistical independence. The server and smoke test can inspect request contents and artifacts; they cannot prove what an arbitrary external model provider may retain outside the MCP message.

Empirical Results

Protocol Isolation

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

Figure 1. Live smoke test recorded on 2026-08-22 using the query 금융 (n = 2 sampled references after excluding gdweb-26905). Each request contained its own reference ID and visual evidence, no other sampled reference ID, and includeContext: none; the run produced two distinct Markdown files. The test verifies observable request composition and file separation, not model-memory behavior outside the protocol.

Recorded Run Measurements

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]

Figure 2. Descriptive measurements from preserved run 2026-07-29T15-54-10-483Z-5c70317e (n = 3 references). The run prepared 12 evidence images totaling 816.9 decimal KB and recorded 96 representative-color measurements. It produced three DESIGN_INDEX documents totaling 27,391 whitespace-delimited tokens and 187.0 decimal KB. All three contain headings 1–19; heading presence does not establish semantic correctness.

Qualitative Case Study

(a) Evidence and measurements	(b) Per-reference DESIGN_INDEX	(c) Specification-driven implementation

Figure 3. A preserved qualitative trace from the GDWEB evidence viewer to the generated Korean Air DESIGN_INDEX and then to AEROFLOW. AEROFLOW intentionally introduces new branding, content, imagery, and functionality; this example illustrates specification use and is not a controlled visual-fidelity comparison.

Interpretation and Limitations

• The live isolation result has n = 2; the recorded artifact analysis has n = 3. Neither supports broad claims about design quality or model performance.
• The current evaluation has no control group, human rating, repeated trials, confidence intervals, or comparison against screenshot-to-code baselines.
• Representative colors are measured after resizing, JPEG normalization, and channel quantization. They are screenshot evidence, not proof of the source website's CSS tokens.
• The 19/19 result measures required heading presence. A future benchmark must separately evaluate factual grounding, coordinate error, color difference, responsive behavior, and implementation fidelity.
• The qualitative implementation is an existence example, not evidence that Secret MCP improves reconstruction quality.

Usage

1. Install and Build

Node.js 20.19 or later is required.

The published MCP server can be launched with:

npx -y secret-design-mcp

Clone the repository when you also need the local viewer or want to work on the source:

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

2. Start the Web Application

Set DESIGN_INDEX_OUTPUT_DIR to the same value for the MCP server and the web application so that both processes read the same output directory.

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

Open the following address in a browser.

http://127.0.0.1:4317

The web application displays the generation-run list, per-work progress, GDWEB evidence images, measured coordinates and palettes, the specification contract sent to the LLM, the final Markdown, and generation timestamps. Documents and evidence are read-only; only Exclude from search and Remove exclusion change the filter used by subsequent searches.

3. Register the MCP Server

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

For a source checkout, replace command and args with "command": "node" and "args": ["/absolute/path/to/secret_mcp/dist/index.js"].