archi.den/den_archi_mcp

Tools

• answer_why

  건축·공간의 **왜·원리·득실**을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다. 수치·조문이 필요하면 k_snippets 를 함께 부른다. relevance=low 또는 no_path_reason 이면 den 이 그 경로를 갖고 있지 않다는 뜻이니 근거로 쓰지 않는다.

  shallow
• compare

  두 공법·개념의 **차이**를 대조한다 — 'RC 구조 vs 조적조 시공순서 차이', '스틱 vs 유닛 커튼월' 같은 **비교/차이** 요청에 호출하라(단일 순서는 scenario). 각각을 결정론 구성해 A/B 시퀀스, A에만/B에만 있는 단계, 공유 단계, contrasts 엣지를 반환한다. LLM 없음. a_coverage/b_coverage가 낮으면 그쪽 지식이 얇다는 정직한 신호 — 지어내지 말고 gaps 그대로 전하라.

  shallow
• emotional_palette

  공간을 순서대로 지날 때의 **분위기 전이**를 읽는다. "진입에서 거실까지 감정 흐름", "압축에서 해방" 처럼 이동 순서와 체험 목표가 있을 때 쓴다. spaces 는 실제 이동 순서로 넣는다. 작품 평가("왜 걸작인가")에는 쓰지 않는다.

  shallow
• enumerate

  어떤 것의 **종류·구성요소·분류**를 완전 열거한다 — '건축물 하중의 종류', '구조용 강종 체계', '건축 도면의 종류' 같은 **'X의 종류/체계'** 요청에 호출하라(순서는 scenario, 비교는 compare). 권위표준 기반 큐레이션 분류학으로 완전한 멤버 목록을 반환하고, 각 멤버 정의는 그래프에서 당긴다. 결정론. match=None이면 미큐레이션 주제 — k_snippets로 폴백. gaps는 멤버 정의가 아직 그래프에 없다는 정직한 신호(지어내지 말고 그대로 전하라).

  shallow
• evidence_for

  "A 가 B 를 유발한다"는 **한 연결의 근거**를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다. from·to 는 개념명, relation 은 causes/enables/requires 등. evidence_note 와 stance 를 구분해 전하고, disclaimer 가 있으면 그대로 표기한다.

  shallow
• feedback

  사용자가 직접 입력하는 폼이 아니라, 호출 에이전트가 직전 Den 응답을 활용한 뒤 사용자가 보인 반응(수정 지시/불만/채택/무시)을 대화 종료 전 요약 수준으로 기록하는 릴레이 툴. query_id가 있으면 그대로 전달하고, 없으면 직전 Den 툴에 전달한 question_text만 전달한다. satisfied를 기록하고, 불만족이면 issue_type을 지정하며 comment는 반응 요지만 200자 이내로 요약한다. 채택·긍정은 satisfied=true, 수정 지시·불만·명시적 무시는 satisfied=false와 가장 가까운 issue_type으로 매핑한다. 관찰 가능한 반응이 전혀 없으면 만족 여부를 추측하지 않는다. ★satisfied=true(채택·긍정)이면 comment 에 **den 이 없었으면 무엇을 하려 했는지** 한 마디를 함께 적는다 — "다른 값을 쓰려 했다" · "몰라서 정하지 못하고 있었다" · "다른 출처로 갔어야 했다" 중 사용자가 실제로 말한 것. 이 한 마디만이 'den 을 썼다'와 'den 때문에 달라졌다'를 가른다. ★★사용자가 말하지 않았으면 **비워 둔다.** 추측해 지어내지 않는다 — 없는 것을 적는 편이 안 적는 것보다 나쁘다. ★★★그렇다고 comment 를 통째로 생략하지는 않는다. satisfied=true 면 **무엇을 채택했는지** 한 줄은 항상 적는다(어느 값·조문·판단을 그대로 썼는가). 비워 두는 것은 반사실 한 마디뿐이다 — 요지까지 비면 그 만족은 기록에 남아도 쓸 수 없다. 사용자 대화 원문은 전송하지 않는다. 만족/불만족과 사유는 다음 날 그래프 보완에 반영된다.

  shallow
• k_snippets

  한국 건설기준(KDS·KCS·KS)과 건축 법령의 **수치·조문 원문**을 찾는다. 건축·토목·시공·구조·설비 질문에 근거를 붙일 때 **웹 검색보다 먼저** 이 도구를 쓴다. 이럴 때 부른다: · 수치 기준 — "철근 피복두께", "콘크리트 압축강도 시험 재령", "방화구획 면적", "계단 챌판 높이" · 조문·법령 — 건축법·시행령·시행규칙, 국가건설기준 조항 · 시공 방법 — "이어치기 면 처리", "되메우기 다짐", "방수층 시공 순서" · 설계 요건 — 하중·내진·단열·피난·주차 기준 돌아오는 것: 조문 원문과 출처(예: KDS 14 20 22 §4.3.1). **출처를 그대로 인용한다.** ★relevance=low 이거나 lacks_answer=true 면 den 이 그 자료를 **갖고 있지 않다**는 뜻이다. 스니펫을 근거로 쓰지 말고 "den 이 이 부분은 보유하지 않는다"고 말한 뒤 다른 출처로 답한다. (자료가 없는데 있는 척하는 것이 틀린 답보다 나쁘다.) as_of 로 과거 시점 기준을 조회한다. 예: as_of=2020-06-01

  shallow
• path_between

  두 개념이 **어떻게 이어지는지** 확인한다. "단열과 결로는 어떻게 연결되나", "전단벽에서 층간변위까지"처럼 출발·도착이 분명할 때 쓴다. 경로가 없으면 만들어 내지 말고 연결이 확인되지 않는다고 말한다.

  shallow
• review_plan

  평면도·배치도를 **건축 법규 관점에서 검토**한다 — 채광·환기·피난·면적 요건 위반을 짚는다. 사용자가 도면을 공유하거나 공간 구성 검토를 요청하면 이 도구를 쓴다. 이미지가 아니라 **도면에서 읽어낸 구조**를 넣는다: 방(용도·외부창 유무)·인접·개구부·동선. 위반(violation) 항목은 답변에서 빼지 않는다.

  shallow
• scenario

  공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 **시퀀스·시나리오** 요청에 호출하라(단순 사실은 k_snippets). 결정론. ordering_coverage가 낮거나 gaps가 있으면 그래프에 순서 지식이 아직 없다는 정직한 신호 — 그 구간은 지어내지 말고 gaps 그대로 사용자에게 전하라.

  shallow
• site_context

  지명·좌표를 **기후·문화·관할** 조건으로 바꾼다. 대지·지역·행정구역·위경도가 언급되면 다른 도구보다 **먼저** 부르고, 돌아온 scope 와 jurisdiction 을 뒤따르는 질의에 넘긴다. 행정구역이 확인되지 않은 좌표 결과는 추정이라고 밝힌다.

  shallow
• traverse

  **시공 순서와 선후 관계**를 따라간다 — '무엇이 무엇보다 먼저 와야 하는가'. '기초부터 골조까지 순서', '거푸집 해체 전에 확인할 것' 같은 공정 질문에 쓴다. relation=requires 는 선행 조건, enables 는 후속 가능 작업이다. 빈 결과는 den 이 그 순서를 아직 갖고 있지 않다는 뜻이다 — 순서를 지어내지 않는다.

  shallow

Embed this server’s score

Tool count and median score across every tool in this server’s corpus — honest in a way a single cherry-picked tool’s badge wouldn’t be.

[![Vouch score](https://vouch.tools/api/servers/c721a5bd-a88a-44a0-a55d-3a9327cc3a81/badge.svg)](https://vouch.tools/servers/c721a5bd-a88a-44a0-a55d-3a9327cc3a81)