secret_mcp

**English** | [한국어](README.ko.md)

## Target Architecture

![Secret MCP target architecture](docs/assets/target-architecture.png)

---

# Secret MCP

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

```bash
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

| Question | Current evidence | Status |
| --- | --- | --- |
| **RQ1.** Can an MCP design-analysis tool maintain one-reference-per-request isolation? | Live sampling smoke test with cross-reference ID inspection and output-file checks | Verified within the test scope |
| **RQ2.** Can screenshot evidence be transformed into auditable spatial, color, and document artifacts? | Preserved three-reference run with evidence manifests, contracts, and generated documents | Descriptively verified |
| **RQ3.** Can the resulting specification guide a distinct frontend implementation? | AEROFLOW qualitative case study | Preliminary; no controlled comparison |

### 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`.

```text
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.

```text
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

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

| Sampling request | `gdweb-26522` present | `gdweb-24516` present | Output documents |
| --- | ---: | ---: | ---: |
| Request 1 | 1 | 0 | 1 |
| Request 2 | 0 | 1 | 1 |

*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

```mermaid
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]
```

| Reference | Desktop source height | Prepared images | Image payload | Color measurements | Document tokens | Document size | Required headings |
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| `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 |

*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 |
| --- | --- | --- |
| ![Actual Secret MCP evidence viewer](tmp/showcase/aviation-godot/screenshots/02-evidence-view.png) | ![Actual per-reference DESIGN_INDEX](tmp/showcase/aviation-godot/screenshots/01-design-index-view.png) | ![Actual AEROFLOW implementation](tmp/showcase/aviation-godot/screenshots/05-generated-site-hero.png) |

*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:

```bash
npx -y secret-design-mcp
```

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

```bash
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.

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

Open the following address in a browser.

```text
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

```json
{
  "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"]`.

The MCP client must support `sampling/createMessage`. When a client does not support sampling, the server returns an explicit error instead of running a fallback that places multiple works in the same co