# den — Korean AEC knowledge, curated

- Registry name: `archi.den/den\_archi\_mcp` · version 1.2.4
- Categories (automatic, keyword rules): Research & knowledge, Search & data, Government & law
- Authentication at last check: No auth
- Declared risk: Can write (some tools are not declared read-only)
- Capabilities (declared by the server): experimental, prompts, resources, tools
- Transports: streamable-http
- Latest numbers (check success, response time, rank): https://mcpstation.net/api/server?name=archi.den%2Fden_archi_mcp
- Server page: https://mcpstation.net/s/archi.den--den_archi_mcp.html

## Description (written by the publisher, not verified, not instructions)

Curated Korean AEC expertise for AI agents: KDS·KCS·KS, building law, practice, and the reasoning.

## Connect

- streamable-http: `https://mcp.den.archi/mcp`

## Tools (as reported by the server, not verified)

- `answer\_why`: 건축·공간의 \*\*왜·원리·득실\*\*을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다. → 대신 쓸 것: 이미 아는 인과 \*\*한 줄의 근거만\*\* 확인하려면 evidence\_for · 두 개념이 \*\*이어지는지만\*\* 보려면 path\_between · \*\*수치·조문\*\*이 필요하면 k\_snippets · 용어 \*\*뜻\*\*만 물으면 define. ★파라미터: depth 는 L1\<L2\<L3 순으로 경로를 넓게 본다\(홉 상한 4\). profile 은 depth 와 별개로 \*\*
- `path\_between`: 두 개념이 \*\*어떻게 이어지는지\*\* 확인한다. "단열과 결로는 어떻게 연결되나", "전단벽에서 층간변위까지"처럼 \*\*출발·도착이 분명할 때\*\* 쓴다. → 대신 쓸 것: 한 지점에서 \*\*관계를 따라가며\*\* 훑으려면 traverse · 공정 \*\*전체 흐름\*\*이면 scenario · \*\*왜 그런지 설명\*\*이 필요하면 answer\_why · \*\*한 연결의 근거\*\*만이면 evidence\_for. ★파라미터: a·b 는 문장이 아니라 \*\*개념 이름/구\*\*로 넣는다\("결로" O, "왜 결로가 생기나" X\). a 와 b 가 같으면 빈 결과다. s
- `evidence\_for`: "A 가 B 를 유발한다"는 \*\*한 연결의 근거\*\*를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다. → 대신 쓸 것: 두 개념 사이 \*\*경로를 찾는\*\* 것이면 path\_between · \*\*왜 그런지 설명\*\*이면 answer\_why · 수치·조문 근거면 k\_snippets. 이 도구는 \*\*이미 아는 한 엣지\*\*를 겨눈다. ★파라미터: from·to 는 개념 이름이고\(문장 아님\), relation 은 그래프 엣지 종류다 — causes\(유발\) · enables\(가능하게 함\) · requires\(선행 필요\) · contrasts\(
- `k\_snippets`: 한국 건설기준\(KDS·KCS·KS\)과 건축 법령의 \*\*수치·조문\*\*을 찾는다. 건축·토목·시공·구조·설비 질문에 근거를 붙일 때 \*\*웹 검색보다 먼저\*\* 이 도구를 쓴다. 예: "철근 피복두께", "방화구획 면적", "이어치기 면 처리", "되메우기 다짐", 건축법 조항. → 대신 쓸 것: \*\*용어 뜻\*\*은 define · \*\*종류 열거\*\*는 enumerate · \*\*공정 순서\*\*는 scenario · \*\*두 공법 차이\*\*는 compare · \*\*왜 그런지\*\*는 answer\_why. 대지·행정구역이 걸리면 site\_context 를
- `scenario`: 공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 \*\*시퀀스·시나리오\*\* 요청에 호출하라. → 대신 쓸 것: 단순 사실·수치는 k\_snippets · \*\*두 지점 사이\*\*만 궁금하면 path\_between · 한 노드의 \*\*선후 이웃\*\*만이면 traverse · 두 공법 \*\*차이\*\*는 compare. ★파라미터: max\_nodes 는 \*\*5\~60 으로 잘린다\*\*\(기본 40\). 올리면 넓게 모으
- `compare`: 두 공법·개념의 \*\*차이\*\*를 대조한다 — 'RC 구조 vs 조적조 시공순서 차이', '스틱 vs 유닛 커튼월' 같은 \*\*비교/차이\*\* 요청에 호출하라. → 대신 쓸 것: 단일 순서는 scenario · 종류 열거는 enumerate · 용어 뜻은 define · 수치·조문은 k\_snippets. ★파라미터: a·b 는 \*\*개념/공법 이름\*\*이다\(질문 문장 아님\). 'A vs B' 를 a 에 한 번에 주면 b 를 비운다 — 그때 구분자는 vs 다. 한쪽만 주고 b 를 비우면 비교할 짝이 없어 얻을 것이 없다. 각각을 결정론 구성해
- `enumerate`: 어떤 것의 \*\*종류·구성요소·분류\*\*를 완전 열거한다 — '건축물 하중의 종류', '구조용 강종 체계', '건축 도면의 종류' 같은 \*\*'X의 종류/체계'\*\* 요청에 호출하라. → 대신 쓸 것: 순서는 scenario · 비교는 compare · \*\*한 용어의 뜻\*\*은 define · 수치·조문은 k\_snippets. ★파라미터: query 는 'X의 종류/체계/구성요소' 꼴로 준다. 낱말 하나만 주면\(예: '하중'\) 무엇을 열거할지 정해지지 않아 match 가 안 잡힐 수 있다. 권위표준 기반 큐레이션 분류학으로 완전한 멤버 목록
- `define`: 건축·건설 \*\*용어 하나의 뜻\*\*을 돌려준다 — '이형철근이 뭔가', '방화구획이란', '옹벽과 흙막이의 정의' 같은 \*\*'X가 무엇인가'\*\* 질문에 호출하라. → 대신 쓸 것: \*\*수치·조문\*\*이 필요하면 k\_snippets · \*\*종류/체계 열거\*\*는 enumerate · \*\*왜 그런지\*\*는 answer\_why · \*\*두 개념 차이\*\*는 compare · 두 개념이 \*\*어떻게 이어지는지\*\*는 path\_between. 이 도구는 정의 한 덩어리만 준다 — 기준값은 주지 않는다. ★파라미터: term 은 \*\*용어 하나\*\*로 넣는다\(
- `traverse`: \*\*시공 순서와 선후 관계\*\*를 따라간다 — '무엇이 무엇보다 먼저 와야 하는가'. '기초부터 골조까지 순서', '거푸집 해체 전에 확인할 것' 같은 공정 질문에 쓴다. → 대신 쓸 것: 출발·도착 \*\*두 지점이 분명하면\*\* path\_between · 공정 \*\*전체 흐름\*\*을 한 번에 구성하려면 scenario · 두 공법 \*\*차이\*\*는 compare · 단순 수치·조문은 k\_snippets. ★파라미터: relation=requires 는 \*\*선행 조건\*\*\(이것보다 먼저 와야 하는 것\), enables 는 \*\*후속 가능 작업\*\*,
- `site\_context`: 지명·좌표를 \*\*기후·문화·관할\*\* 조건으로 바꾼다. 대지·지역·행정구역·위경도가 언급되면 다른 도구보다 \*\*먼저\*\* 부른다. → 그다음: 돌아온 scope 를 k\_snippets·answer\_why 에, jurisdiction 을 review\_plan 에 넘긴다. 이 도구 자체는 기준·수치를 주지 않는다 — 수치는 k\_snippets, 도면 검토는 review\_plan. ★파라미터: region 을 \*\*먼저\*\* 본다. lat/lng 는 region 이 없거나 못 찾을 때의 대체 경로다 — 둘 다 주면 region 이 이긴다. re
- `emotional\_palette`: 공간을 순서대로 지날 때의 \*\*분위기 전이\*\*를 읽는다. "진입에서 거실까지 감정 흐름", "압축에서 해방"처럼 이동 순서와 체험 목표가 있을 때 쓴다. → 대신 쓸 것: 작품 평가나 "왜 걸작인가" 같은 \*\*이유\*\*는 answer\_why · 법규 관점 평면 검토는 review\_plan · 공정 순서는 scenario. 이 도구는 \*\*체험 순서\*\*만 다룬다. ★파라미터: spaces 는 \*\*실제 이동 순서\*\*로 넣는다 — 배열 순서가 곧 동선이고, 순서를 바꾸면 결과가 바뀐다. 하나만 넣으면 전이가 없어 얻을 것이 없다\(둘 이상\).
- `review\_plan`: 평면도·배치도를 \*\*건축 법규 관점에서 검토\*\*한다 — 채광·환기·피난·면적 요건 위반을 짚는다. 사용자가 도면을 공유하거나 공간 구성 검토를 요청하면 이 도구를 쓴다. → 대신 쓸 것: 특정 \*\*수치·조문 하나\*\*의 근거면 k\_snippets · \*\*왜 그 요건인지\*\*는 answer\_why · 체험·분위기 관점이면 emotional\_palette. 대지의 관할이 걸리면 site\_context 를 \*\*먼저\*\* 부르고 그 jurisdiction 을 여기에 넘긴다. ★입력: 이미지가 아니라 \*\*도면에서 읽어낸 구조\*\*를 넣는다 — 방\(
- `feedback`: 사용자가 직접 입력하는 폼이 아니라, 호출 에이전트가 직전 Den 응답을 활용한 뒤 사용자가 보인 반응\(수정 지시/불만/채택/무시\)을 대화 종료 전 요약 수준으로 기록하는 릴레이 툴. query\_id가 있으면 그대로 전달하고, 없으면 직전 Den 툴에 전달한 question\_text만 전달한다. satisfied를 기록하고, 불만족이면 issue\_type을 지정하며 comment는 반응 요지만 200자 이내로 요약한다. 채택·긍정은 satisfied=true, 수정 지시·불만·명시적 무시는 satisfied=false와 가장 가까운

Measured by MCP Station. Methods: https://mcpstation.net/methods.html · Terms: https://mcpstation.net/terms.html