archi.den/den_archi_mcp · v1.2.4 · agents-and-memory
den — Korean AEC knowledge, curated is healthy: it completed an MCP handshake in 2169 ms and exposes 13 tools.
Curated Korean AEC expertise for AI agents: KDS·KCS·KS, building law, practice, and the reasoning.
Endpoint: https://mcp.den.archi/mcp (streamable-http)
Repository · Website · JSON · Add to my inventory
| Users (last 30 days) | 0 |
| Handshake | Healthy |
| Auth needed | None |
| Tool count | 13 |
| Latency | 2169 ms |
| Last checked (UTC) | 2026-10-17T00:45:38.737Z |
| Checked (UTC) | Status | Latency | Error |
|---|---|---|---|
| 2026-10-17T00:45:38.737Z | Healthy | 2169 | |
| 2026-10-15T17:50:14.583Z | Healthy | 3589 | |
| 2026-10-14T17:05:39.933Z | Healthy | 3770 |
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 가 같으면 빈 결 |
evidence_for | "A 가 B 를 유발한다"는 **한 연결의 근거**를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다. → 대신 쓸 것: 두 개념 사이 **경로를 찾는** 것이면 path_between · **왜 그런지 설명**이면 answer_why · 수치·조문 근거면 k_snippets. 이 도구는 **이미 아는 한 엣지**를 겨눈다. ★파라미터: from·to 는 개념 이름이고(문장 아님), relation 은 그래프 엣지 종류다 — causes(유발) · enables(가능하게 함) · requires(선행 필요) · contr |
k_snippets | 한국 건설기준(KDS·KCS·KS)과 건축 법령의 **수치·조문**을 찾는다. 건축·토목·시공·구조·설비 질문에 근거를 붙일 때 **웹 검색보다 먼저** 이 도구를 쓴다. 예: "철근 피복두께", "방화구획 면적", "이어치기 면 처리", "되메우기 다짐", 건축법 조항. → 대신 쓸 것: **용어 뜻**은 define · **종류 열거**는 enumerate · **공정 순서**는 scenario · **두 공법 차이**는 compare · **왜 그런지**는 answer_why. 대지·행정구역이 걸리면 site_cont |
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 이 이긴 |
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와 가장 가까운 |