Secret MCP

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 5 evidence images includeContext: none"] --> D1["DESIGN_INDEX_gdweb-26522.md"] R2["gdweb-24516"] --> Q2["Request 2 4 evidence images 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

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

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 context.

The MCP stdio server itself does not open an HTTP port. The client launches node dist/index.js as a child process and exchanges JSON-RPC messages over stdio. Only the separate web viewer process uses port 4317 by default.

Direct Sampling Client for Hosts Without Sampling

The server does not need to be modified when the outer MCP host cannot answer sampling/createMessage. A separate MCP protocol client can connect directly to dist/index.js, advertise sampling: {}, and handle every sampling request by launching a fresh Codex LLM process in a fresh temporary workspace.

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

The sampling handler must copy only the current request's text blocks and evidence images into that workspace. It must not reuse a Codex conversation, process, working directory, response file, or message history from another work. The workspace launches one new Codex process, waits for its complete Markdown response, returns that response to the pending MCP sampling call, and can then be removed after the server has saved the work's contract, evidence, and document.

The server still controls the sequential queue: work 2 is not prepared until work 1 has returned and been saved. This makes the fresh process and workspace an execution-level equivalent of the protocol-level includeContext: none boundary without adding a combined fallback to the server. The direct client becomes the sampling-capable MCP host; it should use a tool-call timeout