English | 한국어

目标架构

Secret MCP

一个基于证据的 MCP 服务器，用于网页设计分析、截图到规范的工作流以及前端重建规划。

npx -y secret-design-mcp

Secret MCP 是一个本地 Model Context Protocol (MCP) 服务器，它搜索 GDWEB 以获取近期设计参考，并为每个搜索结果创建单独的 LLM 请求和单独的 DESIGN_INDEX 文件。每个文件包含页面和路由特定的布局、导航、像素坐标、颜色、组件以及可追溯到所提供的视觉证据的响应式规范。

名称 Secret MCP 并不意味着该项目提供秘密功能或私有数据。它是在私有仓库中围绕设计网站构建 MCP 服务器的想法进行实验时使用的项目名称。该项目当前的目标是从公开的设计参考中提取可复现的结构性证据，并将其转化为每个作品一份的规范，供 LLM 应用于新项目。

来自多个作品的图像和描述绝不会合并到单个 LLM 上下文或文档中。服务器在服务器内部按顺序处理搜索结果，为每个作品创建独立的 MCP sampling/createMessage 请求，保存该作品的文件，然后才推进到下一个作品。单独的本地 Web 应用程序允许您一次选择一个作品，检查其源证据、测量的颜色和坐标、LLM 契约、生成日志和最终文档，并管理后续搜索的排除列表。

Related MCP server: Refero MCP

研究说明

通过 MCP 采样进行证据隔离的多模态设计分析

工作论文与实现报告 · Secret MCP v0.6.0 · 未经同行评审

摘要

Secret MCP 实现了一个可审计的流水线，用于将公开网页截图转换为面向实现的的设计规范。系统准备桌面和移动视觉证据，记录裁剪坐标和代表性像素颜色，并为每个参考调用一次客户端 MCP 采样。与将多个设计参考拼接到一个提示中的工作流不同，Secret MCP 将参考身份同时视为请求边界和产物边界：一个参考产生一个采样请求、一个请求契约和一个 DESIGN_INDEX 文档。每个请求都要求 includeContext: none，并应用相同的 19 节规范契约，涵盖路由、几何、组件、设计令牌、响应式行为、可访问性、实现任务、验收标准和不确定性。本报告评估协议级隔离和产物生产；它不声称某一种语言模型、提示或重建方法优于另一种。实时冒烟测试验证了请求边界，而保留的三参考运行提供了描述性测量和定性实现案例。

研究问题

形式化系统模型

对于参考 r_i，准备好的证据集包含图像切片 I、裁剪边界 B、代表性颜色测量 P 和源元数据 M。固定的规范契约是 C；独立的请求和生成的文档是 q_i 和 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

在准备好的切片内测量的坐标按如下方式映射回原始截图。

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

这是一个操作层面的隔离不变量，而非统计独立性的声明。服务器和冒烟测试可以检查请求内容和产物；它们无法证明任意外部模型提供商在 MCP 消息之外可能保留什么。

实证结果

协议隔离

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

图 1. 2026-08-22 记录的实时冒烟测试，使用查询 금융（排除 gdweb-26905 后采样 n = 2 个参考）。每个请求包含自己的参考 ID 和视觉证据，不包含其他采样的参考 ID，并且 includeContext: none；该运行生成了两个不同的 Markdown 文件。该测试验证可观察的请求组成和文件分离，而非协议之外的模型记忆行为。

记录运行测量

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]

图 2. 来自保留运行 2026-07-29T15-54-10-483Z-5c70317e（n = 3 个参考）的描述性测量。该运行准备了 12 张证据图像，总计 816.9 十进制 KB，并记录了 96 个代表性颜色测量。它生成了三个 DESIGN_INDEX 文档，总计 27,391 个以空白分隔的词元和 187.0 十进制 KB。所有三个都包含标题 1–19；标题的存在并不确立语义正确性。

定性案例研究

图 3. 从 GDWEB 证据查看器到生成的 Korean Air DESIGN_INDEX 再到 AEROFLOW 的保留定性追踪。AEROFLOW 有意引入新的品牌、内容、图像和功能；此示例说明规范的使用，而非受控的视觉保真度比较。

解释与局限性

• 实时隔离结果有 n = 2；记录的产物分析有 n = 3。两者都不支持关于设计质量或模型性能的广泛声明。

• 当前评估没有对照组、人工评分、重复试验、置信区间，或与截图转代码基线的比较。

• 代表性颜色是在调整大小、JPEG 归一化和通道量化后测量的。它们是截图证据，而非源网站 CSS 令牌的证明。

• 19/19 的结果衡量必需标题的存在。未来的基准必须分别评估事实依据、坐标误差、颜色差异、响应式行为和实现保真度。

• 定性实现是一个存在性示例，而非 Secret MCP 提高重建质量的证据。

使用方法

1. 安装与构建

需要 Node.js 20.19 或更高版本。

已发布的 MCP 服务器可以通过以下方式启动：

npx -y secret-design-mcp

当您还需要本地查看器或想要处理源代码时，请克隆仓库：

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

2. 启动 Web 应用程序

为 MCP 服务器和 Web 应用程序将 DESIGN_INDEX_OUTPUT_DIR 设置为相同的值，以便两个进程读取相同的输出目录。

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

在浏览器中打开以下地址。

http://127.0.0.1:4317

Web 应用程序显示生成运行列表、每项工作的进度、GDWEB 证据图像、测量的坐标和调色板、发送给 LLM 的规范契约、最终的 Markdown 以及生成时间戳。文档和证据是只读的；只有 Exclude from search 和 Remove exclusion 会更改后续搜索使用的过滤器。

3. 注册 MCP 服务器

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

对于源代码检出，将 command 和 args 替换为 "command": "node" 和 "args": ["/absolute/path/to/secret_mcp/dist/index.js"]。

MCP 客户端必须支持 sampling/createMessage。当客户端不支持采样时，服务器返回显式错误，而不是运行将多个工作放在同一上下文中的回退。

MCP stdio 服务器本身不打开 HTTP 端口。客户端将 node dist/index.js 作为子进程启动，并通过 stdio 交换 JSON-RPC 消息。只有单独的 Web 查看器进程默认使用端口 4317。

面向不支持采样的主机的直接采样客户端

当外部 MCP 主机无法响应 sampling/createMessage 时，服务器无需修改。单独的 MCP 协议客户端可以直接连接到 dist/index.js，通告 sampling: {}，并通过在新的临时工作区中启动全新的 Codex LLM 进程来处理每个采样请求。

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

采样处理程序必须仅将当前请求的文本块和证据图像复制到该工作区。它不得重用来自另一项工作的 Codex 对话、进程、工作目录、响应文件或消息历史。工作区启动一个新的 Codex 进程，等待其完整的 Markdown 响应，将该响应返回给挂起的 MCP 采样调用，然后在服务器保存了该工作的契约、证据和文档后即可移除。

服务器仍然控制顺序队列：工作 2 在工作 1 返回并保存之前不会被准备。这使得全新的进程和工作区成为协议级 includeContext: none 边界的执行级等价物，而无需向服务器添加组合回退。直接客户端成为支持采样的 MCP 主机；它应使用足够长的工具调用超时以匹配每项工作的输出预算，并且绝不能通过一个持久的 LLM 对话来响应多个采样请求。

4. 询问 LLM

不需要单独的 /web-design 斜杠命令。

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.

宿主 LLM 调用 generate-gdweb-design-indexes 工具一次。MCP 服务器执行搜索，并在内部将每个作品的 LLM 请求分开处理。

手动工具调用格式如下所示。

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

如果省略 outputDirectory，工具将使用 DESIGN_INDEX_OUTPUT_DIR 环境变量。如果该变量也不存在，则使用服务器工作目录下的 design-index 目录。

maxTokens 是每个作品的输出预算，不是整个运行共享的预算，也不是在页面之间平均分配的预算。单个作品可能包含多个可见页面或路由，每个页面都必须重复 19 节契约中完整的页面专属部分。因此默认值和最小值均为 131072 个 token。对于特别大的多页面证据集，客户端可请求高达 262144 个 token。

使用 limit: 3 时，默认运行最多可请求三个独立的 131072 token 输出；各个作品不共享一个 131072 token 池。所连接的采样客户端和所选模型必须支持请求的输出大小。如果模型返回 stopReason: maxTokens，服务器会将该作品视为失败，而不是将截断的 DESIGN_INDEX 保存为完整结果。

工具完成后，会返回运行 ID、运行清单路径、每个作品的文档路径以及 Web 查看器 URL。

端到端示例：从 GDWEB 规格到 Godot 航空网站

在实际示例中，Secret MCP 找到了 2026 年和 2025 年在 GDWEB 上注册的三个航空类获奖作品，通过独立的 LLM 请求为每个作品创建了 DESIGN_INDEX，然后将 Korean Air 参考网站的结构应用于一个 Godot 航空项目网站。

完成的 AEROFLOW 网站并不是 Korean Air 网站的克隆。它使用了规格中的信息层级、导航、操作面板、区块排列和响应式原则，同时引入了新的品牌、文案、航空图像和内容。此示例证明，即使最终设计与参考网站不同，可测的结构性证据仍然可以生成一个具有独特身份标识的精良网站。

运行示例

# 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

启动进程后，打开以下页面。

• 按作品查看规格的 Web 查看器：http://127.0.0.1:4317/?run=2026-07-29T15-54-10-483Z-5c70317e

• AEROFLOW 结果网站：http://127.0.0.1:4320

1. 每个作品的规格结果

从左侧的运行列表中逐个选择作品。右侧仅显示所选作品的最终 DESIGN_INDEX，不会混入其他作品的内容。

2. 证据图像和测量结果

Evidence 选项卡显示发送给独立 LLM 请求的桌面端和移动端图像、图块坐标、缩小比例以及代表性颜色。

3. 独立 LLM 请求契约

Request Contract 记录页面划分、导航、区块边界、HEX/RGB/HSL 颜色、组件、响应式矩阵和验收标准。该契约避免结果沦为肤浅的氛围摘要，并使其成为另一个 LLM 可以使用的实现规格。

4. 生成过程

Generation Log 显示从搜索和证据准备，到每个作品独立的 LLM 请求、文档保存以及整个运行完成的顺序。此次运行使用三个独立的 includeContext: none 请求处理了全部三个作品。

5. 规格驱动的 AEROFLOW 首屏视图

Korean Air 参考网站中观察到的明亮航空门户和操作面板结构被改编到 Godot 项目中。品牌、飞机图像、文案和功能均为该结果专门创建。

6. 项目亮点

预订和促销卡片结构被重新用于核心项目内容：飞行区域、玻璃驾驶舱和实时天气。

7. 开发日志和快捷入口

源参考网站的通知和服务快捷入口被重构为构建历史、开发进度、飞行模型、航空电子、媒体、控制和路线图导航。

8. 媒体和页脚

最后区域包含项目媒体、开发、支持和许可链接，其后是独立项目页脚。

此结果证明了什么

• 新项目可以使用经过验证的信息层级和布局关系，而无需复制参考网站的徽标、商标、文案或图像。

• 将静态截图转换为导航、像素边界、颜色令牌、组件和响应式矩阵，可以为另一个 LLM 提供足够的细节来制定具体的实现计划。

• 即使使用相同的结构证据，新设计的内容、品牌和视觉资产也可以创造出与源网站不同的独特身份。

• Secret MCP 旨在从优秀设计中提取结构证据，并用它构建适合新项目的精良网站，而不是逐像素复现源网站。

规格和请求契约

• Korean Air DESIGN_INDEX 规格

• 独立 LLM 请求契约

• 运行清单

• 生成的网站源码

这些链接直接指向仓库中包含的实际文件。相同的产物也通过相对符号链接分组在 tmp/showcase/aviation-godot 下，便于本地执行和浏览。

核心执行架构

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

以下边界条件至关重要。

• 多个作品的图像或规格正文绝不会作为一个批次返回给外部宿主 LLM。

• 使用 limit: 3 时，服务器最多执行三个相互独立的 LLM 采样请求。

• 每个采样请求都使用 includeContext: none。

• 一个采样请求只包含一个作品的元数据和图像图块。

• 前一个作品的 ID、图像和分析文档绝不会传入下一个作品的请求。

• Web 查看器中排除的作品会在创建任何采样请求之前从搜索结果中移除。

• 服务器只有在将当前采样响应保存到文件后，才会开始下一个作品。

• 最后，只将生成的文件路径、所用模型以及成功或失败状态返回给宿主。

换句话说，这并不是早期那种宿主 LLM 一次性读取所有结果并生成综合摘要的架构。

Web 查看器

Web 查看器每 2.5 秒读取一次 DESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runs。MCP 生成进程与 Web 服务器之间没有单独的数据库或调试连接。

界面包含以下区域。

• 生成运行：查询、请求数量、允许的年份和整体状态

• 作品列表：每个 gdweb-<work-number> 的进度和证据图像数量

• 作品详情：所选作品的规格、证据图像和测量结果、请求契约以及生成日志

• 搜索排除：将所选作品从以后的搜索中排除、重新包含该作品，并管理完整排除列表

当一个运行包含三个作品时，它也会产生三个文档，如下所示。

.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 不是合并多个作品文档正文的文件。它是一个查看器清单，只包含每个作品的文件路径、状态、时间戳、模型和证据列表。

搜索排除列表

在 Web 查看器中选择 Exclude from search 会将作品编号保存到以下文件。

DESIGN_INDEX_OUTPUT_DIR/.secret-mcp/exclusions.json

• 历史运行和生成的文档绝不会被删除。

• 新的 generate-gdweb-design-indexes 和 search-gdweb-designs 运行会在选择前过滤作品编号。

• 为避免因排除而导致返回结果过少，搜索会读取额外的 GDWEB 候选作品，并从未排除的作品中选择所请求的 limit。

• 选择 Remove exclusion 会使该作品从下一次搜索开始重新符合条件。

• MCP 服务器和 Web 查看器必须使用相同的 DESIGN_INDEX_OUTPUT_DIR，才能共享相同的排除列表。

图像处理

GDWEB 的完整桌面端截图可能非常长，且大小达数 MB。直接将原始 base64 数据放入采样请求可能会超出 MCP 传输限制，或导致视觉模型遗漏细小的结构细节。

在为每个作品创建请求之前，gdweb-sampling-images.ts 会执行以下操作。

• 加载带 sgbn=1 的 GDWEB 桌面端注册图像

• 加载带 sgbn=3 的 GDWEB 移动端注册图像

• 将桌面端图像缩放到最大宽度 1200px

• 将长页面拆分为高度 1600px 的重叠垂直图块

• 将移动端图像作为独立证据保留

• 将证据压缩为 JPEG，以减小 MCP 采样请求的大小

• 为每个图块记录原始和准备好的画布尺寸、缩放比例、准备好的 x/y/width/height 坐标、源空间坐标和源 URL

• 从每个图块测量八种代表性颜色，并记录 HEX、RGB、HSL 和像素覆盖率

同一作品的多张图块包含在同一个作品专属采样请求中。不同作品的图块绝不会包含在同一个请求中。

代表性颜色是从归一化截图像素中采样得到的测量值。它们是比较视觉效果的精确证据，但绝不能作为源网站的 CSS 变量呈现，因为 JPEG 误差和图像内容会影响这些值。生成契约将 MEASURED 颜色与 INFERRED 实现令牌区分开来。

服务器不会打开作品的生产环境网站，也不会抓取其 DOM。视觉证据仅限于 GDWEB 上注册的图像和元数据。

GDWEB 搜索

设计搜索不使用浏览器自动化、Bing、Brave 或 DuckDuckGo。

Query
  -> POST https://www.gdweb.co.kr/sub/search.asp
  -> form field: Txt_word=<query>
  -> parse the GDWEB result HTML
  -> collect work number, category, and registration year
  -> retain only the current and previous year
  -> load GDWEB detail metadata and registered images

新鲜度策略

• 如果省略 year，则使用当前运行时年份。

• includePreviousYear 默认为 true。

• 在 2026 年运行时，默认只允许 2026 年和 2025 年注册的作品。

• 使用 includePreviousYear: false 时，只允许目标年份。

• awardOnly 默认为 true，因此没有奖项名称的作品会被排除。

• limit 可设置为 1 到 10。

作品元数据

DESIGN_INDEX 规范

每次独立的采样请求都包含 secret-mcp/design-index/v2 契约。生成的文件名为 DESIGN_INDEX_gdweb-<strNo>.md。

每个作品对应一个文件，但每个文件都以页面和路由清单开头，并为每个已验证页面重复完整的子章节。该契约不会将长滚动截图中的各个区块误认为独立页面；只有当证据拼贴中明显包含独立屏幕时，才会拆分页面。

每个文档必须包含以下全部 19 个编号章节。

每个重大判断都标记为以下证据级别之一。

• OBSERVED：在 GDWEB 图像或元数据中直接可见

• MEASURED：根据提供的像素坐标或测量调色板进行数值验证

• INFERRED：为复现相同结果而做出的合理推断

• UNKNOWN：无法根据静态证据验证，不得断言为事实

另一个 LLM 必须能够仅凭完成的文档推导出组件树、令牌、响应式规则、资源、实现顺序和验证项。

暴露的工具

服务器当前暴露五个 MCP 工具。

设计规划、布局分析、实现规范以及 DESIGN_INDEX 请求请使用 generate-gdweb-design-indexes。仅轻量级列表请求使用 search-gdweb-designs。

源码结构

secret_mcp/
├── src/
│   ├── index.ts                         MCP tool registration and sampling requests
│   ├── dashboard-server.ts              Local web server and document/exclusion APIs
│   ├── design-index-run-store.ts         Run manifest and per-work artifact records
│   ├── design-exclusion-store.ts         Add/remove persistent search exclusions
│   ├── design-index-paths.ts             Shared MCP/viewer output-path resolution
│   ├── gdweb-design-search.ts           GDWEB search, year filtering, and registered-image loading
│   ├── gdweb-design-index-generator.ts  Sequential per-work generation and Markdown saving
│   ├── gdweb-sampling-images.ts         Long-capture resizing, tiling, and compression
│   ├── design-spec-contract.ts          Required DESIGN_INDEX specification contract
│   ├── search-engine.ts                 General Bing, Brave, and DuckDuckGo search
│   ├── enhanced-content-extractor.ts    General webpage content extraction
│   ├── browser-pool.ts                  Browser pool for general content extraction
│   ├── rate-limiter.ts                  General-search request limits
│   ├── types.ts                         Search and tool types
│   └── utils.ts                         URL, text, and timestamp utilities
├── web/
│   ├── index.html                       Web viewer interface
│   ├── styles.css                       Desktop and mobile layout
│   └── app.js                           Run refresh and per-work document switching
├── .github/workflows/
│   ├── ci.yml                           Build, lint, and package validation
│   ├── gdweb-smoke.yml                  Live GDWEB search and image validation
│   └── release.yml                      Release-package generation
├── tmp/DESIGN_CONTEST_SITES.md          Design competition and award website list
├── tmp/reconstructions/
│   └── gdweb-27294-godot/               Specification-driven AEROFLOW static website
├── tmp/showcase/aviation-godot/
│   ├── DESIGN_INDEX.md                   Relative symbolic link to the per-work specification
│   ├── REQUEST_CONTRACT.md               Relative symbolic link to the independent request contract
│   ├── RUN_MANIFEST.json                 Relative symbolic link to the run manifest
│   ├── generated-site/                   Relative symbolic link to the result website
│   └── screenshots/                      Run and result screens used by this README
├── mcp.json                             MCP registration example
└── package.json

开发与验证

npm run build
npm run lint
npm run smoke:gdweb-isolation
npm run web

隔离冒烟测试连接一个支持采样的模拟 MCP 客户端，并验证以下行为。

• 搜索结果数量等于采样请求数量。

• 每个采样请求恰好包含一个参考 ID。

• 任何其他作品的 ID 都不会混入请求中。

• 每个请求都使用 includeContext: none。

• 每个请求都包含 GDWEB 图像。

• 每个结果都会创建独立的 Markdown 文件。

• 被排除的作品不会进入后续的搜索结果或采样请求。

• 规范契约包含逐页、导航、坐标和颜色要求。

• 运行清单证据记录瓦片坐标和测量调色板。

运行时环境变量

文档

• MCP API 文档

• 设计竞赛与获奖网站列表

• 全新克隆复核记录

• Yeong Coffee DESIGN_INDEX，韩文历史输出

• Yorien DESIGN_INDEX，韩文历史输出

• Ggublack Chicken DESIGN_INDEX，韩文历史输出

• Korean Air DESIGN_INDEX 规范，韩文历史输出

• Korean Air 独立请求契约

相关工作与参考

Secret MCP 被定位为多模态 UI 理解和截图转代码研究邻近的实现产物。它尚未在以下论文所使用的数据集或指标上进行评估，因此这些论文的结果不得被解读为 Secret MCP 的结果。

1. 司成磊、张彦哲、李瑞安、杨正元、刘瑞博和杨迪一。Design2Code：面向自动化前端工程的多模态代码生成基准测试。 NAACL 2025。提出了基于真实世界截图到代码的评估方法，包含视觉和元素级指标。论文

2. 布莱恩·王、李刚、周鑫、陈卓荣、托维·格罗斯曼和李洋。Screen2Words：基于多模态学习的移动界面自动摘要。 UIST 2021。研究了结合截图、文本、结构和界面语义的表示方法。论文

3. 许景宇、罗伯特·罗、劳伦斯·张、维克拉姆·杜弗、林明聪、黄柏瑜、格雷厄姆·纽比格、周淑妍、鲁斯兰·萨拉赫丁诺夫和丹尼尔·弗里德。VisualWebArena：在真实视觉化网页任务上评估多模态智能体。 ACL 2024。确立了视觉化网页智能体评估的重要性和难度。论文

4. Model Context Protocol。采样规范。 定义了客户端中介的 sampling/createMessage，包括请求消息、模型偏好、令牌预算和上下文控制。规范

引用

Secret MCP 目前是带有工作研究笔记的软件，而非经过同行评审的出版物。

@software{jo2026secretmcp,
  author  = {{조영진}},
  title   = {Secret MCP: Evidence-Isolated Multimodal Design Analysis through MCP Sampling},
  year    = {2026},
  version = {0.6.0},
  url     = {https://github.com/yyeongjin/secret_mcp},
  note    = {Software artifact and working implementation report}
}