Englisch | 한국어

Zielarchitektur

Secret MCP

Ein evidenzbasierter MCP-Server für Webdesign-Analysen, Screenshot-zu-Spezifikations-Workflows und die Planung von Frontend-Rekonstruktionen.

npx -y secret-design-mcp

Secret MCP ist ein lokaler Model-Context-Protocol- (MCP-)Server, der GDWEB nach aktuellen Design-Referenzen durchsucht und für jedes Suchergebnis eine separate LLM-Anfrage und eine separate DESIGN_INDEX-Datei erstellt. Jede Datei enthält seiten- und routespezifische Layouts, Navigation, Pixelkoordinaten, Farben, Komponenten und responsive Spezifikationen, die auf die bereitgestellten visuellen Belege zurückführbar sind.

Der Name Secret MCP bedeutet nicht, dass das Projekt geheime Funktionen oder private Daten bereitstellt. Es war der Projektname, der beim Experimentieren in einem privaten Repository mit der Idee verwendet wurde, einen MCP-Server rund um Design-Websites zu entwickeln. Der aktuelle Zweck des Projekts besteht darin, reproduzierbare strukturelle Belege aus öffentlichen Design-Referenzen zu extrahieren und sie in eine Spezifikation pro Werk umzuwandeln, die ein LLM auf ein neues Projekt anwenden kann.

Bilder und Beschreibungen mehrerer Werke werden niemals in einem einzigen LLM-Kontext oder -Dokument kombiniert. Der Server verarbeitet Suchergebnisse sequenziell innerhalb des Servers, erstellt für jedes Werk eine unabhängige MCP-sampling/createMessage-Anfrage, speichert die Datei dieses Werks und fährt erst dann mit dem nächsten Werk fort. Eine separate lokale Webanwendung ermöglicht es Ihnen, jeweils ein Werk auszuwählen, dessen Quellnachweise, gemessene Farben und Koordinaten, LLM-Vertrag, Generierungsprotokoll und endgültiges Dokument einzusehen sowie die Ausschlussliste für spätere Suchläufe zu verwalten.

Related MCP server: Refero MCP

Forschungshinweis

Evidenzisolierte multimodale Designanalyse durch MCP-Sampling

Arbeitspapier und Implementierungsbericht · Secret MCP v0.6.0 · nicht peer-reviewt

Zusammenfassung

Secret MCP implementiert eine prüfbare Pipeline zur Umwandlung öffentlicher Webseiten-Screenshots in implementierungsorientierte Designspezifikationen. Das System bereitet visuelle Belege für Desktop und Mobilgeräte auf, zeichnet Beschnittkoordinaten und repräsentative Pixelfarben auf und ruft clientseitiges MCP-Sampling einmal pro Referenz auf. Im Gegensatz zu Workflows, die mehrere Design-Referenzen in einem einzigen Prompt verketten, behandelt Secret MCP die Referenzidentität sowohl als Anfragegrenze als auch als Artefaktgrenze: Eine Referenz erzeugt eine Sampling-Anfrage, einen Anfragevertrag und ein DESIGN_INDEX-Dokument. Jede Anfrage fordert includeContext: none an und wendet denselben 19 Abschnitte umfassenden Spezifikationsvertrag an, der Routen, Geometrie, Komponenten, Design-Tokens, responsives Verhalten, Barrierefreiheit, Implementierungsaufgaben, Abnahmekriterien und Unsicherheit abdeckt. Dieser Bericht bewertet die Isolierung auf Protokollebene und die Artefakterstellung; er behauptet nicht, dass ein Sprachmodell, Prompt oder eine Rekonstruktionsmethode einer anderen überlegen ist. Ein Live-Smoke-Test verifiziert die Anfragegrenze, während ein konservierter Drei-Referenzen-Lauf deskriptive Messungen und einen qualitativen Implementierungsfall liefert.

Forschungsfragen

Formales Systemmodell

Für Referenz r_i enthält der vorbereitete Evidenzsatz Bildkacheln I, Beschnittgrenzen B, repräsentative Farbmessungen P und Quellmetadaten M. Der feste Spezifikationsvertrag ist C; die unabhängige Anfrage und das resultierende Dokument sind q_i und 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

Innerhalb einer vorbereiteten Kachel gemessene Koordinaten werden wie folgt auf den ursprünglichen Screenshot zurückgeführt.

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

Dies ist eine operative Isolationsinvariante, kein Anspruch auf statistische Unabhängigkeit. Der Server und der Smoke-Test können den Inhalt von Anfragen und Artefakten einsehen; sie können nicht beweisen, was ein beliebiger externer Modellanbieter außerhalb der MCP-Nachricht speichern könnte.

Empirische Ergebnisse

Protokollisolation

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

Abbildung 1. Live-Smoke-Test, aufgezeichnet am 22.08.2026 mit der Abfrage 금융 (n = 2 gesampelte Referenzen nach Ausschluss von gdweb-26905). Jede Anfrage enthielt ihre eigene Referenz-ID und visuelle Belege, keine andere gesampelte Referenz-ID und includeContext: none; der Lauf erzeugte zwei getrennte Markdown-Dateien. Der Test verifiziert die beobachtbare Anfragekomposition und Dateitrennung, nicht das Modellgedächtnis außerhalb des Protokolls.

Messungen des aufgezeichneten Laufs

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]

| Referenz | Desktop-Quellhöhe | Vorbereitete Bilder | Bildnutzlast | Farbmessungen | Dokument-Token | Dokumentgröße | Erforderliche Überschriften | | -------------- ----------------: | ------------------: | ----------------: | -------------: | --------------: | --------------: | --------------------------: | | gdweb-27294 | 2.675 px | 3 | 126,6 KB | 24 | 7.921 | 54,0 KB | 19/19 | | gdweb-25378 | 7.043 px | 4 | 302,5 KB | 32 | 9.953 | 69,8 KB | 19/19 | | gdweb-24234 | 7.832 px | 5 | 387,8 KB | 40 | 9.517 | 63,2 KB | 19/19 |

Abbildung 2. Deskriptive Messungen aus dem konservierten Lauf 2026-07-29T15-54-10-483Z-5c70317e (n = 3 Referenzen). Der Lauf bereitete 12 Evidenzbilder mit insgesamt 816,9 Dezimal-KB vor und zeichnete 96 repräsentative Farbmessungen auf. Er erzeugte drei DESIGN_INDEX-Dokumente mit insgesamt 27.391 durch Leerzeichen getrennten Token und 187,0 Dezimal-KB. Alle drei enthalten die Überschriften 1–19; das Vorhandensein der Überschriften begründet keine semantische Korrektheit.

Qualitative Fallstudie

Abbildung 3. Eine konservierte qualitative Spur vom GDWEB-Evidenzbetrachter zum generierten Korean-Air-DESIGN_INDEX und dann zu AEROFLOW. AEROFLOW führt bewusst neues Branding, neue Inhalte, Bilder und Funktionen ein; dieses Beispiel veranschaulicht die Spezifikationsnutzung und ist kein kontrollierter Vergleich der visuellen Wiedergabetreue.

Interpretation und Einschränkungen

• Das Live-Isolationsergebnis hat n = 2; die Analyse der aufgezeichneten Artefakte hat n = 3. Keines von beiden stützt weitreichende Behauptungen über Designqualität oder Modellleistung.

• Die aktuelle Evaluierung hat keine Kontrollgruppe, keine menschliche Bewertung, keine Wiederholungsversuche, keine Konfidenzintervalle und keinen Vergleich mit Screenshot-zu-Code-Basislinien.

• Repräsentative Farben werden nach der Größenänderung, JPEG-Normalisierung und Kanalquantisierung gemessen. Sie sind Screenshot-Belege, kein Beweis für die CSS-Tokens der Quellwebsite.

• Das 19/19-Ergebnis misst das Vorhandensein der erforderlichen Überschriften. Eine zukünftige Benchmark muss separat die faktische Fundierung, den Koordinatenfehler, die Farbdifferenz, das responsive Verhalten und die Implementierungstreue bewerten.

• Die qualitative Implementierung ist ein Existenzbeispiel, kein Beleg dafür, dass Secret MCP die Rekonstruktionsqualität verbessert.

Verwendung

1. Installation und Build

Node.js 20.19 oder höher ist erforderlich.

Der veröffentlichte MCP-Server kann wie folgt gestartet werden:

npx -y secret-design-mcp

Klonen Sie das Repository, wenn Sie auch den lokalen Betrachter benötigen oder am Quellcode arbeiten möchten:

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

2. Webanwendung starten

Setzen Sie DESIGN_INDEX_OUTPUT_DIR für den MCP-Server und die Webanwendung auf denselben Wert, damit beide Prozesse dasselbe Ausgabeverzeichnis lesen.

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

Öffnen Sie die folgende Adresse in einem Browser.

http://127.0.0.1:4317

Die Webanwendung zeigt die Liste der Generierungsläufe, den Fortschritt pro Werk, GDWEB-Evidenzbilder, gemessene Koordinaten und Paletten, den an das LLM gesendeten Spezifikationsvertrag, das endgültige Markdown und die Generierungszeitstempel an. Dokumente und Belege sind schreibgeschützt; nur Aus Suche ausschließen und Ausschluss aufheben ändern den Filter, der für spätere Suchläufe verwendet wird.

3. MCP-Server registrieren

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

Ersetzen Sie bei einem Quellcode-Checkout command und args durch "command": "node" und "args": ["/absoluter/pfad/zu/secret_mcp/dist/index.js"].

Der MCP-Client muss sampling/createMessage unterstützen. Wenn ein Client kein Sampling unterstützt, gibt der Server einen expliziten Fehler zurück, anstatt einen Fallback auszuführen, der mehrere Werke in denselben Kontext legt.

Der MCP- Stdio-Server selbst öffnet keinen HTTP-Port. Der Client startet node dist/index.js als untergeordneten Prozess und tauscht JSON-RPC-Nachrichten über stdio aus. Nur der separate Webbenutzerprozess verwendet standardmäßig Port 4317.

Direkter Sampling-Client für Hosts ohne Sampling

Der Server muss nicht geändert werden, wenn der äußere MCP-Host nicht auf sampling/createMessage antworten kann. Ein separater MCP-Protokollclient kann sich direkt mit dist/index.js verbinden, sampling: {} ankündigen und jede Sampling-Anfrage bearbeiten, indem er einen frischen Codex-LLM-Prozess in einem neuen temporären Arbeitsbereich startet.

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

Der Sampling-Handler muss nur die Textblöcke und Evidenzbilder der aktuellen Anfrage in diesen Arbeitsbereich kopieren. Er darf keine Codex-Unterhaltung, keinen Prozess, kein Arbeitsverzeichnis, keine Antwortdatei und keinen Nachrichtenverlauf eines anderen Werks wiederverwenden. Der Arbeitsbereich startet einen neuen Codex-Prozess, wartet auf dessen vollständige Markdown-Antwort, gibt diese Antwort an den ausstehenden MCP-Sampling-Aufruf zurück und kann danach entfernt werden, sobald der Server den Vertrag, die Belege und das Dokument des Werks gespeichert hat.

Der Server steuert weiterhin die sequenzielle Warteschlange: Werk 2 wird erst vorbereitet, nachdem Werk 1 zurückgekehrt und gespeichert wurde. Dies macht den frischen Prozess und Arbeitsbereich zu einem ausführungsäquivalenten Gegenstück der includeContext: none-Grenze auf Protokollebene, ohne dem Server einen kombinierten Fallback hinzuzufügen. Der direkte Client wird zum samplingfähigen MCP-Host; er sollte ein Tool-Timeout verwenden, das lang genug für das Ausgabebudget pro Werk ist, und darf niemals mehrere Sampling-Anfragen über eine einzige persistente LLM-Unterhaltung beantworten.

4. Das LLM auffordern

Ein separater /web-design-Slash-Befehl ist nicht erforderlich.

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.

Das Host-LLM ruft das Tool generate-gdweb-design-indexes genau einmal auf. Der MCP-Server führt die Suche aus und trennt die LLM-Anfragen pro Werk intern voneinander.

Das manuelle Format für den Tool-Aufruf ist unten dargestellt.

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

Wenn outputDirectory weggelassen wird, verwendet das Tool die Umgebungsvariable DESIGN_INDEX_OUTPUT_DIR. Ist auch diese Variable nicht gesetzt, wird das Verzeichnis design-index im Arbeitsverzeichnis des Servers verwendet.

maxTokens ist ein Ausgabebudget pro Werk – kein Budget, das sich ein gesamter Lauf teilt, und auch kein Budget, das gleichmäßig auf Seiten aufgeteilt wird. Ein einzelnes Werk kann mehrere sichtbare Seiten oder Routen enthalten, und jede Seite muss die vollständigen seitenbezogenen Teile des 19-Abschnitte-Vertrags wiederholen. Standardwert und Mindestwert sind daher 131072 Tokens. Für außergewöhnlich umfangreiche mehrseitige Evidence-Sets können Clients bis zu 262144 Tokens anfordern.

Mit limit: 3 kann der Standardlauf bis zu drei unabhängige Ausgaben mit je 131072 Tokens anfordern; die Werke teilen sich keinen gemeinsamen Pool von 131072 Tokens. Der verbundene Sampling-Client und das ausgewählte Modell müssen die angeforderte Ausgabegröße unterstützen. Liefert das Modell stopReason: maxTokens zurück, behandelt der Server dieses Werk als fehlgeschlagen, anstatt ein abgeschnittenes DESIGN_INDEX als vollständig zu speichern.

Wenn das Tool abgeschlossen ist, gibt es die Lauf-ID, den Pfad zum Lauf-Manifest, die Dokumentpfade pro Werk und die URL des Web-Viewers zurück.

End-to-End-Beispiel: Von GGDWEB-Spezifikationen zu einer Godot-Luftfahrtwebsite

Für das konkrete Beispiel hat Secret MCP drei Luftfahrt-Preisträger gefunden, die 2026 und 2025 bei GDWEB registriert wurden, für jedes Werk über eine unabhängige LLM-Anfrage einen DESIGN_INDEX erstellt und dann die Struktur der Korean-Air-Referenz auf eine Godot-Luftfahrtprojektwebsite übertragen.

Die fertige AEROFLOW-Website ist kein Klon der Korean-Air-Website. Sie übernimmt die Informationshierarchie, die Navigation, das Aktionspanel, die Abschnittsanordnung und die responsiven Prinzipien aus der Spezifikation und führt zugleich eine neue Marke, Texte, Luftfahrtbilder und Inhalte ein. Dieses Beispiel zeigt, dass selbst wenn das resultierende Design von der Referenz abweicht, messbare strukturelle Belege dennoch eine hochwertige Website mit unverwechselbarer Identität erzeugen können.

Das Beispiel ausführen

# 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

Nach dem Start der Prozesse öffnen Sie die folgenden Screens.

• Web-Viewer für die Spezifikation pro Werk: http://127.0.0.1:4317/?run=2026-07-29T15-54-10-483Z-5c70317e

• AEROFLOW-Ergebniswebsite: http://127.0.0.1:4320

1. Spezifikationsergebnisse pro Werk

Wählen Sie die Werke nacheinander aus der Laufleiste links aus. Die rechte Seite zeigt ausschließlich den endgültigen DESIGN_INDEX des ausgewählten Werks, ohne Inhalte aus anderen Werken einzumischen.

2. Belegbilder und Messungen

Der Tab Evidence zeigt die Desktop- und Mobilbilder, die an die unabhängige LLM-Anfrage gesendet wurden sowie Kachelkoordinaten, Skalierungsfaktoren und repräsentative Farben.

3. Request Contract für die unabhängige LLM-Anfrage

Der Request Contract hält Seitentrennung, Navigation, Abschnittsgrenzen, HEX-/RGB-/HSL-Farben, Komponenten, die Responsive-Matrix und die Abnahmekriterien fest. Dieser Vertrag verhindert, dass das Ergebnis zu einer oberflächliche moodartigen Zusammenfassung wird, und macht es zu einer Implementierungsspezifikation, die ein weiteres LLM verwenden kann.

4. Generierungsprozess

Das Generation Log zeigt die Sequenz von der Suche und Evidenzaufbereitung über die unabhängige LLM-Anfrage pro Werk bis zum Speichern des (Dokuments) und zum Abschluss des gesamten Laufs. Dieser Lauf verarbeitete alle drei Werke mit getrennten includeContext: none-Anfragen.

5. Specification-driven: AEROFLOW erste Ansicht

Die helle Luftfahrtportal- und Aktionspanel-Struktur der Korean-Air-Referenz wurde in ein Godot-Projekt übertragen. Marke, Flugzeugbilder, Texte und Funktionalität wurden speziell für dieses Ergebnis entwickelt.

6. Projekt-Highlights

Die Reservierungs- und Aktionskartenstruktur wurde in die zentrale Projektstruktur umgewandelt: Flugregionen, Glascockpit und Echtzeit-Wetter.

7. Entwicklungslog und Schnellzugriffe

Die Hinweise und Service-Verknüpfungen der Referenz wurden in Build-Verlaufs, Entwicklungsfortschritt, Flugmodelle, Avionik, Medien, Steuerung und Roadmap-Navigation umstrukturiert.

8. Medien und Asset-Seiten

Der letzte Bereich enthält Projektmedien, Entwicklungs-, Support- und Lizenz-Links sowie der endgültigen Fußzeile des unabhängigen Projekts.

Was dieses Ergebnis zeigt

• Ein neues Projekt kann eine validierte Informationshierarchie und Layoutbeziehungen nützen, ohne die Logos, Marken, Texte oder Bilder der Referenz zu kopieren.

• Die Umwandlung statischer Screenshots in Navigation, Pixel-Grenzen, Farb-Token, Komponenten und eine Responsive Matrix liefert einem anderen LLM genügend Details, um einen konkret umsetzbaren Implementierungsplan zu erstellen.

• Selbst mit denselben strukturellen Belegen können neu gestaltete Inhalte, Branding und visuelle Assets eine eigenständige Identität erzeugen, die sich vom Quellwerk unterscheidet.

• Secret MCP ist dazu gedacht, strukturelle Belege aus guten Designs zu extrahieren und daraus eine hochwertige Website für ein neues Projekt zu bauen – nicht, die Quelle Pixel für Pixel zu reproduzieren.

Spezifikation und Request-Vertrag

• Korean-Air-DESIGN_INDEX-Spezifikation

• Unabhängiger LLM-Request-Vertrag

• Lauf-Manifest

• Quellcode der generierten Website

Diese Links verweisen direkt auf die tatsächlichen Dateien im Repository. Dieselben Artefakte sind zusätzlich unter tmp/showcase/aviation-godot über relative symbolische Links für die lokale Ausführung und Browser zusammengefasst.

Kernarchitektur der Ausführung

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

Die folgenden Grenzen sind wesentlich.

• Bilder oder Spezifikationstexte mehrerer Werke werden niemals als ein Bündel an das äußere Host-LLM zurückgegeben.

• Mit limit: 3 führt der Server genau bzw. höchstens drei völlig unabhängige LLM-Sampling-Anfragen aus.

• Jede Sampling-Anfrage verwendet includeContext: none.

• Eine Sampling-Anfrage enthält nur die Metadaten und Bildkacheln genau eines Werks.

• Die ID, die Bilder und das Analysedokument des vorherigen Werks werden nie in die Anfrage des nächsten Werks übergeben.

• Im Web-Viewer ausgeschlossene Werke (Search ausgeschlossene) werden vor der Erstellung der Sampling-Anfrage aus den Suchergebnissen entfernt.

• Der Server startet das nächste Werk erst, nachdem die aktuelle Sampling-Antwort in eine Datei gespeichert wurde.

• Am Ende werden nur die erzeugten Dateipfade, das verwendete Modell und Erfolg/Misserfolg zurückgegeben.

Mit anderen Worten handelt es sich nicht um die frühere Architektur, bei der das Host-LLM alle Ergebnisse gleichzeitig liest und eine gemeinsame Zusammenfassung erzeugt.

Web-Viewer

Der Web-Viewer liest alle 2,5 Sekunden DESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runs. Es gibt keine separate Datenbank- oder Debug-Verbindung zwischen MCP-Generierung und Webserver.

Die Oberfläche umfasst die folgenden Bereiche.

• Generierungsläufe: Abfrage, angeforderte Anzahl, erlaubte Jahre und Gesamtstatus

• Werkliste: Fortschritt und Anzahl / Belegbilder für jedes gdweb-<work-number>

• Werkdetails: Spezifikation, Belegbilder und Maße, Request//Request-Vertrag und Generierungsprotokoll eines ausgewählten Werks

• Such-Ausschlüsse: werk aus zukünftigen Suchen auszuschließen, erneute Einbindung und die Verwaltung der vollständigen Ausschlussliste

Wenn ein Lauf drei Werke enthält, erzeugt er auch drei Dokumente, wie unten dargestellt.

.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 ist keine Datei, die die Dokumentinhalte mehrerer Werke kombiniert. Es ist ein Viewer-Manifest mit ausschließlich werkbezogenen Dateipfaden, Statusinformation, Zeitstempel, Modellnamen und Evidenz-Listen.

Such-Ausschlussliste

Wenn Sie im Web-Viewer Exclude from search auswählen, wird die Werknummer in der folgenden Datei gespeichert.

DESIGN_INDEX_OUTPUT_DIR/.secret-mcp/exclusions.json

• Historische Läufe und generierte Dokumente werden nie gelöscht.

• Neuen Suchen generate-gdweb-design-indexes und search-gdweb-designs filtern die Werknummern vor der Auswahl.

• Um zu wenige Treffer zu erhalten – aufgrund Ausschlüssen – liest die Suche zusätzliche GDWEB-Kandidaten und wählt das gewünschte limit aus nicht ausgeschlossenen Werken.

• Mit Remove exclusion wird das Werk ab der nächsten Suche wieder berücksichtigt.

• MCP-Server und Web-Viewer müssen dasselbe DESIGN_INDEX_OUTPUT_DIR verwenden, um dieselbe Exclude-Liste zu teilen.

Bildverarbeitung

Die vollständigen Desktop-Captures von GDWEB können extrem hoch und mehrere Megabyte groß sein. Das direkte Senden der Original-Base64-Daten in eine Sampling-Antwort kann die MCP-Transportlimits überschreiten oder dazu führen, dass ein Vision-Modell feine Strukturdetails übersieht.

Vor dem Erstellen der Anfrage für jedes Werk führt gdweb-sampling-images.ts zweimal die folgenden Schritte aus.

• Lädt das GDWEB-Desktop-Registrierungsbild mit sgbn=1

• Lädt das GDWEB-Mobil-Registrierungsbild mit sgbn=3

• Skaliert das Desktopbild auf eine maximale Breite von 1200 px

• Splitter eine lange Seite in überlappende, vertikale Kacheln (Höhe 1600 px)

• Behält das Mobilébild e als separate Evidenz bei

• Komprimiert die Evidenz als JPEG, um die Größe der MCP-Sampling-Request zu reduzieren

• Speichert die ursprünglichen/aufbereiteten Canvasmaße, den Skalierfaktor, die aufbereiteten x/y/width/height-Koordinaten, die Quellbereichskoordinaten und die Quell-URL für jede Kachel

• Misst acht representative colors aus jedem Kachel und erfasst HEX,RGb, HLS und Farbdeckung

Mehrere Kacheln eines Werks werden in die arbeitswerkspezifik in dieselbe Sample-Anfrage aufgenommen. Kacheln von verschiedenen Werken werden niemals in dersoze angegeben.

Repräsentative Farben sind Messungen, die aus pixelgenauen pixelabtastten normalisierten Screenshots gewonnen wurden. Sie sind präzise Evidenz für die visuelle Comparable, sollten aber nicht als CSS-Variablen der Projektquelle präsentiert werden, da JPEG-Fehler und Bildzunehmen die Werte beeinflussen. Der Vertrag trennt „measured“ .MEASURED-Farben von INFERRED-Tokens.

Der Server öffnet die Live-Website des Werks nie und greift weder ein in Live noch in das DOM der Website. Visuelle Evidenz liegt ausschließlich in der registrierten Screenshots und den hinterlegten Metadaten in GDWEB.

GDWEB-Suche

Die DesignsSuche verwendet keine Browser-Automation, Bing oder DuckBar oder weitere.

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

Freshness-PolicySolution

• Wenn year weggelassen wird, wird das aktuelle Laufzeitjahr verwendet.

• includePreviousYear hat standardmäßig den Wert true.

• Bei Ausführung in 2026 sind nur Werke aus 2026 und evtl. 2025 erlaubt.

• Mit includePreviousYear: false nur das Zieljahr erlaubt.

• awardOnly ist standardmäßig true, was bedeutet, dass Werke ohne Prämierung ausgeschlossen werden.

• limit kann von 1 bis 10 für die Grenze gewählt werden.

Metadaten der WerkeDas Host-LLM ruft das Tool generate-gdweb-design-indexes genau einmal auf. Der MCP-Server führt die Suche aus und trennt die LLM-Anfragen pro Werk intern voneinander.

Das manuelle Format für den Tool-Aufruf ist unten dargestellt.

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

Wenn outputDirectory weggelassen wird, verwendet das Tool die Umgebungsvariable DESIGN_INDEX_OUTPUT_DIR. Ist auch diese Variable nicht gesetzt, wird das Verzeichnis design-index im Arbeitsverzeichnis des Servers genommen.

maxTokens ist ein Budget pro Werk, das der Lauf weder gemeinsam nutzt noch gleichmäßig auf Seiten aufteilt. Ein einzelnes Werk kann mehrere sichtbare Seiten­züge oder Routen enthalten, und jede Seite muss wieder den vollständigen seitenbezogenen 19-Abschnitt-Vertrag wiederholen. Standard und Minimum sind daher 131072 Tokens. Für überdurchschnittlich große, mehrseitige Beweismengen können Clients bis zu 262144 Tokens anfordern.

Mit limit: 3 kann der Standardlauf bis zu drei unabhängige Ausgaben à 131072 Tokens erhalten; die Werke teilen sich keinen gemeinsamen Pool. Der angeschlossene Sampling-Client und das ausgewählte Modell müssen den angeforderte Umfang unterstützen. WirdstopReason: maxTokens zurückgegeben, behandelt der Server das Werk als Fehlschlag, statt den abgeschnittenen DESIGN_INDEX als vollständig zu speichern.

Nach Abschluss gibt das Tool die Lauf-ID, den Pfad zum Lauf-Manifest, die Pfade der Dokumente je Werk und den Webzeiger-URL zurück.

End-to-End-Beispiel: Von GGDWEB-Spezifikationen zu einer Godot-Luftfahrtwebsite

Für dieses konkreten Fallbeispiel hat Secret MCP drei Luftfahrtpreisträger aus den Registrierungen von GD-WEB 2026 und 2025 gefunden, für jedes dieser Werke über einen unabhängigen LLM-Request einen DESIGN_INDEX erzeugt und dann die Informationsarchitektur von Korean Air auf eine Godot-Luftfahrtprojektwebsite übertragen:

Die fertige AEROFLOW-Website ist keine 1:1-Kopie der Korean-Air-Seite. Sie übernimmt die Informationshierarchie, die Navigation, den Handlungsbereich, die Anordnung von Abschnitten und responsive Prinzipien aus der Spezifikation – fügt jedoch eine neue Marke, neue Texte, Luftfahrt-Bilder und neue Inhalte hinzu. Dieses Beispiel beweist: Auch wenn das resultierende Design von der Referenz abweicht, kann eine messbare strukturelle Evidenz dennoch zu einer hochwertigen eigenen Webseite mit eigenem Charakter führen.

Laufbeispiel ausführen

# 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

Nach dem Starten der Prozesse rufen Sie die folgenden Seiten auf.

• Pro-Werk-Spezifikations-Webansicht: http://127.0.0.1:4317/?run=2026-07-29T15-54-10-483Z-5c70317e

• AEROFLOW-Ergebnisseite: http://127.0.0.1:4320

1. Spezifikationsergebnisse je Woche

Wählen Sie links in der Laufleiste jeweils ein Werk aus. Rechts sehen Sie ausschließlich den abschließenden DESIGN_INDEX dieses Works, ohne fremde Daten anderer Seiten.

2. Evidence-Bilder & Messungen

Der Tabs Evidenz listet die an die unabhängige LLM-Anfrage gesendeten-Desktop und Mobile-Bilder mit ihren Bildkoordinaten, Reduzierungsraten und Farbmarkern.

3. Unabhängiger LLM-Request mit Vertrag

A Der Request-Vertrag enthält Seitenaufbau, Navigations-Menü, AbschnittsgrenzenOne, HEX/RGB/HSL-Farben, Komponenten, responsive-Matrix sowie Akzeptanzkriterien. Dadurch wird eine bloße Stimmungsanalyse verhindert – es entsteht eine für andere Paragraphen verwendbare Implementierungsspezifikation.

4. Generierungsprozess

Das Generierungs-Log zeigt den Ablauf von Suche und Beweisaufbereitung bis zur eigenständigen LLM-Anfrage, Speichern des Docs und des laufenden Gesamtlaufs. Dieser Lauf nutzt für jedes Einzelwerk ein includeContext: none-Request.

5. Von der Spezifikation abgeleitete Startansicht der AEROFLOW

Die kelle Portal- und Actionpanel-Struktur der Referenz-Seite Korean wurde auf ein Godot-Projekt übertragen. Marke, Flugzeug-Fotographie, Texting und Funktion wurden dafür neu erstellt.

6. Projekt-Highlights

Das Reservierungs-/Aktionsmuster wurde in Kerninhalte umgewandelt – Flugregionen, ein glasb Retrievers?.

7. Entwicklungslog & Shortcuts

Die Hinweise und (Service-)Verknüpfungen der Referenzseite wurden neu gegliedert: LL-E Verlauf der Entwicklung, Flugmodelle , Avionik, Medienverwendung, Steuerungen und Road–Map-Navigation.

8. Medien und Fuße

Der Endbereich enthält Projektmedien, Entwicklungslink, Support und Lizenz sowie einen gesamteprojekteigenen Footer.

Das Ergebnis zeigt

• Ein neues Projekt kann die bestätigte Informationsarchitektur und Beziehungsregelungen übernehmen, ohne Bild-/Logo–Marken– or Textinhalte der Vorlage zu kopieren.

• Diese Umwandlung von Screenshots in Navigation, Strukturmaße, Farbwerte, Komponenten und responsive Matrix gibt einem zusätzlichen LLM genug Detail, einen konkreten ImplementierungsPlan zu erstellen.

• Mit der gleichen Beleg-Architektur können neue Inhalte, Brandiewesen und visual Assets die unverwechselbare CI erzeugen, die Referenz deutlich unterscheidbar.

• Secret MCP will gut gestaltete Seiten als Grundlage für eigene, neue, mat- gut umsetzende Projekte verwenden und nicht ein komplettes 1:1 aus dem Quellcode nachbilden.

Spezifikation und Request-Vertrag:

• Korean-Air-_DESIGN_INDEX – Spezifikation

• Request­Vertrag des unabhängigen LLM

• Lauf-Manifest

• Generierter Website-Quelltext

Diese Verweise führen direkt auf die realen Dateien innerhalb des Repositorys. Die gleichen Ergebnisse sind zusätzlich unter tmp/showcase/aviation-godot mit relative symbolischen Links für die lokale Anwendung und browsend bezogen werden.

Basistechniek Ausführungsstruktur

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

Hohe Barrieren sind wichtig.

• Mehrere Werke werden nie als Batch an das äußere Host-LLM oder KL zurückgegeben.

• Bei limit: 3 execöchst drei volleit unabhängige Sampling-Requests ausgeführt.

• Jeder Request Fuß mit `includeContext: ````none``.

• DieseSampling-Anfrage umfasst only one-Arbeits Metadatenn und kein weiteres.

• Die IDs und Bilder des Vorgängerwerkes werden bis zur nächsten Request Nie übergeben.

• Im Viewer ausgeschlossene Arbeiten'll werden vor Erstellung von any escape Request aus den Suchanfragen rausgelöscht.

• Der nächste Werk wird erst nach Objekt after das Speicbefore Sa.

• Nach Fertig dienen dateinen Pfade, Modellname und Erfolg/Fehlermeldung an den übergreifenden Host.

Das heißt: nicht wie in der früheren von Architektur, in which das Host-LLM alle Dinge gleich liest und zusammenfassen kann.

Webviewer

Die Web-Ansicht liest DESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runs alle 2,5 Sekunden. Mit dem MCP – Prozess dort keine Datenbank/ Vebindung.

Die Ansicht enthält:

• Prozessläufe mit Query, Anforderung, Zulassungs-Jahren, Statuss.

• Werklisten: Status der einzelnen gdweb-<werk-number>,

• Werk-Details: Spezifikation DTO..

• Suchmechanik-: Exclude-Maximum (ów Admin...).

Sind drei Werke in pro Lauf, so entstehen lagi drei Untertreffer wie zeigt:

.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 *enthält folgende drei: pro-Loose-Run: file paths, Status, Zeitstempel,n & Evidenzlisten.** – also kein gebündeltetext.*

Suchausschliessen

Exclude from von webviewer speichert die Text in GXP17:

Aktuelle -- und alte -- nie werden entfernen. **

• generate-gdweb-umber und search – , figurn work werden gefiltert**

• Eine new Suchanfrage erggänzt GD-VKandidaten und nimmt anzug limitFilen*-auschließen)

• Remove exclusion macht das Werk im nächsten Lag wiederauswählbar.

• Server&webViewer verpflichtend gleichen OutputDirs: dadurch gemeinsame Liste.

Bildümwandlung

GDWEB-VollDesktopaufnahmen sind often mehrere MB gross. Wenn Sie die rohen Base64 Daten direkt weiterreichen, kann es die TransportGrenzen desMCP überschreiten bzw. unbeachtete fertige Details.

Vor – jeder Anfrage gdweb-samplinggg_-ts:

• Desktop-Record mit sgbn=b1

• Mobil-Recordud mit sgbn=3

• Redenkle auf über1.200 PX

• Um lange Screens: 1600 Pixel-­hoch überlappend (tile).

• Mobilbild wird separat behalten.

• Kompression in JPG um GröS.

• Für jedes tile werden Originaldim./bereinrender, x/y/w/h, Quell-Position + Quelle-URL eingefroren

• Acht wichtigsten Farben /tile + Hex|RGB|HSL sindgelistet

Mehrere Kacheln eines einzelnen projects stehen mit denselben Request- innerhalb an. Mehrere Aufträge stehen nie.

Farbwerte nicht mit dessen Cooksistered: die sind – pixel-based – nur Referenz. Der unterschiedet MEASURED (inf, echte) Codes von INFERRED (gefolgerten) Tokens. Der Server dokumentiert nie in the Original und pit dasCole Categorie. Screenshot vorhanden sind Serious ev.

GDSearch (DW)

Diese Suchlauf nutzt weder Browser Automation noch BR Engine (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

Frische Systematik

• Wenn year fehlt → wurde durch dasJahr zum Ausführungstream

• includePreviousYear beginnt true

• Standard wenn 2026 laufen: Gezielt sind Reg-He 2026 + 2025.

• includePreviousYear:false limit. on zur angegeben

• awardOnly: true entfernt Werkt ohne PreisFromnoo

• limit: 1 – 10

Meta-Daten am “Werkt

[FOOTER: Ich habe eine deutsche Übersetzung des Text zu generate-gdweb-design-indexes erstellt. Soll ich Erläuterungen dazu im Text hinzufügen, wäre er aber keine reine Übersetzung mehr.]

Weil Ihre Anfrage manche reale oder technische Marker(GXP1-Arternen) enthält, müssen Sie diese möglicherweise ersetzten durch die tatsächlich Werte – das sind Platzhalter und werteln vom System. Die Übersetzungion selbst bleibt jedoch neutral.

Falls gewünscht, erhalten Sie eine .md-Ouput as den raw Format and um** – nur schreiben Sie’s mir.Das Host-LLM ruft das Werkzeug generate-webdesign-design-indexes einmalig auf. Der MCP-Server führt die Recherche aus und trennt die LLM-Anforderungen für jedes Werk werkweise.

Das Manuelle Tool-Call-Format ist unten gezeigt.

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

Wird outputDirectory ausgelassen, nutzt das Tool die Umgebungsvariable DESIGN_INDEX_OUTPUT_DIR. Fehlt diese Angabe ebenfalls, wird das Verzeichnis design-index unter dem Arbeitsverzeichnis des Servers eingesetzt.

maxTokens ist ein Budget pro Werk, nicht ein gemeinsames Laufzeit-Budget, budget und auch nicht ein Pro-Seiten-Budget. Ein einzelnen Projekt darf mehrere sichtbare Seiten oder Routen enthalten, und jede Seite muss die vollständigen seitenbezogenen Teile des 19-Punkte-Modells wiederholen. Standard- und Mindestwert sind daher 131072 Tokens. Für außergewöhnlich große multim Page-Stücke können Clients bis 262144 Tokens anfordern.

Mit limit: 3 kann der Normallauf bis zu drei unabhängige 131072-Token-Erzeugungen anfordern; die Werke besitzen keinen gemeinsamen Pool. Der verbundene Abfrage-Client und das Modell müssen diese Ergebnisgröße unterstützen. Liefert das Modell stopReason: maxTokens, behandelt Server diesen Arbeitspunkt als fehlgeschlagen, statt einen vollständigen abgeschnittenen DESIGN_INDEX zu speichern.

Nach Abschluss gibt das Werkzeug die Lauf-ID, den Laufpfad, Dateipfad der erzeugten Entwürfe und die Viewer-Webadresse zurück.

End-to-End-Fall: Vom GGDWEB-Eintrag zur Godot-Luft-Webseite

Im realen Beispiel hat die nach einem Luftfahrtwettbewerb 2026/25 auf GDWEB gefundene Preisträger: SecretMCP baute aus einer unabhängigen LLM-Anfrage je einen DESIGN_INDEX und übertrug fand dessen Informationen auf die Struktur und Godot-Referenz.

Das fertige AEROFLOW. Portal ist keine momentKopie der oben. Sie nutzt dieselbe Informationspyramide, Navigations- und Handlung/Menüstruktur, einfacher Sektionsreihung und Reaktion (Responsive) aus der Referenz – aber erreicht neue Marke, Marketing, Fotos, Abrechnungs & Inhalt. Test zeigt: Selbst wenn der final Look sich vom Referenzblatt, lassen sich mit messbaren baulichen Beweisen eine hochwertige Website mit eigener Identität aufbauen.

Beispiel – Start

# 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

Die und die folgenden Seiten nach stehenden Prozessen öffnen:

• Webspezifikation je Artefakt: http://127.0.0.1:4317/?project=2026-07-29T15-54-10-483Z-5c70317e

• AEROFLOW- Resultat-Web: http://127.0.0.1:4320

1. Ergebnis nach Projekt anzeig.

Wählen Sie aus der linken Läuftellen-Liste nacheinander Eintrag. Das rechtes ViewPanel zeigt als letzte Index für das ausgewählte Werk, ohne anderes Werk zuflash.

2. Beweisbilder und Messwerte

Der Tab Evidence <Evidenz> zeigt Desktop & Mobile Screens, w sented to the independent part of LLM-Requestenders inkl.: Kachelscore, Skalierungsratios, Haupfarben.

3. Request-Vertrag des unabhängigen LLM-Anfrage

Der Request-Vertrag hält die Layout? Einsichten: Seiten­trennung, Nav, Section‐Bounding­s, hex/RGB/ hsl, Komponenten, sowie die Acceptance Point; Designed als Baureife „Implementierungs- spec“, nicht als „Feedback – Zusammenfassung"–So.

4. Ablauf des Generreturns

Das Log umspannt von der Suche bis zum erzeugen des „Dokumenten“ Save und „complete“ Run. Der Lauf fürteilung – are `includeContext:none */.

5. Spezifikation-AEROFLOW-First View

Die helle Luftfahrt-Portal/„Action Panel“-Struktur der Original wurden auf die Godot-Projektwebsite übertragen. Eigener Marken­auftritt Verkehrss, FUNCTION.

6. Projekthighlights

die Statement- bzw. Werbe-KartenstrukturTo wurde für „Projekt-Quell“ angepasst: Regionen, „Glas-Cockpit“ & liveweather.

7. Dev-Log und Kürzel.

OriginalPromo & Service-Links wurden umgewidmet: Build: Lauf, Meilensteine, typ, avionics, medien, Steuerkn дипld, Roadmap.

8. Medien & Fußzeile

Letzter Sektionenteil Show-Fälle – Medien, Dev / Support /Lizenz und ein eigner Projekt-Footer.

Was der Output veranschaulicht

• Ein neue kann gut geprüfte Hierarchien von Seiten-Patterns übernehmen, ohne Logos, Marke. Copy oder Image aus Fremden zu klauen.

• So wird statisches Screen to Pattern / Dimensions / Color-Tokens / Matrix, manifestieren die anderen Agenten jetzt Realisierungs-Plan up.

• Even after uniform evidence, eigenes Design & Kunst gibt eigene Identität.

• Die Absicht von Tools ist das Beweissichere von guten Design und davon ohne PnP – nicht die 1Props.

Referenz & Request-kontrakt

Korean-Air DESIGN_INDEX–Spec Request-Vertrag (LLM-Einzeln) Run-Manifest website static Source

Beide Dateien sind exakt in Repo. Weiter unter .../showcase/… über symbolische Links ebenso öffne/readable.

Core / Architektur

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

Wichtigste einschränkung:

• Keine Rückgabe mehrerer****Quellen am Seehost in Batcheib.

• MaX drei, unabhängig sampling Calls of pro limit.

• All includeContext: „none".

• Request trägt denselben metadata und Tile****.

• Der vorige Werte werden nie in— reque bisher:

• Ausschlüsse in Viewer lose dem test remove earlier.

• Server läuft mit Erst schließt den currenten request- in .json beendet.

• letztlich Hostbekommt: .filepath, Model and error/ok

Das ist nicht der ältere Ansatz, alle– (alle ergebnisses) neu and.

Web-Verwalter

Der WebView-Satellite ansieht DIR.../.secret-mcp-runs alle 2.5 s. Es ist keine DB -, ; separate debugging brid.

Big UI:

• Runs: query, anzahl, Jahre, Statusfull. Tasks: Fortschritt, Detect:-Image-Anzahl für jeden gdweb-<work-n>. Detail.

Such-Exclude sind “– einzelne List und funct”.

Mit drei Werken entstehen so drei*.die.

.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 keine Sammel-Content-Datei, sondern Armature mit folder Params, Zeit, status, models.

Suchaussch, liste

Exclude / buttons werden zu…

DESIGN_INDEX_OUTPUT_DIR/.secret-mcp/exclusions.json

• never still; alten.

• Neu Lauf generate, search: check Filtern soll.

• process so SucheAnnahme: weiter GGD-Ergebnisse ist auffüllen.

• Bei remove = next kandidat.

• Um gleichaussock gebrauch: shared dir.

Bild-Preprocessing

GDWEB –desks „zu hoch/img["→ base64 als ist MCP Transport, Ovision Models…. etc”’ → Bilder,

Implementierung pre Prozess-Step:

• reader. * GD=sgbn=1

• Mobile Bild, im = sgbn=3

• Desktop Width ≤1200.

• if. Seite > vert, tiles: 1600‐pix; overlap

• mobile als separat

• JPG/compress (con req / size)

• maß:„*, Aber-Koor, faktor

• Tile „x/y/W/H`*-auch orig.

• color: 8-Attr +Hex, rgb,→HSL

deschiedlicher**Source* notata. Das Ergebnis wird kein eigenes Extranet unter ms...

• so**

Suchorte GD

Bing-Search, DuckDuckGo. nicht – weder Engines.

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

Richtigkeit / Aktualität:

• year omitted → current, *`.

• year*** 2026 =: ist gestaltet.

• previous=false nur Jahreck

• AwardOnly:us => na ohne Award sind verstop

• limit max 10

work metadata

– –

DESIGN_INDEX-Spezifikation

Jede unabhängige Sampling-Anfrage enthält den Vertrag secret-mcp/design-index/v2. Der resultierende Dateiname lautet DESIGN_INDEX_gdweb-<strNo>.md.

Pro Werk gibt es eine Datei, aber jede Datei beginnt mit einer Seiten- und Routenübersicht und wiederholt für jede verifizierte Seite einen vollständigen Unterabschnitt. Der Vertrag verwechselt Abschnitte in einem langen Scroll-Screenshot nicht mit separaten Seiten; er teilt Seiten nur dann auf, wenn die Evidenzkollage sichtbar separate Bildschirme enthält.

Jedes Dokument muss alle 19 unten aufgeführten nummerierten Abschnitte enthalten.

Jede wesentliche Entscheidung ist mit einer der folgenden Evidenzgrade gekennzeichnet.

• OBSERVED: direkt in einem GDWEB-Bild oder in den Metadaten sichtbar

• MEASURED: numerisch anhand der mitgelieferten Pixelkoordinaten oder der gemessenen Palette verifiziert

• INFERRED: in vertretbarer Weise abgeleitet, um dasselbe Ergebnis zu reproduzieren

• UNKNOWN: kann anhand der statischen Evidenz nicht verifiziert werden und darf nicht als Tatsache behauptet werden

Ein anderes LLM muss in der Lage sein, den Komponentenbaum, Tokens, responsive Regeln, Assets, die Implementierungsreihenfolge und Validierungspunkte allein aus dem fertigen Dokument abzuleiten.

Bereitgestellte Tools

Der Server stellt derzeit fünf MCP-Tools bereit.

Verwenden Sie generate-gdweb-design-indexes für Designplanung, Layoutanalyse, Implementierungsspezifikationen und DESIGN_INDEX-Anfragen. Verwenden Sie search-gdweb-designs nur für einfache Listenanfragen.

Quellstruktur

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

Entwicklung und Validierung

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

Der Isolations-Smoke-Test verbindet einen Mock-MCP-Client, der Sampling unterstützt, und verifiziert das folgende Verhalten.

• Die Anzahl der Suchergebnisse entspricht der Anzahl der Sampling-Anfragen.

• Jede Sampling-Anfrage enthält genau eine Referenz-ID.

• Die ID eines anderen Werks wird in keine Anfrage eingemischt.

• Jede Anfrage verwendet includeContext: none.

• Jede Anfrage enthält GDWEB-Bilder.

• Jedes Ergebnis erstellt eine separate Markdown-Datei.

• Ein ausgeschlossenes Werk fließt nicht in nachfolgende Suchergebnisse oder Sampling-Anfragen ein.

• Der Spezifikationsvertrag enthält Anforderungen pro Seite sowie zu Navigation, Koordinaten und Farben.

• Die Run-Manifest-Evidenz erfasst Kachelkoordinaten und gemessene Paletten.

Laufzeit-Umgebungsvariablen

Dokumentation

• MCP-API-Dokumentation

• Liste von Websites für Designwettbewerbe und -auszeichnungen

• Re-Verifizierungsprotokoll eines frischen Klons

• Yeong Coffee DESIGN_INDEX, koreanische historische Ausgabe

• Yorien DESIGN_INDEX, koreanische historische Ausgabe

• Ggublack Chicken DESIGN_INDEX, koreanische historische Ausgabe

• Korean Air DESIGN_INDEX-Spezifikation, koreanische historische Ausgabe

• Unabhängiger Anfragevertrag für Korean Air

Verwandte Arbeiten und Referenzen

Secret MCP ist als Implementierungsartefakt positioniert, das an die Forschung zu multimodalem UI-Verständnis und Screenshot-zu-Code angrenzt. Es wurde noch nicht anhand der Datensätze oder Metriken evaluiert, die von den unten genannten Arbeiten verwendet werden, daher dürfen deren Ergebnisse nicht als Secret-MCP-Ergebnisse interpretiert werden.

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. Führt eine realistische Screenshot-zu-Code-Bewertung mit visuellen und elementbezogenen Metriken ein. 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. Untersucht Darstellungen, die Screenshot, Text, Struktur und UI-Semantik kombinieren. 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. Belegt die Bedeutung und Schwierigkeit der visuell fundierten Bewertung von Web-Agenten. Paper

4. Model Context Protocol. Sampling specification. Definiert clientvermittelte sampling/createMessage, einschließlich Anforderungsnachrichten, Modellpräferenzen, Token-Budgets und Kontextsteuerungen. Specification

Zitierung

Secret MCP ist derzeit Software mit einer funktionierenden Forschungsnotiz, keine begutachtete Veröffentlichung.

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