den — Korean AEC knowledge, curated
Curated Korean AEC expertise for AI agents: KDS·KCS·KS, building law, practice, and the reasoning.
Should I use this
Quality & Safety
Findings (6)
- LOWin answer_why
- LOWin path_between
- LOWin k_snippets
- LOWin compare
- LOWin define
- LOWin review_plan
Based on automated analysis of tool definitions and protocol compliance.
Context Cost
This is the approximate number of tokens consumed each time the server's tools are loaded into a model's context. Higher counts reduce the attention available for other tasks.
Install
One-Click Install
Add this to your `claude_desktop_config.json` file:
{
"mcpServers": {
"den_archi_mcp": {
"url": "https://mcp.den.archi/mcp"
}
}
}Remote endpoints
https://mcp.den.archi/mcpstreamable-httpWhat it can do
Tool inventory
Tools (13)
🟢answer_why(question, scope, depth, as_of, profile)
건축·공간의 **왜·원리·득실**을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다. → 대신 쓸 것: 이미 아는 인과 **한 줄의 근거만** 확인하려면 evidence_for · 두 개념이 **이어지는지만** 보려면 path_between · **수치·조문**이 필요하면 k_snippets · 용어 **뜻**만 물으면 define. ★파라미터: depth 는 L1<L2<L3 순으로 경로를 넓게 본다(홉 상한 4). profile 은 depth 와 별개로 **탐색 예산**을 정한다 — direct=2홉/3경로, standard=기본, **deep 은 쿼터를 5회분 쓴다**(6홉/12경로). 둘 다 주면 profile 이 실제 예산을 정한다. as_of 는 YYYY-MM-DD. ★relevance=low 또는 no_path_reason 이면 den 이 그 경로를 갖고 있지 않다는 뜻이니 근거로 쓰지 않는다. 읽기 전용이고 외부를 부르지 않는다 — 적재된 정본만 본다.
Input Schema
{
"type": "object",
"properties": {
"question": {
"description": "Natural-language why question.",
"title": "Question",
"type": "string"
},
"scope": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional comma scope filter such as climate=arid,epoch=ancient.",
"title": "Scope"
},
"depth": {
"default": "L2",
"description": "L1, L2, or L3. Hops are hard-capped at 4.",
"title": "Depth",
"type": "string"
},
"as_of": {
"anyOf": [
{
"pattern": "^\\d{4}-\\d{2}-\\d{2}$",
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01",
"title": "As Of"
},
"profile": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard).",
"title": "Profile"
}
},
"required": [
"question"
],
"title": "answer_whyArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "answer_whyDictOutput"
}🟢path_between(a, b, scope, profile)
두 개념이 **어떻게 이어지는지** 확인한다. "단열과 결로는 어떻게 연결되나", "전단벽에서 층간변위까지"처럼 **출발·도착이 분명할 때** 쓴다. → 대신 쓸 것: 한 지점에서 **관계를 따라가며** 훑으려면 traverse · 공정 **전체 흐름**이면 scenario · **왜 그런지 설명**이 필요하면 answer_why · **한 연결의 근거**만이면 evidence_for. ★파라미터: a·b 는 문장이 아니라 **개념 이름/구**로 넣는다("결로" O, "왜 결로가 생기나" X). a 와 b 가 같으면 빈 결과다. scope 는 쉼표로 여러 축을 주면 **모두 만족**하는 경로만 남긴다 (climate=arid,epoch=ancient). **profile=deep 은 쿼터를 5회분 쓴다** — 먼저 기본으로 보고 빈손일 때만 올린다. ★경로가 없으면 만들어 내지 말고 연결이 확인되지 않는다고 말한다. 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"a": {
"description": "Start concept name or phrase.",
"title": "A",
"type": "string"
},
"b": {
"description": "End concept name or phrase.",
"title": "B",
"type": "string"
},
"scope": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional comma scope filter such as climate=arid,epoch=ancient.",
"title": "Scope"
},
"profile": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard).",
"title": "Profile"
}
},
"required": [
"a",
"b"
],
"title": "path_betweenArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "path_betweenDictOutput"
}🟢evidence_for(from, to, relation, as_of)
"A 가 B 를 유발한다"는 **한 연결의 근거**를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다. → 대신 쓸 것: 두 개념 사이 **경로를 찾는** 것이면 path_between · **왜 그런지 설명**이면 answer_why · 수치·조문 근거면 k_snippets. 이 도구는 **이미 아는 한 엣지**를 겨눈다. ★파라미터: from·to 는 개념 이름이고(문장 아님), relation 은 그래프 엣지 종류다 — causes(유발) · enables(가능하게 함) · requires(선행 필요) · contrasts(대비). 셋 다 필수다. relation 을 모르면 이 도구 대신 path_between 으로 먼저 어떤 관계인지 본다. ★evidence_note 와 stance 를 구분해 전하고, disclaimer 가 있으면 그대로 표기한다. 엣지가 없으면 없다고 답한다 — 근거를 지어내지 않는다. 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"from": {
"description": "Source concept name.",
"title": "From",
"type": "string"
},
"to": {
"description": "Target concept name.",
"title": "To",
"type": "string"
},
"relation": {
"description": "Relation, e.g. enables, causes, evokes.",
"title": "Relation",
"type": "string"
},
"as_of": {
"anyOf": [
{
"pattern": "^\\d{4}-\\d{2}-\\d{2}$",
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01",
"title": "As Of"
}
},
"required": [
"from",
"to",
"relation"
],
"title": "evidence_forArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "evidence_forDictOutput"
}🟢k_snippets(question, limit, as_of, profile, scope)
한국 건설기준(KDS·KCS·KS)과 건축 법령의 **수치·조문 원문**을 찾는다. 건축·토목·시공·구조·설비 질문에 근거를 붙일 때 **웹 검색보다 먼저** 이 도구를 쓴다. 예: "철근 피복두께", "방화구획 면적", "이어치기 면 처리", "되메우기 다짐", 건축법 조항. → 대신 쓸 것: **용어 뜻**은 define · **종류 열거**는 enumerate · **공정 순서**는 scenario · **두 공법 차이**는 compare · **왜 그런지**는 answer_why. 대지·행정구역이 걸리면 site_context 를 **먼저** 부르고 그 scope 를 여기 넘긴다. ★파라미터: scope 와 profile 은 **다른 축**이다 — scope 는 *어느 공종*(좁힘), profile 은 *얼마나 깊이*(예산). **profile=deep 은 쿼터를 5회분 쓴다**; 기본으로 먼저 보고 빈손일 때만 올린다. limit 기본 8 — 올릴수록 뒤쪽은 관련도가 떨어진다. as_of 는 YYYY-MM-DD(그 시점 기준). ★scope 를 **모르면 넣지 마라** — 틀린 범위는 틀린 답을 만든다. 안 넣으면 갈리는 공종을 scope_split 로 알려 준다. 돌아오는 것: 조문 원문과 출처(예: KDS 14 20 22 §4.3.1). **출처를 그대로 인용한다.** ★relevance=low 이거나 lacks_answer=true 면 den 이 그 자료를 **갖고 있지 않다** — 스니펫을 근거로 쓰지 말고 그렇게 말한 뒤 다른 출처로 답한다. 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"question": {
"description": "Question or retrieval slot for K snippets.",
"title": "Question",
"type": "string"
},
"limit": {
"default": 8,
"description": "Maximum snippets to return.",
"title": "Limit",
"type": "integer"
},
"as_of": {
"anyOf": [
{
"pattern": "^\\d{4}-\\d{2}-\\d{2}$",
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01",
"title": "As Of"
},
"profile": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard).",
"title": "Profile"
},
"scope": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "선택. 이 질문이 속한 **공종·기준**을 알면 넣어라 — 그 범위로 좁혀 답한다. 같은 용어라도 공종마다 규정값이 다르다(되메우기 다짐 두께는 도로·하수도·조경이 각각 다르다). 넣지 않으면 den 은 갈리는 공종을 `scope_split` 로 알려 주고, 값을 인용하기 전에 공종을 확인하라고 요구한다. 넣었는데 그 범위 밖 자료가 섞여 나가면 `scope_partial` 로, 하나도 없으면 `scope_absent` 로 알려 준다 — den 은 범위 밖 자료를 버리지 않고 **고지**한다. 형식: 공종 이름('도로'·'하수도'·'건축') 또는 기준코드('KCS 44'·'KDS 14 20 50'). ★모르면 넣지 마라 — 틀린 범위는 틀린 답을 만든다.",
"title": "Scope"
}
},
"required": [
"question"
],
"title": "k_snippetsArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "k_snippetsDictOutput"
}🟢scenario(query, max_nodes)
공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 **시퀀스·시나리오** 요청에 호출하라. → 대신 쓸 것: 단순 사실·수치는 k_snippets · **두 지점 사이**만 궁금하면 path_between · 한 노드의 **선후 이웃**만이면 traverse · 두 공법 **차이**는 compare. ★파라미터: max_nodes 는 **5~60 으로 잘린다**(기본 40). 올리면 넓게 모으지만 느슨한 노드가 섞여 ordering_coverage 가 떨어질 수 있다 — 먼저 기본으로 보고 gaps 를 본 뒤 올린다. 결정론(LLM 없음). ordering_coverage 가 낮거나 gaps 가 있으면 그래프에 순서 지식이 아직 없다는 정직한 신호 — 그 구간은 지어내지 말고 gaps 그대로 사용자에게 전하라. 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"query": {
"description": "공정/시퀀스 질의 (예: 철근콘크리트 골조 시공 순서).",
"title": "Query",
"type": "string"
},
"max_nodes": {
"default": 40,
"description": "수집할 공정 노드 상한.",
"title": "Max Nodes",
"type": "integer"
}
},
"required": [
"query"
],
"title": "scenarioArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "scenarioDictOutput"
}🟢compare(a, b)
두 공법·개념의 **차이**를 대조한다 — 'RC 구조 vs 조적조 시공순서 차이', '스틱 vs 유닛 커튼월' 같은 **비교/차이** 요청에 호출하라. → 대신 쓸 것: 단일 순서는 scenario · 종류 열거는 enumerate · 용어 뜻은 define · 수치·조문은 k_snippets. ★파라미터: a·b 는 **개념/공법 이름**이다(질문 문장 아님). 'A vs B' 를 a 에 한 번에 주면 b 를 비운다 — 그때 구분자는 vs 다. 한쪽만 주고 b 를 비우면 비교할 짝이 없어 얻을 것이 없다. 각각을 결정론 구성해 A/B 시퀀스, A에만/B에만 있는 단계, 공유 단계, contrasts 엣지를 반환한다. LLM 없음. a_coverage/b_coverage 가 낮으면 그쪽 지식이 얇다는 정직한 신호 — 지어내지 말고 gaps 그대로 전하라. 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"a": {
"description": "첫째 공법/개념 (예: RC 골조 시공). 'A vs B'를 a에 한 번에 줘도 됨.",
"title": "A",
"type": "string"
},
"b": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "둘째 공법/개념 (예: 철골 시공). a에 vs가 있으면 생략 가능.",
"title": "B"
}
},
"required": [
"a"
],
"title": "compareArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "compareDictOutput"
}🟢enumerate(query)
어떤 것의 **종류·구성요소·분류**를 완전 열거한다 — '건축물 하중의 종류', '구조용 강종 체계', '건축 도면의 종류' 같은 **'X의 종류/체계'** 요청에 호출하라. → 대신 쓸 것: 순서는 scenario · 비교는 compare · **한 용어의 뜻**은 define · 수치·조문은 k_snippets. ★파라미터: query 는 'X의 종류/체계/구성요소' 꼴로 준다. 낱말 하나만 주면(예: '하중') 무엇을 열거할지 정해지지 않아 match 가 안 잡힐 수 있다. 권위표준 기반 큐레이션 분류학으로 완전한 멤버 목록을 반환하고, 각 멤버 정의는 그래프에서 당긴다. 결정론. match=None 이면 미큐레이션 주제 — k_snippets 로 폴백. gaps 는 멤버 정의가 아직 그래프에 없다는 정직한 신호(지어내지 말고 그대로 전하라). 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"query": {
"description": "'X의 종류/체계/구성요소' 질의 (예: 건축물 하중의 종류).",
"title": "Query",
"type": "string"
}
},
"required": [
"query"
],
"title": "enumerateArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "enumerateDictOutput"
}🟢define(term, limit, as_of)
건축·건설 **용어 하나의 뜻**을 돌려준다 — '이형철근이 뭔가', '방화구획이란', '옹벽과 흙막이의 정의' 같은 **'X가 무엇인가'** 질문에 호출하라. → 대신 쓸 것: **수치·조문 원문**이 필요하면 k_snippets · **종류/체계 열거**는 enumerate · **왜 그런지**는 answer_why · **두 개념 차이**는 compare · 두 개념이 **어떻게 이어지는지**는 path_between. 이 도구는 정의 한 덩어리만 준다 — 기준값은 주지 않는다. ★파라미터: term 은 **용어 하나**로 넣는다(질문 문장이나 여러 용어 나열이 아니다). limit 는 동음이의로 갈릴 때 몇 개까지 볼지이고 1~5 로 잘린다(기본 3). as_of 는 YYYY-MM-DD. ★abstained=true 이면 den 이 그 용어의 정의를 **갖고 있지 않다**는 뜻이다 — 비슷한 말을 지어내지 말고 그대로 전한 뒤 다른 출처로 답한다. exact=false 는 정확한 이름 일치가 아니라는 표시이니 이름이 맞는지 확인하고 쓴다. 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"term": {
"description": "정의를 물을 용어 하나 (예: 이형철근).",
"title": "Term",
"type": "string"
},
"limit": {
"default": 3,
"description": "동음이의로 갈릴 때 볼 후보 수 (1~5).",
"title": "Limit",
"type": "integer"
},
"as_of": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01",
"title": "As Of"
}
},
"required": [
"term"
],
"title": "defineArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "defineDictOutput"
}🟢traverse(start, relation, direction, depth, limit)
**시공 순서와 선후 관계**를 따라간다 — '무엇이 무엇보다 먼저 와야 하는가'. '기초부터 골조까지 순서', '거푸집 해체 전에 확인할 것' 같은 공정 질문에 쓴다. → 대신 쓸 것: 출발·도착 **두 지점이 분명하면** path_between · 공정 **전체 흐름**을 한 번에 구성하려면 scenario · 두 공법 **차이**는 compare · 단순 수치·조문은 k_snippets. ★파라미터: relation=requires 는 **선행 조건**(이것보다 먼저 와야 하는 것), enables 는 **후속 가능 작업**, causes 는 인과, contrasts 는 대비다. 생략하면 전부 본다. direction=out 은 정방향(다음), in 은 역방향(이전) — 'X 전에 무엇을' 은 in 이다. depth 는 **1~4 로 잘린다**(넘겨도 4). limit 는 최대 스텝 수이고 depth 와 곱해 커진다. 빈 결과는 den 이 그 순서를 아직 갖고 있지 않다는 뜻이다 — 순서를 지어내지 않는다. 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"start": {
"description": "시작 개념 이름/구문 (예: 거푸집).",
"title": "Start",
"type": "string"
},
"relation": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "순회할 관계 (requires/enables/causes/contrasts 등). 생략 시 전체.",
"title": "Relation"
},
"direction": {
"default": "out",
"description": "out(정방향) 또는 in(역방향).",
"title": "Direction",
"type": "string"
},
"depth": {
"default": 2,
"description": "순회 홉 수 (1~4).",
"title": "Depth",
"type": "integer"
},
"limit": {
"default": 40,
"description": "최대 스텝 수.",
"title": "Limit",
"type": "integer"
}
},
"required": [
"start"
],
"title": "traverseArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "traverseDictOutput"
}🟢site_context(region, lat, lng)
지명·좌표를 **기후·문화·관할** 조건으로 바꾼다. 대지·지역·행정구역·위경도가 언급되면 다른 도구보다 **먼저** 부른다. → 그다음: 돌아온 scope 를 k_snippets·answer_why 에, jurisdiction 을 review_plan 에 넘긴다. 이 도구 자체는 기준·수치를 주지 않는다 — 수치는 k_snippets, 도면 검토는 review_plan. ★파라미터: region 을 **먼저** 본다. lat/lng 는 region 이 없거나 못 찾을 때의 대체 경로다 — 둘 다 주면 region 이 이긴다. region 은 등재된 지명·별칭에 맞아야 한다("부산 수영구" O). 셋 다 비우면 아무것도 못 정하고 relevance=low 로 돌려준다. ★행정구역이 확인되지 않은 좌표 결과는 **추정**이라고 밝힌다. 읽기 전용 · **외부 지오코딩을 부르지 않는다**(적재된 지명표만 본다).
Input Schema
{
"type": "object",
"properties": {
"region": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Place name such as \"부산 수영구\" or \"Dubai\".",
"title": "Region"
},
"lat": {
"anyOf": [
{
"type": "number"
},
{
"type": "null"
}
],
"default": null,
"description": "Latitude for coordinate fallback.",
"title": "Lat"
},
"lng": {
"anyOf": [
{
"type": "number"
},
{
"type": "null"
}
],
"default": null,
"description": "Longitude for coordinate fallback.",
"title": "Lng"
}
},
"title": "site_contextArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "site_contextDictOutput"
}🟢emotional_palette(spaces, target)
공간을 순서대로 지날 때의 **분위기 전이**를 읽는다. "진입에서 거실까지 감정 흐름", "압축에서 해방"처럼 이동 순서와 체험 목표가 있을 때 쓴다. → 대신 쓸 것: 작품 평가나 "왜 걸작인가" 같은 **이유**는 answer_why · 법규 관점 평면 검토는 review_plan · 공정 순서는 scenario. 이 도구는 **체험 순서**만 다룬다. ★파라미터: spaces 는 **실제 이동 순서**로 넣는다 — 배열 순서가 곧 동선이고, 순서를 바꾸면 결과가 바뀐다. 하나만 넣으면 전이가 없어 얻을 것이 없다(둘 이상). target 은 선택이고, 넣으면 그 목표에 대한 정합/괴리를 같이 본다. 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"spaces": {
"description": "Ordered spaces such as [\"좁은 진입로\", \"낮은 천장 복도\", \"높은 거실\"].",
"items": {
"type": "string"
},
"title": "Spaces",
"type": "array"
},
"target": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional affective target such as \"환대와 개방감\".",
"title": "Target"
}
},
"required": [
"spaces"
],
"title": "emotional_paletteArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "emotional_paletteDictOutput"
}🟢review_plan(rooms, adjacency, openings, circulation, jurisdiction, ...)
평면도·배치도를 **건축 법규 관점에서 검토**한다 — 채광·환기·피난·면적 요건 위반을 짚는다. 사용자가 도면을 공유하거나 공간 구성 검토를 요청하면 이 도구를 쓴다. → 대신 쓸 것: 특정 **수치·조문 하나**의 근거면 k_snippets · **왜 그 요건인지**는 answer_why · 체험·분위기 관점이면 emotional_palette. 대지의 관할이 걸리면 site_context 를 **먼저** 부르고 그 jurisdiction 을 여기에 넘긴다. ★입력: 이미지가 아니라 **도면에서 읽어낸 구조**를 넣는다 — 방(용도·외부창 유무)·인접·개구부·동선. rooms 만 필수이고 나머지는 선택인데, **빠뜨린 만큼 검토가 좁아진다**(adjacency 가 없으면 인접 요건을, circulation 이 없으면 피난 동선을 못 본다). 검토 못 한 축은 결과에 그대로 밝힌다. jurisdiction 은 KR-서울 꼴이고, 주면 그 관할 조문까지 본다 — 없으면 국가법령 층까지만 본다. 위반(violation) 항목은 답변에서 빼지 않는다. 읽기 전용 · 외부 호출 없음.
Input Schema
{
"type": "object",
"properties": {
"rooms": {
"description": "Parsed rooms with id, use, ext_windows, optional area/floor/access/shape.",
"items": {
"additionalProperties": true,
"type": "object"
},
"title": "Rooms",
"type": "array"
},
"adjacency": {
"anyOf": [
{
"items": {},
"type": "array"
},
{
"type": "null"
}
],
"default": null,
"description": "Room adjacency pairs such as [[a,b]] or objects with from/to.",
"title": "Adjacency"
},
"openings": {
"anyOf": [
{
"items": {},
"type": "array"
},
{
"type": "null"
}
],
"default": null,
"description": "Openings, including exterior windows and doors, as parsed objects or pairs.",
"title": "Openings"
},
"circulation": {
"anyOf": [
{
"items": {},
"type": "array"
},
{
"type": "null"
}
],
"default": null,
"description": "Circulation edges or ordered paths, e.g. [[from,to]] or [a,b,c].",
"title": "Circulation"
},
"jurisdiction": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional jurisdiction key such as KR-서울 for NormClause lookup.",
"title": "Jurisdiction"
},
"site_scope": {
"anyOf": [
{
"additionalProperties": true,
"type": "object"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional site scope such as climate/culture/epoch/tech_level.",
"title": "Site Scope"
}
},
"required": [
"rooms"
],
"title": "review_planArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "review_planDictOutput"
}🟢feedback(satisfied, query_id, question_text, issue_type, comment)
사용자가 직접 입력하는 폼이 아니라, 호출 에이전트가 직전 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 면 **무엇을 채택했는지** 한 줄은 항상 적는다(어느 값·조문·판단을 그대로 썼는가). 비워 두는 것은 반사실 한 마디뿐이다 — 요지까지 비면 그 만족은 기록에 남아도 쓸 수 없다. → 이 도구는 **질의가 아니다** — 답을 찾으려면 k_snippets·answer_why 를 쓴다. 사용자 대화 원문은 전송하지 않는다. 만족/불만족과 사유는 다음 날 그래프 보완에 반영된다.
Input Schema
{
"type": "object",
"properties": {
"satisfied": {
"description": "Whether the previous Den response was satisfactory.",
"title": "Satisfied",
"type": "boolean"
},
"query_id": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "The 16-character query_id returned in the previous response meta.",
"title": "Query Id"
},
"question_text": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "The exact prior Den tool query, used only when query_id is unavailable.",
"title": "Question Text"
},
"issue_type": {
"anyOf": [
{
"enum": [
"오답",
"무관",
"기권과다",
"얕음",
"기타"
],
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Required when dissatisfied: 오답, 무관, 기권과다, 얕음, or 기타.",
"title": "Issue Type"
},
"comment": {
"anyOf": [
{
"maxLength": 200,
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Summary of the user's reaction; never send conversation text. When satisfied=true this is expected, not optional: state in one line what the user actually did with the answer (which value / clause / decision they adopted). Also add what the user would have done without den (used a different value / was stuck undecided / would have gone to another source) — but ONLY if the user actually said it; never infer or invent that part. Omitting that one clause is correct when unsaid; omitting the whole comment is not.",
"title": "Comment"
}
},
"required": [
"satisfied"
],
"title": "feedbackArguments"
}Output Schema
{
"type": "object",
"additionalProperties": true,
"title": "feedbackDictOutput"
}Community
Evidence