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 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. **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 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. 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. ``` `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. ``` `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. *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. - 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. 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` ``` 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. 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. ``` `{ "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 long enough for the per-work output budget and must never answer multiple sampling requests through one persistent LLM conversation. A separate`/web-design`slash 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 the`generate-gdweb-design-indexes`tool 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 } }` ``` If`outputDirectory`is omitted, the tool uses the`DESIGN_INDEX_OUTPUT_DIR`environment variable. If that variable is also absent, it uses the`design-index`directory under the server's working directory. `maxTokens`is 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 therefore`131072`tokens. Clients may request up to`262144`tokens for exceptionally large multi-page evidence sets. With`limit: 3`, the default run can request up to three independent`131072`-token outputs; the works do not share one`131072`-token pool. The connected sampling client and selected model must support the requested output size. If the model returns`stopReason: maxTokens`, the server treats that work as failed instead of saving a truncated`DESIGN_INDEX`as 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 a`DESIGN_INDEX`for each work through an independent LLM request, and then applied the structure of the Korean Air reference to a Godot aviation project website. The finished`AEROFLOW`website 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 that**even 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:4317/?run=2026-07-29T15-54-10-483Z-5c70317e)[http://127.0.0.1:4320 Select works one at a time from the run list on the left. The right side displays only the final`DESIGN_INDEX`for the selected work, without mixing in content from other works. The`Evidence`tab shows the desktop and mobile images sent to the independent LLM request, tile coordinates, reduction ratios, and representative colors. The`Request Contract`records page separation, navigation, section bounds, HEX/RGB/HSL colors, components, the responsive matrix, and acceptance criteria. This contract prevents the result from ending as a superficial mood summary and makes it an implementation specification another LLM can use. The`Generation Log`shows the sequence from search and evidence preparation through the independent per-work LLM request, document save, and full-run completion. This run processed all three works with separate`includeContext: none`requests. ### 5. Specification-Driven AEROFLOW First View The bright aviation portal and action-panel structure observed in the Korean Air reference were adapted to a Godot project. The brand, aircraft imagery, copy, and functionality were created specifically for this result. The reservation and promotion card structure was repurposed for core project content: flight regions, a glass cockpit, and real-time weather. The source reference's notices and service shortcuts were restructured into build history, development progress, flight models, avionics, media, controls, and roadmap navigation. The final area contains project media, development, support, and license links, followed by an independent-project footer. - A new project can use a validated information hierarchy and layout relationships without copying the reference's logo, trademarks, copy, or images. - Converting static screenshots into navigation, pixel bounds, color tokens, components, and a responsive matrix gives another LLM enough detail to create a concrete implementation plan. - Even with the same structural evidence, newly designed content, branding, and visual assets can create a distinctive identity that differs from the source. - Secret MCP is intended to extract structural evidence from good design and use it to build a polished website suited to a new project, not to reproduce the source pixel for pixel. - ](http://127.0.0.1:4320)[Korean Air DESIGN_INDEX specification - ](https://github.com/yyeongjin/secret_mcp/blob/HEAD/tmp/design-index/aviation-godot-20260730/.secret-mcp-runs/2026-07-29T15-54-10-483Z-5c70317e/documents/DESIGN_INDEX_gdweb-27294.md)[Independent LLM request contract - ](https://github.com/yyeongjin/secret_mcp/blob/HEAD/tmp/design-index/aviation-godot-20260730/.secret-mcp-runs/2026-07-29T15-54-10-483Z-5c70317e/contracts/gdweb-27294.md)[Run manifest - ](https://github.com/yyeongjin/secret_mcp/blob/HEAD/tmp/design-index/aviation-godot-20260730/.secret-mcp-runs/2026-07-29T15-54-10-483Z-5c70317e/run.json)[Generated website source These links point directly to the actual files included in the repository. The same artifacts are also grouped under`tmp/showcase/aviation-godot`through relative symbolic links for local execution and browsing. ``` `flowchart TD User](https://github.com/yyeongjin/secret_mcp/blob/HEAD/tmp/reconstructions/gdweb-27294-godot/index.html)["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. - With`limit: 3`, the server performs exactly up to three mutually independent LLM sampling requests. - Every sampling request uses`includeContext: 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 reads`DESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runs`every 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 each`gdweb-<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.json`is 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. Selecting`Exclude from search`in 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. - New`generate-gdweb-design-indexes`and`search-gdweb-designs`runs filter work numbers before selection. - To avoid returning too few results because of exclusions, the search reads additional GDWEB candidates and selects the requested`limit`from the non-excluded works. - Selecting`Remove exclusion`makes the work eligible again starting with the next search. - The MCP server and web viewer must use the same`DESIGN_INDEX_OUTPUT_DIR`to 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.ts`performs the following operations. - Load the GDWEB desktop registration image with`sgbn=1` - Load the GDWEB mobile registration image with`sgbn=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, prepared`x/y/width/height`coordinates, 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 distinguishes`MEASURED`colors from`INFERRED`implementation 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.