Secret MCP

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

Secret MCP is a local Model Context Protocol (MCP) server that searches GDWEB for recent design references andcreates a separate LLM request and a separateDESIGN_INDEXfile 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 nameSecret MCPdoes 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 MCPsampling/createMessagerequest 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.

Evidence-Isolated Multimodal Design Analysis through MCP Sampling

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

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 oneDESIGN_INDEXdocument. Each request asks forincludeContext: noneand 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.

For referencer_i, the prepared evidence set contains image tilesI, crop boundsB, representative-color measurementsP, and source metadataM. The fixed specification contract isC; the independent request and resulting document areq_iandD_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.

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 = 2sampled references after excludinggdweb-26905). Each request contained its own reference ID and visual evidence, no other sampled reference ID, andincludeContext: none; the run produced two distinct Markdown files. The test verifies observable request composition and file separation, not model-memory behavior outside the protocol.

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 run2026-07-29T15-54-10-483Z-5c70317e(n = 3references). The run prepared 12 evidence images totaling 816.9 decimal KB and recorded 96 representative-color measurements. It produced threeDESIGN_INDEXdocuments totaling 27,391 whitespace-delimited tokens and 187.0 decimal KB. All three contain headings 1–19; heading presence does not establish semantic correctness.

Figure 3.A preserved qualitative trace from the GDWEB evidence viewer to the generated Korean AirDESIGN_INDEXand 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.

- The live isolation result hasn = 2; the recorded artifact analysis hasn = 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.

The published MCP server can be launched with:

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

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

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; onlyExclude from searchandRemove exclusionchange the filter used by subsequent searches.

{ "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, replacecommandandargswith"command": "node"and"args": ["/absolute/path/to/secret_mcp/dist/index.js"].

The MCP client must supportsampling/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 launchesnode dist/index.jsas a child process and exchanges JSON-RPC messages over stdio. Only the separate web viewer process uses port4317by default.

Direct Sampling Client for Hosts Without Sampling

The server does not need to be modified when the outer MCP host cannot answersampling/createMessage. A separate MCP protocol client can connect directly todist/index.js, advertisesampling: {}, 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-levelincludeContext: noneboundary without adding a combined fallback to the server. The direct client becomes the sampling-capable MCP host; it should use a tool-call timeout long enough for the per-work output budget and must never answer multiple sampling requests through one persistent LLM conversation.

A separate/web-designslash command is not required.

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.

The host LLM calls thegenerate-gdweb-design-indexestool once. The MCP server performs the search and separates the per-work LLM requests internally.

The manual tool-call format is shown below.

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

IfoutputDirectoryis omitted, the tool uses theDESIGN_INDEX_OUTPUT_DIRenvironment variable. If that variable is also absent, it uses thedesign-indexdirectory under the server's working directory.

maxTokensis a per-work output budget, not a budget shared by the run and not a budget divided equally between pages. A single work may contain multiple visible pages or routes, and every page must repeat the complete page-specific parts of the 19-section contract. The default and minimum are therefore131072tokens. Clients may request up to262144tokens for exceptionally large multi-page evidence sets.

Withlimit: 3, the default run can request up to three independent131072-token outputs; the works do not share one131072-token pool. The connected sampling client and selected model must support the requested output size. If the model returnsstopReason: maxTokens, the server treats that work as failed instead of saving a truncatedDESIGN_INDEXas complete.

When the tool completes, it returns the run ID, run-manifest path, per-work document paths, and web-viewer URL.

End-to-End Example: From GDWEB Specifications to a Godot Aviation Website

For the actual example, Secret MCP found three aviation award winners registered on GDWEB in 2026 and 2025, created aDESIGN_INDEXfor each work through an independent LLM request, and then applied the structure of the Korean Air reference to a Godot aviation project website.

The finishedAEROFLOWwebsite is not a clone of the Korean Air website. It uses the information hierarchy, navigation, action panel, section arrangement, and responsive principles from the specification while introducing a new brand, copy, aviation imagery, and content. This example demonstrates thateven when the resulting design differs from the reference, measurable structural evidence can still produce a polished website with a distinctive identity.

# 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

After starting the processes, open the following screens.

- Per-work specification web viewer:http://127.0.0.1:4317/?run=2026-07-29T15-54-10-483Z-5c70317e
- AEROFLOW result website:http://127.0.0.1:4320

- Korean Air DESIGN_INDEX specification
- Independent LLM request contract
- Run manifest
- Generated website source

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

- Images or specification bodies from multiple works are never returned to the outer host LLM as one batch.
- Withlimit: 3, the server performs exactly up to three mutually independent LLM sampling requests.
- Every sampling request usesincludeContext: none.
- A sampling request contains only one work's metadata and image tiles.
- The previous work's ID, images, and analysis document are never passed into the next work's request.
- Works excluded in the web viewer are removed from search results before any sampling request is created.
- The server starts the next work only after saving the current sampling response to a file.
- At the end, only generated file paths, the model used, and success or failure status are returned to the host.

In other words, this is not the earlier architecture in which the host LLM reads every result at once and produces a combined summary.

The web viewer readsDESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runsevery 2.5 seconds. There is no separate database or debugging connection between the MCP generation process and the web server.

The interface contains the following areas.

- Generation runs: query, requested count, allowed years, and overall status
- Work list: progress and evidence-image count for eachgdweb-<work-number>
- Work details: specification, evidence images and measurements, request contract, and generation log for one selected work
- Search exclusions: exclude the selected work from future searches, include it again, and manage the full exclusion list

When a run contains three works, it also produces three documents as shown below.

.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.jsonis not a file that combines document bodies from multiple works. It is a viewer manifest containing only per-work file paths, status, timestamps, model, and evidence lists.

SelectingExclude from searchin the web viewer saves the work number to the following file.

DESIGN_INDEX_OUTPUT_DIR/.secret-mcp/exclusions.json

- Historical runs and generated documents are never deleted.
- Newgenerate-gdweb-design-indexesandsearch-gdweb-designsruns filter work numbers before selection.
- To avoid returning too few results because of exclusions, the search reads additional GDWEB candidates and selects the requestedlimitfrom the non-excluded works.
- SelectingRemove exclusionmakes the work eligible again starting with the next search.
- The MCP server and web viewer must use the sameDESIGN_INDEX_OUTPUT_DIRto share the same exclusion list.

GDWEB's full desktop captures can be extremely tall and several megabytes in size. Sending the original base64 data directly in a sampling request can exceed MCP transport limits or cause a vision model to miss fine structural details.

Before creating the request for each work,gdweb-sampling-images.tsperforms the following operations.

- Load the GDWEB desktop registration image withsgbn=1
- Load the GDWEB mobile registration image withsgbn=3
- Resize the desktop image to a maximum width of 1200px
- Split a long page into overlapping vertical tiles 1600px high
- Preserve the mobile image as separate evidence
- Compress the evidence as JPEG to reduce the MCP sampling-request size
- Record the original and prepared canvas dimensions, scale factor, preparedx/y/width/heightcoordinates, source-space coordinates, and source URL for every tile
- Measure eight representative colors from every tile and record HEX, RGB, HSL, and pixel coverage

Multiple tiles from one work are included in the same work-specific sampling request. Tiles from different works are never included in the same request.

Representative colors are measurements sampled from normalized screenshot pixels. They are precise evidence for visual comparison, but they must not be presented as the source site's CSS variables because JPEG error and image content affect the values. The generation contract distinguishesMEASUREDcolors fromINFERREDimplementation tokens.

The server does not open the work's live production website or crawl its DOM. Visual evidence is limited to the images and metadata registered on GDWEB.