영어 | 한국어
웹 디자인 분석, 스크린샷-대-명세 워크플로우, 프런트엔드 재구축 계획을 위한 증거 기반 MCP 서버.
npx -y secret-design-mcpSecret MCP는 GDWEB에서 최신 디자인 참고자료를 검색하고 검색 결과마다 별도의 LLM 요청과 별도의 DESIGN_INDEX 파일을 생성하는 로컬 Model Context Protocol(MCP) 서버입니다. 각 파일에는 제공된 시각적 증거로 추적 가능한 페이지 및 경로별 레이아웃, 내비게이션, 픽셀 좌표, 색상, 컴포넌트, 반응형 사양이 포함됩니다.
Secret MCP라는 이름은 이 프로젝트가 비밀 기능이나 개인 데이터를 제공한다는 의미가 아닙니다. 디자인 웹사이트를 중심으로 MCP 서버를 구축한다는 아이디어로 프라이빗 저장소에서 실험할 때 사용한 프로젝트 이름입니다. 이 프로젝트의 현재 목적은 공개 디자인 참고자료에서 재현 가능한 구조적 증거를 추출하여 LLM이 새 프로젝트에 적용할 수 있는 작업물별 사양서로 만드는 것입니다.
여러 작업의 이미지와 설명이 단일 LLM 컨텍스트나 문서에 결합되는 일은 없습니다. 서버는 검색 결과를 서버 내부에서 순차적으로 처리하고, 각 작업에 대해 독립적인 MCP sampling/createMessage 요청을 생성하며, 해당 작업의 파일을 저장한 후에만 다음 작업으로 진행합니다. 별도의 로컬 웹 애플리케이션에서 한 번에 하나의 작업을 선택하고, 소스 증거, 측정된 색상 및 좌표, LLM 계약, 생성 로그, 최종 문서를 검토하고 이후 검색의 제외 목록을 관리할 수 있습니다.
Related MCP server: Refero MCP
MCP 샘플링을 통한 증거 격리 멀티모달 디자인 분석
워킹 페이퍼 및 구현 보고서 · Secret MCP v0.6.0 · 비동료 검토
Secret MCP는 공개 웹페이지 스크린샷을 구현 지향 디자인 사양으로 변환하는 감사 가능한 파이프라인을 구현합니다. 이 시스템은 데스크톱 및 모바일 시각 증거를 준비하고, 크롭 좌표와 대표 픽셀 색상을 기록하며, 참조물당 한 번씩 클라이언트 측 MCP 샘플링을 호출합니다. 여러 디자인 참조물을 하나의 프롬프트에 연결하는 워크플로우와 달리 Secret MCP는 참조물의 정체성을 요청 경계이자 산출물 경계로 취급합니다. 즉, 참조물 하나는 하나의 샘플링 요청, 하나의 요청 계약, 하나의 DESIGN_INDEX 문서를 생성합니다. 각 요청은 includeContext: none을 요청하고 경로, 지오메트리, 컴포넌트, 디자인 토큰, 반응형 동작, 접근성, 구현 작업, 승인 기준, 불확실성을 다루는 동일한 19개 섹션 사양 계약을 적용합니다. 이 보고서는 프로토콜 수준의 격리와 산출물 생성을 평가하며, 특정 언어 모델, 프롬프트 또는 재구성 방법이 더 우수하다고 주장하지 않습니다. 라이브 스모크 테스트로 요청 경계를 검증하고, 보존된 3개 참조 실행으로 기술적 측정값과 정성적 구현 사례를 제공합니다.
질문 | 현재 증거 | 상태 |
RQ1. MCP 디자인 분석 도구가 참조물당 요청 하나의 격리를 유지할 수 있는가? | 교차 참조 ID 검사 및 출력 파일 확인을 통한 라이브 샘플링 스모크 테스트 | 테스트 범위 내에서 검증됨 |
RQ2. 스크린샷 증거를 감사 가능한 공간, 색상, 문서 산출물로 변환할 수 있는가? | 증거 매니페스트, 계약, 생성 문서가 포함된 보존된 3개 참조 실행 | 기술적으로 검증됨 |
RQ3. 결과 사양이 별도의 프런트엔드 구현을 안내할 수 있는가? | AEROFLOW 정성적 사례 연구 | 예비적, 대조 비교 없음 |
참조물 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 | 1 | 0 | 1 |
요청 2 | 0 | 1 | 1 |
그림 1. 금융 쿼리(gdweb-26905 제외 후 n = 2개 참조 샘플링)를 사용하여 2026-08-22에 기록된 라이브 스모크 테스트. 각 요청에는 자체 참조 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,675px | 3 | 126.6KB | 24 | 7,921 | 54.0KB | 19/19 |
| 7,043px | 4 | 302.5KB | 32 | 9,953 | 69.8KB | 19/19 |
| 7,832px | 5 | 387.8KB | 40 | 9,517 | 63.2KB | 19/19 |
그림 2. 보존된 실행 2026-07-29T15-54-10-483Z-5c70317e(n = 3개 참조)의 기술적 측정값. 이 실행은 총 816.9KB의 증거 이미지 12개를 준비하고 96개의 대표 색상 측정값을 기록했습니다. 총 27,391개의 공백 구분 토큰과 187.0KB 크기의 DESIGN_INDEX 문서 3개를 생성했습니다. 세 문서 모두 1~19번 제목을 포함하지만, 제목 존재가 의미적 정확성을 보장하지는 않습니다.
(a) 증거 및 측정값 | (b) 참조물별 | (c) 사양 기반 구현 |
|
|
|
그림 3. GDWEB 증거 뷰어에서 생성된 대한항공 DESIGN_INDEX, 그리고 AEROFLOW로 이어지는 보존된 정성적 추적 기록. AEROFLOW는 의도적으로 새로운 브랜딩, 콘텐츠, 이미지, 기능을 도입합니다. 이 예시는 사양 사용을 설명하기 위한 것이며 통제된 시각적 충실도 비교가 아닙니다.
라이브 격리 결과는 n = 2이고, 기록된 산출물 분석은 n = 3입니다. 어느 것도 디자인 품질이나 모델 성능에 대한 광범위한 주장을 뒷받침하지 않습니다.
현재 평가에는 대조군, 인간 평가, 반복 시행, 신뢰 구간, 스크린샷-대-코드 기준선과의 비교가 없습니다.
대표 색상은 크기 조정, JPEG 정규화, 채널 양자화 후에 측정됩니다. 이는 소스 웹사이트의 CSS 토큰이 아닌 스크린샷 증거입니다.
19/19 결과는 필수 제목 존재 여부를 측정합니다. 향후 벤치마크는 사실적 근거, 좌표 오류, 색상 차이, 반응형 동작, 구현 충실도를 별도로 평가해야 합니다.
정성적 구현은 존재 사례일 뿐 Secret MCP가 재구성 품질을 향상시킨다는 증거는 아닙니다.
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 buildMCP 서버와 웹 애플리케이션 모두에 DESIGN_INDEX_OUTPUT_DIR을 동일한 값으로 설정하여 두 프로세스가 동일한 출력 디렉터리를 읽도록 하세요.
DESIGN_INDEX_OUTPUT_DIR=/absolute/path/to/design-index npm run web브라우저에서 다음 주소를 여세요.
http://127.0.0.1:4317웹 애플리케이션에는 생성 실행 목록, 작업별 진행 상황, GDWEB 증거 이미지, 측정된 좌표 및 팔레트, LLM에 전송된 사양 계약, 최종 Markdown, 생성 타임스탬프가 표시됩니다. 문서와 증거는 읽기 전용이며, 검색에서 제외 및 제외 제거만 이후 검색에 사용되는 필터를 변경합니다.
{
"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 메시지를 교환합니다. 별도의 웹 뷰어 프로세스만 기본적으로 포트 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 샘플링 호출에 반환하며, 서버가 작업의 계약, 증거, 문서를 저장한 후에는 제거할 수 있습니다.
서버는 여전히 순차 대기열을 제어합니다. 즉, 작업 1이 반환되어 저장되기 전에는 작업 2가 준비되지 않습니다. 이로 인해 새 프로세스와 작업 공간은 서버에 결합된 폴백을 추가하지 않으면서 프로토콜 수준의 includeContext: none 경계와 실행 수준에서 동일해집니다. 직접 클라이언트는 샘플링 가능한 MCP 호스트가 되며, 작업별 출력 예산에 충분히 긴 도구 호출 제한 시간을 사용해야 하며 단일 영구 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 토큰입니다. 클라이언트는 예외적으로 큰 다중 페이지 증거 세트에 대해 최대 262144 토큰까지 요청할 수 있습니다.
limit: 3인 경우 기본 실행은 최대 3개의 독립적인 131072 토큰 출력을 요청할 수 있으며, 작업들이 하나의 131072 토큰 풀을 공유하지는 않습니다. 연결된 샘플링 클라이언트와 선택된 모델은 요청된 출력 크기를 지원해야 합니다. 모델이 stopReason: maxTokens를 반환하면 서버는 해당 작업을 실패로 처리하고 잘린 DESIGN_INDEX를 완료로 저장하지 않습니다.
도구가 완료되면 실행 ID, 실행 매니페스트 경로, 작업별 문서 경로 및 웹 뷰어 URL을 반환합니다.
실제 예시에서 Secret MCP는 2026년과 2025년에 GDWEB에 등록된 항공 수상작 3개를 찾아 각 작업에 대해 독립적인 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프로세스를 시작한 후 다음 화면을 엽니다.
작업별 명세 웹 뷰어: http://127.0.0.1:4317/?run=2026-07-29T15-54-10-483Z-5c70317e
AEROFLOW 결과 웹사이트: http://127.0.0.1:4320
왼쪽의 실행 목록에서 작업을 하나씩 선택합니다. 오른쪽에는 다른 작업의 콘텐츠가 섞이지 않고 선택한 작업의 최종 DESIGN_INDEX만 표시됩니다.
Evidence 탭에는 독립적인 LLM 요청에 전송된 데스크톱 및 모바일 이미지, 타일 좌표, 축소 비율, 대표 색상이 표시됩니다.
Request Contract는 페이지 분리, 내비게이션, 섹션 경계, HEX/RGB/HSL 색상, 컴포넌트, 반응형 매트릭스, 수용 기준을 기록합니다. 이 계약은 결과물이 피상적인 분위기 요약에 그치지 않게 하며, 다른 LLM이 사용할 수 있는 구현 명세로 만듭니다.
Generation Log는 검색 및 증거 준비부터 작업별 독립 LLM 요청, 문서 저장, 전체 실행 완료까지의 순서를 보여줍니다. 이 실행은 세 작업 모두를 별도의 includeContext: none 요청으로 처리했습니다.
Korean Air 참조에서 관찰된 밝은 항공 포털 및 액션 패널 구조를 Godot 프로젝트에 맞게 적용했습니다. 브랜드, 항공기 이미지, 카피, 기능은 이 결과물을 위해 새로 제작되었습니다.
예약 및 프로모션 카드 구조를 핵심 프로젝트 콘텐츠(비행 지역, 글래스 칵핏, 실시간 날씨)에 맞게 재사용했습니다.
소스 참조의 공지사항과 서비스 바로가기를 빌드 이력, 개발 진행 상황, 비행 모델, 항공전자, 미디어, 조종, 로드맵 내비게이션으로 재구성했습니다.
마지막 영역에는 프로젝트 미디어, 개발, 지원, 라이선스 링크가 있고 그 뒤에 독립 프로젝트 푸터가 이어집니다.
새 프로젝트는 참조의 로고, 상표, 카피, 이미지를 복사하지 않고도 검증된 정보 계층과 레이아웃 관계를 사용할 수 있습니다.
정적 스크린샷을 내비게이션, 픽셀 경계, 색상 토큰, 컴포넌트, 반응형 매트릭스로 변환하면 다른 LLM이 구체적인 구현 계획을 세울 수 있을 만큼 충분한 세부 정보를 얻을 수 있습니다.
동일한 구조적 증거를 사용하더라도 새로 디자인된 콘텐츠, 브랜딩, 시각 자산은 출처와 다른 개성 있는 정체성을 만들어낼 수 있습니다.
Secret MCP는 우수한 디자인에서 구조적 증거를 추출하여 새 프로젝트에 맞는 완성도 높은 웹사이트를 만드는 데 사용하도록 설계되었으며, 출처를 픽셀 단위로 재현하기 위한 것이 아닙니다.
이 링크는 저장소에 포함된 실제 파일을 직접 가리킵니다. 동일한 아티팩트는 로컬 실행과 탐색을 위해 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인 경우 서버는 정확히 최대 3개의 상호 독립적인 LLM 샘플링 요청을 수행합니다.
모든 샘플링 요청은 includeContext: none을 사용합니다.
샘플링 요청에는 단일 작업의 메타데이터와 이미지 타일만 포함됩니다.
이전 작업의 ID, 이미지, 분석 문서는 다음 작업의 요청에 절대 전달되지 않습니다.
웹 뷰어에서 제외된 작업은 샘플링 요청이 생성되기 전에 검색 결과에서 제거됩니다.
서버는 현재 샘플링 응답을 파일로 저장한 후에만 다음 작업을 시작합니다.
마지막에는 생성된 파일 경로, 사용된 모델, 성공 또는 실패 상태만 호스트에 반환됩니다.
즉, 이는 호스트 LLM이 모든 결과를 한 번에 읽고 통합 요약을 생성하던 이전 아키텍처가 아닙니다.
웹 뷰어는 2.5초마다 DESIGN_INDEX_OUTPUT_DIR/.secret-mcp-runs를 읽습니다. MCP 생성 프로세스와 웹 서버 사이에 별도의 데이터베이스나 디버깅 연결은 없습니다.
인터페이스에는 다음 영역이 포함됩니다.
생성 실행: 쿼리, 요청된 수, 허용 연도, 전체 상태
작업 목록: 각 gdweb-<work-number>에 대한 진행률 및 증거 이미지 수
작업 세부 정보: 선택된 단일 작업의 명세, 증거 이미지 및 측정값, 요청 계약, 생성 로그
검색 제외: 선택한 작업을 향후 검색에서 제외하거나 다시 포함하고 전체 제외 목록을 관리
실행에 작업이 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.mdrun.json은 여러 작업의 문서 본문을 결합한 파일이 아닙니다. 작업별 파일 경로, 상태, 타임스탬프, 모델, 증거 목록만 포함하는 뷰어 매니페스트입니다.
웹 뷰어에서 Exclude from search를 선택하면 작업 번호가 다음 파일에 저장됩니다.
DESIGN_INDEX_OUTPUT_DIR/.secret-mcp/exclusions.json과거 실행과 생성된 문서는 절대 삭제되지 않습니다.
새로운 generate-gdweb-design-indexes 및 search-gdweb-designs 실행은 선택 전에 작업 번호를 필터링합니다.
제외로 인해 결과가 너무 적게 반환되는 것을 방지하기 위해 검색은 GDWEB 후보를 추가로 읽고 제외되지 않은 작업에서 요청된 limit만큼 선택합니다.
Remove exclusion을 선택하면 다음 검색부터 해당 작업이 다시 대상이 됩니다.
MCP 서버와 웹 뷰어가 동일한 제외 목록을 공유하려면 동일한 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 및 픽셀 적용 범위를 기록합니다.
한 작업의 여러 타일은 동일한 작업별 샘플링 요청에 포함됩니다. 서로 다른 작업의 타일은 같은 요청에 절대 포함되지 않습니다.
대표 색상은 정규화된 스크린샷 픽셀에서 샘플링한 측정값입니다. 시각적 비교를 위한 정밀한 증거이지만 JPEG 오류와 이미지 콘텐츠가 값에 영향을 주기 때문에 소스 사이트의 CSS 변수로 제시되어서는 안 됩니다. 생성 계약은 MEASURED 색상과 INFERRED 구현 토큰을 구분합니다.
서버는 작업의 실제 운영 웹사이트를 열거나 DOM을 크롤링하지 않습니다. 시각적 증거는 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 imagesyear가 생략되면 현재 런타임 연도가 사용됩니다.
includePreviousYear의 기본값은 true입니다.
2026년에 실행하면 기본적으로 2026년과 2025년에 등록된 작업만 허용됩니다.
includePreviousYear: false이면 대상 연도만 허용됩니다.
awardOnly의 기본값은 true이므로 수상 이름이 없는 작업은 제외됩니다.
limit는 1부터 10까지 설정할 수 있습니다.
필드 | 설명 |
| GDWEB 작품 번호, 문서 파일명에도 사용됨 |
| GDWEB 작품 분류 값 |
| 작품 제목 |
| GDWEB 작품 상세 페이지 |
| 등록 날짜 및 연도(필터링에 사용) |
| 수상 내역 |
| 디자인 콘셉트 |
| 기본 색상 |
| 제작사 |
| GDWEB 데스크톱 캡처 ( |
| GDWEB 모바일 캡처 ( |
모든 독립 샘플링 요청에는 secret-mcp/design-index/v2 계약이 포함됩니다. 결과 파일명은 DESIGN_INDEX_gdweb-<strNo>.md입니다.
작품마다 파일이 하나씩 생성되지만, 각 파일은 페이지 및 경로 인벤토리로 시작하며 검증된 모든 페이지에 대해 완전한 섹션을 반복합니다. 이 계약은 긴 스크롤 캡처 내의 섹션을 별도의 페이지로 간주하지 않으며, 증거 콜라주에 별도의 화면이 명확히 보일 때만 페이지를 분할합니다.
모든 문서는 아래의 19개 번호 매겨진 섹션을 모두 포함해야 합니다.
영역 | 필수 명세 |
재구성 목표 | 참조 ID, 목표 충실도, 경로, 목표 뷰포트, 비목표 |
증거 및 좌표계 | 이미지 ID, 원본/준비된 치수, 배율, 타일 좌표, 소스 공간 좌표, 중복 제거 방법 |
사이트 맵 | 검증된 페이지 및 경로, 목적, 증거 이미지, 공유 셸, 활성 메뉴, 신뢰도 |
공유 앱 셸 | 전역 배경, 컨테이너, 거터, 페이지 크롬, 스태킹 컨텍스트 |
내비게이션 | 데스크톱/모바일 높이, 로고/메뉴 좌표, 간격, 터치 영역, 활성/호버/포커스/열림 상태 |
페이지별 명세 및 좌표표 | 캔버스 모델, 섹션 순서, x/y/너비/높이, 레이아웃, 상태, 데이터, 모든 페이지의 증거 수준 |
레이아웃 상세 분석 | DOM, 그리드/플렉스, 트랙, 최소/최대, 비율, 간격, 오버플로, 고정, 절대 위치, z-index |
컴포넌트 추상화 | 페이지 연결 컴포넌트 트리, props, 변형, 슬롯, 상태, 이벤트, 데이터 계약 |
토큰 및 정확한 색상 | HEX/RGB/HSL/알파, 용도, 측정 좌표, 신뢰도, 허용 오차, CSS 변수 |
타이포그래피 | 역할별 글꼴 패밀리, px/rem, 두께, 줄 높이, 자간, 정렬, 말줄임, 반응형 값 |
에셋 및 아이콘 | 페이지 및 섹션, 표시 크기, 종횡비, 크롭, 초점, object-fit, 로딩, 폴백 전략 |
반응형 매트릭스 | 1440/1280/1024/768/390/360px에서의 컨테이너, 열, 순서, 가시성, 내비게이션, 간격 |
인터랙션 및 모션 | 모든 상태의 색상, 불투명도, 변형, 지속 시간, 이징, 키보드, reduced-motion 동작 |
접근성 | 페이지별 랜드마크, 제목, 포커스, 메뉴 의미론, 라벨, 대체 텍스트, 대비, 터치 대상 |
데이터 및 콘텐츠 | 페이지 엔티티, 필드, 개수, 정렬, 형식, 지역화, 로딩/빈/오류 상태 |
프론트엔드 아키텍처 | 경로, 디렉터리, 페이지/공유 모듈, 토큰, 에셋, 상태, 서버/클라이언트 경계 |
구현 작업 그래프 | 측정, 셸, 내비게이션, 페이지별 작업 ID, 종속성, 산출물, 완료 기준 |
페이지별 승인 기준 | 좌표, 색상, 타이포그래피 허용 오차, 뷰포트 비교, 오버플로, 에셋, 키보드, 성능 |
불확실성 및 결정 | 페이지별/섹션별 UNKNOWN, 채택된 값, 대안, 신뢰도, 추가 증거 요구 사항 |
모든 주요 판단에는 다음 증거 수준 중 하나가 표시됩니다.
OBSERVED: GDWEB 이미지 또는 메타데이터에서 직접 확인됨
MEASURED: 제공된 픽셀 좌표 또는 측정된 팔레트에서 수치적으로 검증됨
INFERRED: 동일한 결과를 재현하기 위해 합리적으로 추론됨
UNKNOWN: 정적 증거만으로는 검증할 수 없으며 사실로 단정해서는 안 됨
다른 LLM은 완성된 문서만으로 컴포넌트 트리, 토큰, 반응형 규칙, 에셋, 구현 순서, 검증 항목을 도출할 수 있어야 합니다.
서버는 현재 5개의 MCP 도구를 노출합니다.
도구 | 용도 |
| GDWEB 검색, 결과별 격리된 LLM 요청, 문서 저장 |
| 명세 생성 없이 GDWEB 참조 목록 반환 |
| 일반 웹 검색 및 전체 페이지 콘텐츠 추출 |
| 일반 검색에서 제목, URL, 설명 반환 |
| 알려진 일반 웹페이지의 전체 콘텐츠 추출 |
디자인 계획, 레이아웃 분석, 구현 명세에는 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.jsonnpm run build
npm run lint
npm run smoke:gdweb-isolation
npm run web격리 스모크 테스트는 목 MCP 클라이언트를 연결하여 다음 동작을 검증합니다.
검색 결과 수는 샘플링 요청 수와 같습니다.
각 샘플링 요청에는 정확히 하나의 참조 ID가 포함됩니다.
다른 작품의 ID가 요청에 섞이지 않습니다.
모든 요청은 includeContext: none을 사용합니다.
모든 요청에는 GDWEB 이미지가 포함됩니다.
모든 결과는 별도의 Markdown 파일을 생성합니다.
제외된 작품은 이후 검색 결과나 샘플링 요청에 포함되지 않습니다.
명세 계약에는 페이지별, 내비게이션, 좌표, 색상 요구 사항이 포함됩니다.
실행 매니페스트 증거에는 타일 좌표와 측정된 팔레트가 기록됩니다.
이름 | 기본값 | 설명 |
|
| 생성된 문서가 저장되는 디렉터리 |
|
| MCP 결과에 포함되는 웹 뷰어 주소 |
|
| 웹 서버 바인드 주소 |
|
| 웹 서버 포트 |
|
| 개별 작업별 LLM 요청의 타임아웃(밀리초) |
|
| 일반 웹페이지에서 추출되는 본문의 최대 길이 |
|
| 일반 HTTP 및 브라우저 요청의 타임아웃 |
|
| 일반 추출에 사용되는 최대 브라우저 수 |
|
| 일반 검색 및 추출에 사용되는 브라우저 |
|
| Playwright가 헤드리스 모드로 실행되는지 여부 |
|
| 일반 검색 시 모든 엔진을 비교할지 여부 |
|
| 브라우저 수명 주기 로그를 출력할지 여부 |
Secret MCP는 멀티모달 UI 이해 및 스크린샷-투-코드 연구에 인접한 구현 산출물로 자리매김합니다. 아래 논문에서 사용된 데이터셋이나 지표로 아직 평가되지 않았으므로, 해당 논문의 결과를 Secret MCP의 결과로 해석해서는 안 됩니다.
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. 실제 환경의 스크린샷-코드 변환 평가와 시각적 및 요소 수준 지표를 소개합니다. 논문
Bryan Wang, Gang Li, Xin Zhou, Zhourong Chen, Tovi Grossman, and Yang Li. Screen2Words: Automatic Mobile UI Summarization with Multimodal Learning. UIST 2021. 스크린샷, 텍스트, 구조, UI 의미론을 결합한 표현을 연구합니다. 논문
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. 시각적으로 기반한 웹 에이전트 평가의 중요성과 난이도를 입증합니다. 논문
Model Context Protocol. Sampling specification. 클라이언트 매개 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}
}Search the web and fetch complete page content from top results. This is the most comprehensive web search tool. It searches the web and then follows the resulting links to extract their full page content, providing the most detailed and complete information available. Use get-web-search-summaries for a lightweight alternative.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return with full content (1-10) | |
| query | Yes | Search query to execute (recommended for comprehensive research) | |
| includeContent | No | Whether to fetch full page content (default: true) | |
| maxContentLength | No | Maximum characters per result content (0 = no limit). Usually not needed - content length is automatically optimized. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose a genuine behavioral trait: the tool performs a two-stage operation (search, then follow links to extract full page content), which tells the agent this is heavier than a plain search. However, it stops short of warning about the costs or failure modes of that behavior — latency, a slow underlying website, partial fetch successes, or content truncation — which an agent would benefit from knowing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each of which earns its place: the first defines the action, the second states the positioning and mechanism, and the third gives the explicit alternative routing. The content is dense yet minimal, with the most important facts appearing in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately simple 4-parameter tool with rich schema coverage, the description provides the essential facts and points to the correct alternative. The main missing piece is absence of an expected latency/failure profile for the full-page extraction step — coverage that would be especially useful given the 'fetches full content' behavior and the format of results is not specified. Still, what's missing is the optional, not-basic, information, and the definition is arguably strong enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (query, limit, includeContent, maxContentLength) is already documented at the schema level with sensible defaults. The description adds no meaningful information about parameters while also requiring none because the structured definitions do the heavy lifting. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: 'Search the web and fetch complete page content from top results.' It further clarifies its mechanism by explaining it 'follows the resulting links to extract their full page content,' which unambiguously distinguishes it from siblings like get-web-search-summaries and get-single-web-page-content. An agent can understand exactly what this tool does without opening any other definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes for the lightweight case: 'Use get-web-search-summaries for a lightweight alternative,' giving clear when-to-use guidance and naming the competing tool. It also positions itself as the right choice for comprehensive research. It does not, however, cover the case where a single known URL is already in hand and get-single-web-page-content should be used, so the exclusion guidance is slightly incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Automatically use this tool when the user asks to find GDWEB references and create layout analysis, frontend specifications, implementation plans, or DESIGN_INDEX files. This tool applies the dashboard-managed exclusion list, performs the GDWEB search internally, and sends one completely separate MCP sampling/createMessage request per non-excluded result. Each isolated request contains only one result and has no previous-result context. It writes one page-by-page, measurement-first DESIGN_INDEX_gdweb-.md file before starting the next request, then returns only file paths and statuses to the calling LLM. Never replace this tool with search-gdweb-designs plus a combined summary. The connected MCP client must support sampling.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Target award/registration year. Defaults to the current runtime year. | |
| limit | No | Number of isolated result requests and output documents (1-10) | |
| query | Yes | Natural-language design query to search directly on GDWEB | |
| language | No | Language for every generated document. Defaults to English; choose Korean for Korean output. | English |
| awardOnly | No | Whether to require a non-empty GDWEB award field | |
| maxTokens | No | Per-work output budget for a complete multi-page specification (131,072-262,144 tokens; default 131,072) | |
| outputDirectory | No | Directory for generated DESIGN_INDEX files. Defaults to DESIGN_INDEX_OUTPUT_DIR or ./design-index. | |
| includePreviousYear | No | Whether to include the previous year |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden and does so thoroughly. It reveals the internal exclusion list, the isolated per-result MCP sampling requests with no previous-result context, the file-writing sequence, the return format (only paths and statuses), and the client prerequisite of supporting sampling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded, opening with the trigger condition before moving to behavioral details. There is minor redundancy between 'one completely separate MCP sampling/createMessage request' and 'Each isolated request contains only one result,' but every sentence otherwise contributes non-obvious operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, eight parameters, no annotations, and no output schema, the description supplies the essential context: when to use it, how it executes, what it produces, what it returns, and what the client must support. An agent has enough information to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All eight parameters have schema descriptions at 100% coverage, so the schema already documents parameter meaning and defaults. The tool description adds workflow context but no additional parameter-level semantics, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a concrete verb-resource pair: it generates DESIGN_INDEX files from GDWEB references, and explicitly enumerates the deliverables (layout analysis, frontend specifications, implementation plans, DESIGN_INDEX files). It also differentiates the tool from search-gdweb-designs by stating it should never be replaced with that sibling plus a combined summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence gives an explicit automatic trigger condition: use whenever the user asks for GDWEB references with layout analysis, specifications, plans, or DESIGN_INDEX files. The last sentence provides a clear when-not rule naming the alternative, search-gdweb-designs plus a combined summary, which is exactly the routing an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and return the full content from a single web page URL. This tool follows a provided URL and extracts the main page content. Useful for getting detailed content from a specific webpage without performing a search.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the web page to extract content from | |
| maxContentLength | No | Maximum characters for the extracted content (0 = no limit, undefined = use default limit). Usually not needed - content length is automatically optimized. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'follows a provided URL and extracts the main page content,' but lacks details on failure modes, handling of pagination/dynamic content, rate limits, or response structure. This is a significant gap for a read tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the primary action and then immediately provides the use case. Every word earns its place, and it is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool, the description is adequate but not complete. It does not describe the return format, error handling, or edge cases (e.g., redirects, large pages). Without an output schema, this missing information is more noticeable, though the tool's simplicity mitigates the impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra clarification for 'maxContentLength' or 'url' beyond what the schema already provides, but this is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Extract and return the full content from a single web page URL') and distinguishes itself from search tools by noting it is 'without performing a search.' This effectively differentiates it from sibling tools like full-web-search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when you have a specific URL and want detailed content, as opposed to searching. However, it does not explicitly name alternatives or state when NOT to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web and return only the search result snippets/descriptions without following links to extract full page content. This is a lightweight alternative to full-web-search for when you only need brief search results. For comprehensive information, use full-web-search instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of search results to return (1-10) | |
| query | Yes | Search query to execute (lightweight alternative) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It clearly discloses that the tool only returns snippets and does not follow links, which is useful behavioral context. It could add details about rate limits or exact response shape, but the core behavior is transparent and non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core behavior, then immediately provides usage guidance and the alternative, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is complete: it explains what results look like (snippets/descriptions), when to choose it, and how it differs from the primary sibling. The schema covers parameter details, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both 'query' and 'limit' adequately. The description adds contextual framing ('lightweight alternative') but does not add new parameter-level semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search the web') and precise resource ('return only the search result snippets/descriptions'), clearly distinguishing it from full-web-search. It also names what it does not do: follow links to extract full page content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('lightweight alternative... when you only need brief search results') and when not to ('For comprehensive information, use full-web-search instead'). It directly names the main alternative, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this tool only when the user wants a lightweight list of GDWEB references. It applies the dashboard-managed exclusion list before returning results, returns metadata for multiple results, and does not generate implementation documents. For layout analysis, frontend specifications, DESIGN_INDEX files, or implementation planning, use generate-gdweb-design-indexes instead so every result is processed by a separate isolated LLM request.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Target award/registration year. Defaults to the current runtime year. | |
| limit | No | Number of GDWEB design results to return (1-10) | |
| query | Yes | Natural-language design reference query to search directly on GDWEB | |
| awardOnly | No | Whether to require a non-empty GDWEB award field. Defaults to true. | |
| includePreviousYear | No | Whether to include the previous year in addition to the target year. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool applies a dashboard-managed exclusion list, returns metadata for multiple results, and does not generate implementation documents. It does not describe response structure or any side effects, but the stated behaviors are meaningful for selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The usage condition is front-loaded, followed by behavioral boundaries and the alternative route. Every clause contributes selection or behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for tool selection and invocation: it explains purpose, usage boundary, exclusion behavior, and non-generation of implementation documents. Since there is no output schema, the exact metadata fields returned are left vague, but this is a minor gap for a lightweight search-list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all five parameters documented in the input schema. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: returning a lightweight list of GDWEB references with metadata, and explicitly contrasts itself with generate-gdweb-design-indexes. It clearly identifies what the tool does and how it differs from the most relevant sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description begins with 'Use this tool only when the user wants a lightweight list of GDWEB references,' giving an explicit trigger condition. It then names the alternative tool and the conditions under which that sibling should be used, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.6.0full-web-searchgenerate-gdweb-design-indexesget-single-web-page-contentget-web-search-summariessearch-gdweb-designsThe tools are largely distinct: full-web-search and get-web-search-summaries are explicit alternatives for comprehensive vs lightweight results, and get-single-web-page-content handles a specific URL without searching. The two GDWEB tools could be confused at first glance, but their descriptions strongly differentiate metadata listing from file generation.
Most tools follow a hyphenated verb-noun pattern (search-gdweb-designs, generate-gdweb-design-indexes, get-web-search-summaries, get-single-web-page-content). The exception is full-web-search, which uses an adjective-noun form rather than a verb, creating a minor inconsistency.
Five tools is a well-scoped set for a web search and GDWEB reference server. Each tool has a distinct role—comprehensive search, snippet search, single-page fetch, lightweight GDWEB listing, and GDWEB index generation—so none feel redundant.
The surface covers the core workflows: broad web search with two detail levels, direct page extraction, and the specialized GDWEB design-index generation pipeline. Minor gaps exist around managing the dashboard exclusion list or retrieving previously generated index files, but agents can work around these.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Focused full-screen UI references and hosted design materials for coding agents.
A design-style library for AI agents: search real styles, fetch a ready-to-apply design spec.
Curated design references for AI — real CSS values, typography specs, and color palettes.
Serves your design system and coding standards to coding agents, so they stop guessing.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yyeongjin/secret_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
