英語 | 한국어

ターゲットアーキテクチャ

Secret MCP

Webデザイン分析、スクリーンショットから仕様書へのワークフロー、フロントエンド再構築計画のためのエビデンスに基づくMCPサーバー。

npx -y secret-design-mcp

Secret MCP は、GDWEB で最近のデザインリファレンスを検索し、検索結果ごとに個別の LLM リクエストと個別の DESIGN_INDEX ファイルを作成するローカル Model Context Protocol (MCP) サーバーです。各ファイルには、提供されたビジュアルエビデンスにトレース可能な、ページ・ルート固有のレイアウト、ナビゲーション、ピクセル座標、色、コンポーネント、レスポンシブ仕様が含まれます。

Secret MCP という名前は、このプロジェクトがシークレット機能やプライベートデータを提供することを意味するものではありません。これは、デザインウェブサイトを中心に MCP サーバーを構築するというアイデアで、プライベートリポジトリで実験していたときのプロジェクト名です。このプロジェクトの現在の目的は、公開デザインリファレンスから再現可能な構造的エビデンスを抽出し、LLM が新しいプロジェクトに適用できる仕様書を作品ごとに1つ作成することです。

複数の作品の画像や説明が単一の LLM コンテキストやドキュメントに結合されることはありません。サーバーは検索結果をサーバー内で順次処理し、各作品に対して独立した MCP sampling/createMessage リクエストを作成し、その作品のファイルを保存してから、次の作品に進みます。別のローカル Web アプリケーションでは、一度に1つの作品を選択し、そのソースエビデンス、測定された色と座標、LLM コントラクト、生成ログ、最終ドキュメントを検査し、その後の検索の除外リストを管理できます。

Related MCP server: Refero MCP

研究ノート

MCPサンプリングによるエビデンス分離型マルチモーダルデザイン分析

ワーキングペーパー兼実装レポート・Secret MCP v0.6.0・査読なし

概要

Secret MCP は、公開 Web ページのスクリーンショットを実装指向のデザイン仕様書に変換するための、監査可能なパイプラインを実装しています。このシステムは、デスクトップおよびモバイルのビジュアルエビデンスを準備し、クロップ座標と代表的なピクセルカラーを記録し、リファレンスごとにクライアントサイドの MCP サンプリングを1回呼び出します。複数のデザインリファレンスを1つのプロンプトに連結するワークフローとは異なり、Secret MCP はリファレンスの同一性をリクエスト境界とアーティファクト境界の両方として扱います。1つのリファレンスが、1つのサンプリングリクエスト、1つのリクエストコントラクト、1つの DESIGN_INDEX ドキュメントを生成します。各リクエストは includeContext: none を要求し、ルート、ジオメトリ、コンポーネント、デザイントークン、レスポンシブ動作、アクセシビリティ、実装タスク、受け入れ基準、不確実性をカバーする同じ19セクションの仕様コントラクトを適用します。このレポートは、プロトコルレベルの分離とアーティファクト生成を評価するものであり、ある言語モデル、プロンプト、または再構築方法が他より優れていると主張するものではありません。ライブスモークテストでリクエスト境界を検証し、保存された3リファレンスの実行が記述的な測定値と定性的な実装ケースを提供します。

研究課題

形式的システムモデル

リファレンス 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 でした。実行により、2つの異なる 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 リファレンス）からの記述的測定値。実行では、合計816.9 KB（10進数）の12個のエビデンス画像が準備され、96個の代表色の測定値が記録されました。合計27,391トークン（空白区切り）と187.0 KB（10進数）の3つの DESIGN_INDEX ドキュメントが生成されました。3つすべてに見出し1〜19が含まれています。見出しの存在は意味的正しさを保証するものではありません。

定性的ケーススタディ

図3. GDWEB エビデンスビューアから生成された Korean Air の DESIGN_INDEX、そして AEROFLOW までの保存された定性的トレース。AEROFLOW は、新しいブランディング、コンテンツ、画像、機能を意図的に導入しています。この例は、仕様の使用法を示すものであり、管理された視覚的忠実度の比較ではありません。

解釈と制限

• ライブ分離結果は n = 2 であり、記録されたアーティファクト分析は n = 3 です。どちらも、デザインの品質やモデルのパフォーマンスに関する広範な主張をサポートするものではありません。

• 現在の評価には、対照群、人間による評価、反復試行、信頼区間、スクリーンショットからコードへのベースラインとの比較はありません。

• 代表色は、リサイズ、JPEG 正規化、チャネル量子化の後に測定されます。これらはスクリーンショットのエビデンスであり、ソース Web サイトの 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 会話、プロセス、作業ディレクトリ、応答ファイル、メッセージ履歴を再利用してはなりません。ワークスペースは1つの新しい Codex プロセスを起動し、完全な Markdown 応答を待って、その応答を保留中の MCP サンプリング呼び出しに返し、サーバーが作品のコントラクト、エビデンス、ドキュメントを保存した後で削除できます。

サーバーは引き続きシーケンシャルキューを制御します。作品1が戻って保存されるまで、作品2は準備されません。これにより、新しいプロセスとワークスペースは、サーバーに結合フォールバックを追加することなく、プロトコルレベルの includeContext: none 境界と同等の実行レベルのものになります。ダイレクトクライアントは、サンプリング対応の MCP ホストになります。作品ごとの出力予算に対して十分に長いツール呼び出しタイムアウトを使用し、1つの永続的な 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は作品ごとの出力予算であり、実行全体で共有される予算でも、ページ間で均等に分割される予算でもありません。1つの作品に複数の表示ページやルートが含まれる場合があり、各ページで19セクション構成のコントラクトのページ固有部分をすべて繰り返す必要があります。そのため、デフォルト値と最小値は131072トークンです。クライアントは、非常に大きなマルチページのエビデンスセットに対して、最大262144トークンをリクエストできます。

limit: 3の場合、デフォルトの実行では最大3つの独立した131072トークン出力をリクエストできます。作品間で1つの131072トークンプールを共有するわけではありません。接続されたサンプリングクライアントと選択したモデルが、リクエストされた出力サイズをサポートしている必要があります。モデルがstopReason: maxTokensを返した場合、サーバーはその作品を、切り詰められたDESIGN_INDEXを完全なものとして保存する代わりに、失敗として扱います。

ツールが完了すると、実行ID、実行マニフェストのパス、作品ごとのドキュメントパス、WebビューアのURLが返されます。

エンドツーエンドの例：GDWEB仕様からGodot航空ウェブサイトへ

実際の例では、Secret MCPが2026年と2025年にGDWEBに登録された3件の航空賞受賞作品を発見し、独立したLLMリクエストを通じて各作品のDESIGN_INDEXを作成し、その後、大韓航空のリファレンスの構造をGodot航空プロジェクトのウェブサイトに適用しました。

完成したAEROFLOWウェブサイトは、大韓航空のウェブサイトのクローンではありません。リファレンスの情報階層、ナビゲーション、アクションパネル、セクション構成、レスポンシブの原則を使用しながら、新しいブランド、コピー、航空画像、コンテンツを導入しています。この例は、結果として得られるデザインがリファレンスと異なる場合でも、測定可能な構造的エビデンスがあれば、独自のアイデンティティを持つ洗練されたウェブサイトを制作できることを示しています。

例を実行する

# 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. 作品ごとの仕様結果

左側の実行リストから作品を1つずつ選択します。右側には、選択した作品の最終的なDESIGN_INDEXのみが、他の作品のコンテンツを混在させることなく表示されます。

2. エビデンス画像と測定値

Evidenceタブには、独立したLLMリクエストに送信されたデスクトップ画像とモバイル画像、タイル座標、縮小率、代表色が表示されます。

3. 独立したLLMリクエストコントラクト

Request Contractには、ページ区切り、ナビゲーション、セクション境界、HEX/RGB/HSLカラー、コンポーネント、レスポンシブマトリクス、受け入れ条件が記録されます。このコントラクトにより、結果が表面的なムードの要約で終わるのを防ぎ、別のLLMが実装仕様として利用できるようにします。

4. 生成プロセス

Generation Logには、検索とエビデンス準備から、独立した作品ごとのLLMリクエスト、ドキュメントの保存、実行全体の完了までの一連の流れが表示されます。この実行では、3つの作品すべてが個別のincludeContext: noneリクエストで処理されました。

5. 仕様駆動型AEROFLOWのファーストビュー

大韓航空のリファレンスで確認された明るい航空ポータルとアクションパネル構造は、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"]

以下の境界が重要です。

• 複数の作品からの画像や仕様本文が、1つのバッチとして外部のホストLLMに返されることはありません。

• limit: 3の場合、サーバーは最大3つの相互に独立したLLMサンプリングリクエストを実行します。

• すべてのサンプリングリクエストはincludeContext: noneを使用します。

• サンプリングリクエストに含まれるのは、1つの作品のメタデータと画像タイルのみです。

• 前の作品のID、画像、分析ドキュメントが次の作品のリクエストに渡されることはありません。

• Webビューアで除外された作品は、サンプリングリクエストが作成される前に検索結果から削除されます。

• サーバーは、現在のサンプリングレスポンスをファイルに保存した後にのみ、次の作品の処理を開始します。

• 最後に、生成されたファイルパス、使用されたモデル、成功または失敗のステータスのみがホストに返されます。

つまり、これはホストLLMがすべての結果を一度に読み取って結合サマリーを生成する以前のアーキテクチャではありません。

Webビューア

Webビューアは、DESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runsを2.5秒ごとに読み取ります。MCP生成プロセスとWebサーバーの間に、個別のデータベースやデバッグ接続はありません。

インターフェースには、次の領域が含まれます。

• 生成実行：クエリ、リクエスト数、許可された年、全体的なステータス

• 作品リスト：各gdweb-<作品番号>の進捗状況とエビデンス画像数

• 作品の詳細：選択した1つの作品の仕様、エビデンス画像と測定値、リクエストコントラクト、生成ログ

• 検索除外：選択した作品を将来の検索から除外する、再度含める、除外リスト全体を管理する

実行に3つの作品が含まれる場合、以下のように3つのドキュメントも生成されます。

.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のフルデスクトップキャプチャは非常に縦長で、サイズが数メガバイトになる場合があります。元のbase64データをサンプリングリクエストで直接送信すると、MCPトランスポートの制限を超えたり、ビジョンモデルが細かい構造の詳細を見逃したりする可能性があります。

各作品のリクエストを作成する前に、gdweb-sampling-images.tsは次の操作を実行します。

• sgbn=1を指定してGDWEBデスクトップ登録画像を読み込む

• sgbn=3を指定してGDWEBモバイル登録画像を読み込む

• デスクトップ画像の最大幅を1200pxにリサイズする

• 長いページを1600pxの高さで重複する垂直タイルに分割する

• モバイル画像を別のエビデンスとして保持する

• MCPサンプリングリクエストのサイズを小さくするために、エビデンスをJPEGとして圧縮する

• すべてのタイルについて、元のキャンバスサイズと準備済みキャンバスサイズ、スケール係数、準備済みのx/y/width/height座標、ソーススペース座標、ソースURLを記録する

• すべてのタイルから8つの代表色を測定し、HEX、RGB、HSL、ピクセルカバレッジを記録する

1つの作品からの複数のタイルは、同じ作品固有のサンプリングリクエストに含まれます。異なる作品のタイルが同じリクエストに含まれることはありません。

代表色は、正規化されたスクリーンショットのピクセルからサンプリングされた測定値です。これらは視覚的な比較のための正確なエビデンスですが、JPEGエラーや画像コンテンツが値に影響するため、ソースサイトのCSS変数として提示してはなりません。生成コントラクトは、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-hook/design-index/v2 コントラクトが含まれます。 生成されるファイル名は DESIGN_INDEX_gdweb-<strNo>.md です。

作品ごとに1つのファイルがありますが、各ファイルはまずページとルートの一覧で始まり、検証されたすべてのページの完全なサブセクションを繰り返します。コントラクトは、長いスクロールキャプチャ内のセクションを独立したページとして誤認しません。エビデンスコラージュの中に視覚的に別々の画面が含まれる場合にのみ、ページを分割します。

すべてのドキュメントには、以下の19の番号付きセクションがすべて含まれていなければなりません。

すべての主要な判断は、以下のいずれかのエビデンスレベルでマークされます。

• OBSERVED: GDWEB の画像またはメタデータに直接見えているもの

• MEASURED: 提供されたピクセル座標または計測済みパレットから数値的に検証されるもの

• INFERRED: 同じ結果を再現するために合理的に推論されたもの

• UNKNOWN: 静的証拠から検証できず、事実として断言してはならないもの

別の LLM が完成したドキュメント単体から、コンポーネントツリー、トークン、レスポンシブルール、アセット、実装順序、検証項目を導出できなければなりません。

公開されたツー・サービス

サーバーは現在、5 種類の 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が1つだけ含まれること

• 他作品のIDがリクエストに混入しないこと

• すべてのリクエストが includeContext: none であること

• すべてのリクエストが GDWEB 画像を含んでいること

• 各実行で複数の Markdown ファイルが作成されること

• 除外した作品がその後の検索結果やサンプリングリクエストに現れないこと

• 仕様書にページ、ナビゲーション、座標、色の要件があること

• 実行マニフェストの証拠にタイル座標と計測したパレットが記録されること

実行時間変数

学習教材のドキュメント

• MCP API ドキュメント

• デザインコンペや受賞サイトの一覧

• 新規クローンの再検証記録

• Yeong Coffee DESIGN_INDEX、韓国語の過去の出力

• Yorien DESIGN_INDEX、韓国語の過去の出力

• 그블랙チキン DESIGN_INDEX、韓国語の過去の出力

• Korean Air DESIGN_INDEX 仕様、韓国語の過去の出力

• Korean Air 独立リクエスト契約

関連作品と変更履歴に関連する言及

Secret MCP は、多様な表示形式の画面理解やスクリーンショットからコード化までの研究に隣接した実装 artifact として位置付けられています。下記の論文で使われているデータセットや指標では正式に評価されていないため、それらの数を Secret MCP の結果として解釈してはなりません。

1. Chenglei Si, Yanzhe Zhang, Ryan Li, Zhengyuan Yang, Ruibo Liu, and Diyi Yang. Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering. NAACL 2025. 実世界のスクリーンショットからコードへの評価を、ビジュアルおよび要素レベルの指標で紹介しています。Paper

2. Bryan Wang, Gang Li, Xin Zhou, Zhourong Chen, Tovi Grossman, and Yang Li. Screen2Words: Automatic Mobile UI Summarization with Multimodal Learning. UIST 2021. スクリーンショット、テキスト、構造、UIセマンティクスを組み合わせた表現を研究しています。Paper

3. Jing Yu Koh, Robert Lo, Lawrence Jang, Vikram Duvvur, Ming Chong Lim, Po-Yu Huang, Graham Neubig, Shuyan Zhou, Ruslan Salakhutdinov, and Daniel Fried. VisualWebArena: Evaluating Multimodal Agents on Realistic Visually Grounded Web Tasks. ACL 2024. 視覚に基づくWebエージェント評価の重要性と難しさを確立しています。Paper

4. Model Context Protocol. Sampling specification. リクエストメッセージ、モデル設定、トークン予算、コンテキスト制御を含む、クライアント仲介のsampling/createMessageを定義しています。Specification

Citation

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