Curated Korean AEC expertise for AI agents: KDS·KCS·KS, building law, practice, and the reasoning.
Scored across 13 tools
Each tool carries explicit routing hints ('→ 대신 쓸 것') that sharply delimit its purpose, and the intent verbs (why vs define vs enumerate vs compare) are genuinely distinct. However, five tools (answer_why, evidence_for, path_between, traverse, scenario) all operate over the same causal/ordering graph with only subtly different scopes, so an agent must read carefully to avoid misselection.
All names are lowercase snake_case with no camelCase mixing, which keeps them readable. But the convention is semantically mixed: bare verbs (compare, define, enumerate, traverse, answer_why) sit alongside noun phrases (emotional_palette, site_context, k_snippets, review_plan, feedback), so there is no predictable verb_noun pattern.
13 tools is squarely in the well-scoped 3-15 range for an AEC knowledge graph, and each query tool earns its place by covering a distinct retrieval mode (definition, enumeration, causation, ordering, standards, site, plan review). The lone non-query tool (feedback) is a deliberate write-path addition rather than filler.
The surface covers an impressively broad knowledge lifecycle: term definitions, type enumeration, causal explanation and verification, connection paths, process ordering, standards snippets, site conditions, plan-code review, and experience reading, plus a feedback channel. The only gaps are the absence of a free-text topic search or a way to list covered domains, which agents can mostly work around via k_snippets.
건축·공간의 왜·원리·득실을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다.
→ 대신 쓸 것: 이미 아는 인과 한 줄의 근거만 확인하려면 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 이 그 경로를 갖고 있지 않다는 뜻이니 근거로 쓰지 않는다. 읽기 전용이고 외부를 부르지 않는다 — 적재된 정본만 본다.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | 과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01 | |
| depth | No | L1, L2, or L3. Hops are hard-capped at 4. | L2 |
| scope | No | Optional comma scope filter such as climate=arid,epoch=ancient. | |
| profile | No | 탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard). | |
| question | Yes | Natural-language why question. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, closed-world, idempotent, and non-destructive behavior; the description reinforces this and adds non-obvious behavioral facts: depth is hard-capped at 4 hops, profile independently sets the exploration budget with deep consuming 5x quota, profile overrides depth when both are given, and relevance=low/no_path_reason means the path is absent and must not be cited as evidence.
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 front-loaded with the core purpose, then follows a logical structure: examples, alternative tools, parameter semantics, and a usage caveat. Every sentence carries actionable information without filler, and the use of bullets and bold makes it 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?
Given five parameters, an output schema, and rich annotations, the description covers purpose, routing boundaries, parameter behaviors, edge cases, and operational constraints. An agent has everything needed to decide whether to call this tool, how to configure depth/profile, and how to interpret success and failure signals.
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 baseline is 3, but the description adds substantial meaning beyond the schema: it defines depth ordering (L1<L2<L3), explains that profile is independent of depth, states that profile determines the actual budget when both are provided, and details the budget implications of each profile. It also clarifies as_of's format and the interpretation of result caveats.
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 verb and resource: it explains the 'why, principles, and pros/cons' of architecture/space via causal paths, and grounds this with concrete example questions. It also explicitly distinguishes itself from four sibling tools, so an agent can tell them apart without inspecting schemas.
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?
It clearly states when to use the tool ('when asking why questions') and routes to named alternatives with specific conditions: evidence_for for a single known causal line, path_between for mere connectivity, k_snippets for numbers/provisions, and define for term meanings. This is explicit when-to-use and when-to-use-other guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
두 공법·개념의 차이를 대조한다 — '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 그대로 전하라. 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | 첫째 공법/개념 (예: RC 골조 시공). 'A vs B'를 a에 한 번에 줘도 됨. | |
| b | No | 둘째 공법/개념 (예: 철골 시공). a에 vs가 있으면 생략 가능. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses key behaviors: deterministic construction, no LLM involvement, return content (A/B sequences, unique steps, shared steps, contrast edges), and the meaning of low a_coverage/b_coverage as an honest knowledge-thinness signal with instruction to not fabricate gaps. This adds significant context beyond the annotation fields and aligns with them; no contradiction.
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 front-loaded with the core purpose and examples, followed by concise routing rules, parameter semantics, and behavioral notes. Every sentence carries distinct, actionable information; there is no filler or redundancy. Despite being longer than the minimal two-sentence example, its density and clear formatting justify a perfect score.
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 comparison tool with a relatively rich operational model, the description covers everything needed to invoke it correctly: what it returns, how to pass parameters, the meaning of coverage fields, honesty principles, and its read-only/external-call-free nature. The output schema exists, so return-value details need not be repeated, and annotations already cover safety. No material gap remains.
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?
The input schema already covers parameter meaning at 100%, including the 'A vs B' option in parameter a. The description adds important usage semantics beyond the schema: parameters are concept/method names rather than question sentences, the separator is strictly 'vs', and leaving b empty when only one side is given produces no useful result. This elevates the baseline of 3 to a 4 by providing operational guidance that prevents misuse.
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 verb and resource: it contrasts differences between two methods/concepts, with concrete examples ('RC 구조 vs 조적조', '스틱 vs 유닛 커튼월'). It also explicitly differentiates itself from sibling tools by naming scenario, enumerate, define, and k_snippets as alternatives for other request types, so the agent can clearly distinguish when to use compare.
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 gives explicit 'call it for comparison/difference requests' guidance and lists when-not-to-use with specific alternative tools ('단일 순서는 scenario · 종류 열거는 enumerate · 용어 뜻은 define · 수치·조문은 k_snippets'). It also provides critical parameter usage rules: a and b are concept/method names, not question sentences, and how to handle the 'A vs B' format, including the warning that providing only one side yields no comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
건축·건설 용어 하나의 뜻을 돌려준다 — '이형철근이 뭔가', '방화구획이란', '옹벽과 흙막이의 정의' 같은 'X가 무엇인가' 질문에 호출하라. → 대신 쓸 것: 수치·조문이 필요하면 k_snippets · 종류/체계 열거는 enumerate · 왜 그런지는 answer_why · 두 개념 차이는 compare · 두 개념이 어떻게 이어지는지는 path_between. 이 도구는 정의 한 덩어리만 준다 — 기준값은 주지 않는다. ★파라미터: term 은 용어 하나로 넣는다(질문 문장이나 여러 용어 나열이 아니다). limit 는 동음이의로 갈릴 때 몇 개까지 볼지이고 1~5 로 잘린다(기본 3). as_of 는 YYYY-MM-DD. ★abstained=true 이면 den 이 그 용어의 정의를 갖고 있지 않다는 뜻이다 — 비슷한 말을 지어내지 말고 그대로 전한 뒤 다른 출처로 답한다. exact=false 는 정확한 이름 일치가 아니라는 표시이니 이름이 맞는지 확인하고 쓴다. 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | 정의를 물을 용어 하나 (예: 이형철근). | |
| as_of | No | 과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01 | |
| limit | No | 동음이의로 갈릴 때 볼 후보 수 (1~5). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/closed-world, yet the description adds material behavior the agent cannot get elsewhere: abstained=true means the den genuinely lacks a definition and must not be paraphrased, exact=false flags an inexact name match, and the tool never returns normative values. It also restates the read-only/no-external-call profile without contradicting annotations.
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?
Information is front-loaded: purpose first, then alternatives, then parameter notes, then output-flag semantics. The arrow-and-star shorthand is dense and effective, though the block is long enough that a reader must scan several segments to find the two output flags.
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 three-parameter lookup with an output schema plus full annotations, nothing an agent needs is missing: when to call, when to use a sibling, how to form each argument, and how to interpret abstained/exact in the response.
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 already 100%, but the description still adds meaning: term must be a single term rather than a question sentence or a list of terms, limit is a disambiguation cap truncated to 1~5 with default 3. as_of's YYYY-MM-DD format merely repeats the schema, so this stops short of a 5.
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?
States a specific verb and resource ('건축·건설 용어 하나의 뜻을 돌려준다') and anchors it with concrete example questions. It also explicitly carves out scope ('이 도구는 정의 한 덩어리만 준다 — 기준값은 주지 않는다'), making it distinguishable from every 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?
Gives an explicit trigger condition ('X가 무엇인가' 질문) and then routes to the right alternative for each adjacent need: k_snippets for numbers/articles, enumerate for taxonomies, answer_why for causation, compare for contrasts, path_between for relations. This is about as complete as routing guidance gets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
공간을 순서대로 지날 때의 분위기 전이를 읽는다. "진입에서 거실까지 감정 흐름", "압축에서 해방"처럼 이동 순서와 체험 목표가 있을 때 쓴다.
→ 대신 쓸 것: 작품 평가나 "왜 걸작인가" 같은 이유는 answer_why · 법규 관점 평면 검토는 review_plan · 공정 순서는 scenario. 이 도구는 체험 순서만 다룬다.
★파라미터: spaces 는 실제 이동 순서로 넣는다 — 배열 순서가 곧 동선이고, 순서를 바꾸면 결과가 바뀐다. 하나만 넣으면 전이가 없어 얻을 것이 없다(둘 이상). target 은 선택이고, 넣으면 그 목표에 대한 정합/괴리를 같이 본다. 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| spaces | Yes | Ordered spaces such as ["좁은 진입로", "낮은 천장 복도", "높은 거실"]. | |
| target | No | Optional affective target such as "환대와 개방감". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description goes beyond them by disclosing: no external calls ('외부 호출 없음'), order-sensitivity of results ('순서를 바꾸면 결과가 바뀐다'), and the minimum-input behavior ('하나만 넣으면 전이가 없어 얻을 것이 없다'). These are non-obvious operational traits that materially change how the agent should invoke the tool.
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 follows a clear arc — definition, use-case examples, alternative mapping, parameter guidance, safety note — with scannable markers (→, ★) that aid parsing. It is slightly long and the closing '읽기 전용' partially duplicates readOnlyHint, but no sentence is wasted and the disambiguation section earns its length given 11 siblings.
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 tool with full annotations, 100% schema coverage, and an output schema present, the description covers everything an agent needs to call it correctly: what it computes, when to use it, what to use instead, how to order inputs, an edge-case warning (single space), the target's role, and the side-effect profile. Return-format details are already covered by the output schema, so their absence is not a gap.
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?
Despite 100% schema coverage (baseline 3), the description adds real semantic value: spaces must be the 'actual movement order' with array order being the route itself, a de facto minimum of two entries with the reasoning (a single space produces no transition), and target is explained as checking coherence/discrepancy against the goal — something the schema only hints at with an example. This transforms the parameters from data shapes into behavioral instructions.
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 opens with a specific verb+resource statement — 'reads atmosphere transitions when passing through spaces in order' — and grounds it with concrete examples ('진입에서 거실까지 감정 흐름', '압축에서 해방'). It closes with an explicit scope boundary ('이 도구는 체험 순서만 다룬다') and names what it is not (answer_why, review_plan, scenario), so an agent can distinguish it from siblings without opening their schemas.
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?
Gives an explicit when-to-use condition (movement order + experience goal) and names three alternatives with their trigger conditions: reasons/judgment → answer_why, legal-plan review → review_plan, process order → scenario. The only gap is that spatially or sequentially adjacent siblings such as traverse and path_between are not addressed, even though the tool's spatial/sequential theme makes confusion with them plausible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
어떤 것의 종류·구성요소·분류를 완전 열거한다 — '건축물 하중의 종류', '구조용 강종 체계', '건축 도면의 종류' 같은 'X의 종류/체계' 요청에 호출하라. → 대신 쓸 것: 순서는 scenario · 비교는 compare · 한 용어의 뜻은 define · 수치·조문은 k_snippets. ★파라미터: query 는 'X의 종류/체계/구성요소' 꼴로 준다. 낱말 하나만 주면(예: '하중') 무엇을 열거할지 정해지지 않아 match 가 안 잡힐 수 있다. 권위표준 기반 큐레이션 분류학으로 완전한 멤버 목록을 반환하고, 각 멤버 정의는 그래프에서 당긴다. 결정론. match=None 이면 미큐레이션 주제 — k_snippets 로 폴백. gaps 는 멤버 정의가 아직 그래프에 없다는 정직한 신호(지어내지 말고 그대로 전하라). 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 'X의 종류/체계/구성요소' 질의 (예: 건축물 하중의 종류). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false, and the description adds useful behavioral context: deterministic output, curated taxonomy based on authoritative standards, fallback to k_snippets when match=None, and honest gaps signaling. It also explicitly states '읽기 전용 · 외부 호출 없음' which aligns with the annotations.
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 compact and front-loaded with the core action and examples, then routes to alternatives, then clarifies parameters and behavior. Every sentence has a purpose, though it is denser than necessary in the middle section with shorthand arrows and symbols. Still highly efficient for a Korean-language tool description.
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 only one param, full schema coverage, an output schema present, and rich annotations, the description covers what an agent needs: when to use, what to pass, what to expect, and how to handle fallback/gaps. Nothing important is missing for correct invocation.
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 baseline is 3. The description adds meaning beyond the schema by specifying the query form ('X의 종류/체계/구성요소' 꼴), giving examples, and warning about the failure mode when a single word is passed. This is meaningful guidance that helps the agent form the correct query.
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 verb ('완전 열거한다') and a specific resource ('종류·구성요소·분류'), and distinguishes it from sibling tools like compare, define, and k_snippets. It also provides concrete examples ('건축물 하중의 종류', '구조용 강종 체계') that make the tool's purpose unambiguous.
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 says when to call it ('X의 종류/체계' 요청에 호출하라) and names each alternative with its routing condition (순서는 scenario · 비교는 compare · 한 용어의 뜻은 define · 수치·조문은 k_snippets). It also warns against supplying a single word and advises the required query shape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
"A 가 B 를 유발한다"는 한 연결의 근거를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다.
→ 대신 쓸 것: 두 개념 사이 경로를 찾는 것이면 path_between · 왜 그런지 설명이면 answer_why · 수치·조문 근거면 k_snippets. 이 도구는 이미 아는 한 엣지를 겨눈다.
★파라미터: from·to 는 개념 이름이고(문장 아님), relation 은 그래프 엣지 종류다 — causes(유발) · enables(가능하게 함) · requires(선행 필요) · contrasts(대비). 셋 다 필수다. relation 을 모르면 이 도구 대신 path_between 으로 먼저 어떤 관계인지 본다. ★evidence_note 와 stance 를 구분해 전하고, disclaimer 가 있으면 그대로 표기한다. 엣지가 없으면 없다고 답한다 — 근거를 지어내지 않는다. 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target concept name. | |
| from | Yes | Source concept name. | |
| as_of | No | 과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01 | |
| relation | Yes | Relation, e.g. enables, causes, evokes. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: evidence_note and stance should be reported separately, disclaimers must be preserved, and if no edge exists the agent should say so rather than fabricating evidence. It also explicitly notes read-only behavior and no external calls, which reinforces the annotation profile.
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 well organized, leading with purpose, then alternatives, then parameter semantics, then behavioral caveats. It is slightly longer than strictly necessary, but every section earns its place and the arrow/bullet formatting makes it easy to scan.
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 tool with an output schema and strong annotations, the description covers all decision-relevant aspects: when to use it, what the parameters mean, what to do when the relation is unknown, what to report, and how to handle missing edges. Nothing needed for correct invocation 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?
Although schema coverage is 100%, the description adds crucial semantics: from and to are concept names, not sentences; relation is a graph edge type; it lists the allowed relation values (causes, enables, requires, contrasts); and clarifies that all three are required. This goes well beyond the schema's minimal descriptions.
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 verb and resource: it confirms the evidence for one causal edge ('A가 B를 유발한다는 한 연결의 근거를 확인한다'). It further sharpens the scope by saying the tool targets 'an edge you already know,' which clearly sets it apart from path-finding or explanation tools.
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 says when to use it, provides sibling alternatives (path_between, answer_why, k_snippets), and states when to switch to path_between if the relation is unknown. This is exemplary guidance for an agent selecting among related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
사용자가 직접 입력하는 폼이 아니라, 호출 에이전트가 직전 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 를 쓴다. 사용자 대화 원문은 전송하지 않는다. 불만족과 사유는 다음 날 보완 후보로 접수된다.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | 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. | |
| query_id | No | The 16-character query_id returned in the previous response meta. | |
| satisfied | Yes | Whether the previous Den response was satisfactory. | |
| issue_type | No | Required when dissatisfied: 오답, 무관, 기권과다, 얕음, or 기타. | |
| question_text | No | The exact prior Den tool query, used only when query_id is unavailable. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, so the agent knows this is a non-idempotent write. The description adds useful behavioral context (never send conversation text, complaints are logged as next-day candidates) but doesn't restate mutation semantics. Adequate given annotations carry the safety profile.
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 bloated with repeated starred emphases (★, ★★, ★★★), restating the same comment-field guidance three times. The core content is buried and the formatting is shouty rather than front-loaded, impairing quick scanning.
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 mutation tool with an output schema, the description covers the who/what/when reasonably well and the schema covers parameters. However, the comment-field guidance is over-specified and the enumeration of issue-types is left to the schema, so it is adequate but not well-balanced.
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 all five parameters are already documented in the schema. The description reinforces the satisfied/issue_type mapping and query_id-vs-question_text fallback logic but adds no syntax or format detail beyond the schema. Baseline 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 action (recording the user's reaction to the previous Den answer before ending the conversation) and explicitly distinguishes itself from a query tool by naming the siblings k_snippets/answer_why. It is clear what the tool does, though the 'relay tool' framing in Korean is slightly indirect.
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?
Gives concrete when-to-use rules: pass query_id if available, otherwise question_text; map satisfied=true for adoption/positive and false with an issue_type for corrections/complaints/ignoring; do not guess if no observable reaction. Missing explicit exclusions beyond 'this is not a query tool', but the conditional mapping is detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한국 건설기준(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) · 조문 원문이 있으면 cited_articles. 출처를 그대로 인용한다. ★relevance=low 이거나 lacks_answer=true 면 den 이 그 자료를 갖고 있지 않다 — 스니펫을 근거로 쓰지 말고 그렇게 말한 뒤 다른 출처로 답한다. 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | 과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01 | |
| limit | No | Maximum snippets to return. | |
| scope | No | 선택. 이 질문이 속한 **공종·기준**을 알면 넣어라 — 그 범위로 좁혀 답한다. 같은 용어라도 공종마다 규정값이 다르다(되메우기 다짐 두께는 도로·하수도·조경이 각각 다르다). 넣지 않으면 den 은 갈리는 공종을 `scope_split` 로 알려 주고, 값을 인용하기 전에 공종을 확인하라고 요구한다. 넣었는데 그 범위 밖 자료가 섞여 나가면 `scope_partial` 로, 하나도 없으면 `scope_absent` 로 알려 준다 — den 은 범위 밖 자료를 버리지 않고 **고지**한다. 형식: 공종 이름('도로'·'하수도'·'건축') 또는 기준코드('KCS 44'·'KDS 14 20 50'). ★모르면 넣지 마라 — 틀린 범위는 틀린 답을 만든다. | |
| profile | No | 탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard). | |
| question | Yes | Question or retrieval slot for K snippets. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly/idempotent/non-destructive/openWorld=false), yet the description adds behavior annotations cannot express: relevance=low / lacks_answer=true means the corpus lacks the material and the snippet must not be used as evidence, the scope_split/scope_partial/scope_absent disclosure semantics, and the deep profile's 5x quota cost. That is substantial disclosure beyond structured fields.
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?
Front-loaded with purpose, then alternatives, then parameters, with bold/★ markers aiding scanning. It is long and partially redundant with the schema's own scope parameter text, but nearly every sentence carries routing or behavioral 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 five parameters, a rich schema, and an output schema, the description supplies everything else an agent needs: corpus limits, failure-signal semantics, quota tradeoffs, and prerequisite tool ordering. Nothing required to invoke or interpret results 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 baseline is 3, but the description goes well beyond it: it explains that scope and profile are orthogonal axes, gives accepted scope formats, warns against guessing scope, states limit's default of 8 and that higher values degrade relevance on the tail, and explains as_of's format and purpose.
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?
States a specific verb and resource ('한국 건설기준(KDS·KCS·KS)과 건축 법령의 수치·조문을 찾는다') and gives concrete example queries. It also names the sibling tools it is not (define, enumerate, scenario, compare, answer_why), so an agent can route without opening any schema.
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?
Explicit when-to-use ('웹 검색보다 먼저'), explicit routing to alternatives by intent type, and an ordering rule (call site_context first and pass its scope). It even states when NOT to supply a parameter ('scope를 모르면 넣지 마라'), which is the strongest form of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
두 개념이 어떻게 이어지는지 확인한다. "단열과 결로는 어떻게 연결되나", "전단벽에서 층간변위까지"처럼 출발·도착이 분명할 때 쓴다.
→ 대신 쓸 것: 한 지점에서 관계를 따라가며 훑으려면 traverse · 공정 전체 흐름이면 scenario · 왜 그런지 설명이 필요하면 answer_why · 한 연결의 근거만이면 evidence_for.
★파라미터: a·b 는 문장이 아니라 개념 이름/구로 넣는다("결로" O, "왜 결로가 생기나" X). a 와 b 가 같으면 빈 결과다. scope 는 쉼표로 여러 축을 주면 모두 만족하는 경로만 남긴다 (climate=arid,epoch=ancient). profile=deep 은 쿼터를 5회분 쓴다 — 먼저 기본으로 보고 빈손일 때만 올린다. ★경로가 없으면 만들어 내지 말고 연결이 확인되지 않는다고 말한다. 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | Start concept name or phrase. | |
| b | Yes | End concept name or phrase. | |
| scope | No | Optional comma scope filter such as climate=arid,epoch=ancient. | |
| profile | No | 탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive annotations, it discloses important behaviors: identical a and b yield an empty result, deep profile consumes 5x quota, and it must not fabricate a path when none is found. These are material execution traits not present in the annotations.
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 well-organized: purpose/examples, alternatives, parameter guidance, then failure behavior. Every sentence adds operative value, and the most important routing information is front-loaded.
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?
With 4 params, an output schema, and rich annotations, the description still adds all missing operational context: when to use, how to phrase inputs, cost/quota warning, and honesty requirement on empty results. Nothing important for correct invocation is left unstated.
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?
Although schema coverage is 100%, the description adds critical usage semantics: a/b must be concept names/phrases rather than full sentences, same a=b returns empty, scope axes are ANDed, and deep should only be used after default returns empty. This goes beyond the schema's field-level descriptions.
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 opens with a specific verb and resource: '두 개념이 어떻게 이어지는지 확인한다' (verifies how two concepts are connected), and gives concrete examples. It also distinguishes itself from siblings by naming traverse, scenario, answer_why, and evidence_for as alternatives for different tasks.
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?
It explicitly states when to use the tool ('출발·도착이 분명할 때') and supplies a '대신 쓸 것' list with conditions for each alternative. This gives an agent clear routing criteria without needing to inspect other definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
평면도·배치도를 건축 법규 관점에서 검토한다 — 채광·환기·피난·면적 요건 위반을 짚는다. 사용자가 도면을 공유하거나 공간 구성 검토를 요청하면 이 도구를 쓴다. → 대신 쓸 것: 특정 수치·조문 하나의 근거면 k_snippets · 왜 그 요건인지는 answer_why · 체험·분위기 관점이면 emotional_palette. 대지의 관할이 걸리면 site_context 를 먼저 부르고 그 jurisdiction 을 여기에 넘긴다. ★입력: 이미지가 아니라 도면에서 읽어낸 구조를 넣는다 — 방(용도·외부창 유무)·인접·개구부·동선. rooms 만 필수이고 나머지는 선택인데, 빠뜨린 만큼 검토가 좁아진다(adjacency 가 없으면 인접 요건을, circulation 이 없으면 피난 동선을 못 본다). 검토 못 한 축은 결과에 그대로 밝힌다. jurisdiction 은 KR-서울 꼴이고, 주면 그 관할 이름이 적힌 조문 기록을 우선 매칭한다 — 관할 조례를 따로 조회하지는 않는다. 위반(violation) 항목은 답변에서 빼지 않는다. 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | Yes | Parsed rooms with id, use, ext_windows, optional area/floor/access/shape. | |
| openings | No | Openings, including exterior windows and doors, as parsed objects or pairs. | |
| adjacency | No | Room adjacency pairs such as [[a,b]] or objects with from/to. | |
| site_scope | No | Optional site scope such as climate/culture/epoch/tech_level. | |
| circulation | No | Circulation edges or ordered paths, e.g. [[from,to]] or [a,b,c]. | |
| jurisdiction | No | Optional jurisdiction key such as KR-서울 for NormClause lookup. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/no-external-call, and the description adds substantive traits beyond them: violations are never dropped from the answer, unreviewed axes are disclosed in the result, and jurisdiction only prioritizes matching clause records rather than querying separate ordinances. That is meaningful behavioral disclosure not present in structured fields.
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?
Front-loads the purpose, then alternatives, then input guidance, then caveats. It is dense with arrows and star markers and runs long, but nearly every clause carries distinct operational information, so little is wasted.
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 six-parameter review tool with an output schema, the description covers purpose, alternatives, input semantics, interaction with site_context, and result behavior. Return values need not be explained because an output schema exists, so nothing an agent needs to invoke it correctly 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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: the input is parsed structure rather than an image, rooms is the only required field, and missing adjacency/circulation specifically narrows which requirements are checked. It also specifies the jurisdiction key format and its lookup behavior, exceeding what the schema conveys.
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?
States a specific verb and resource (건축 법규 관점에서 평면도·배치도를 검토) and enumerates the exact axes checked (채광·환기·피난·면적 요건 위반). It also names the sibling it is not for (k_snippets, answer_why, emotional_palette), so an agent can distinguish it without opening any schema.
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?
Explicitly states the triggering condition (사용자가 도면을 공유하거나 공간 구성 검토를 요청) and routes to named alternatives for adjacent needs, plus a required ordering rule (site_context를 먼저 부르고 jurisdiction을 넘긴다). Nothing about when-to-use is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 시퀀스·시나리오 요청에 호출하라. → 대신 쓸 것: 단순 사실·수치는 k_snippets · 두 지점 사이만 궁금하면 path_between · 한 노드의 선후 이웃만이면 traverse · 두 공법 차이는 compare. ★파라미터: max_nodes 는 5~60 으로 잘린다(기본 40). 올리면 넓게 모으지만 느슨한 노드가 섞여 ordering_coverage 가 떨어질 수 있다 — 먼저 기본으로 보고 gaps 를 본 뒤 올린다. 결정론(LLM 없음). ordering_coverage 가 낮거나 gaps 가 있으면 그래프에 순서 지식이 아직 없다는 정직한 신호 — 그 구간은 지어내지 말고 gaps 그대로 사용자에게 전하라. 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 공정/시퀀스 질의 (예: 철근콘크리트 골조 시공 순서). | |
| max_nodes | No | 수집할 공정 노드 상한. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds several behavioral facts beyond the annotations: the operation is deterministic with no LLM, it makes no external calls, max_nodes is clamped to 5–60, and low ordering_coverage or gaps are honest signals to surface to the user rather than fabricate. These details materially shape invocation and post-processing behavior without contradicting the readOnly/idempotent annotations.
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?
Each sentence carries distinct information: purpose, request examples, sibling routing, parameter tuning, determinism, and honesty policy. The use of arrows and starred labels keeps the dense content scannable and front-loads the primary purpose before alternatives and parameter details.
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 output schema exists, return values need not be described. The description covers selection criteria, alternatives, parameter behavior, successful output semantics, failure signals, and safety characteristics, making it complete for an agent to decide when and how to call the 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?
Although the schema already covers both parameters at 100%, the description meaningfully extends the max_nodes semantics: it is clamped to 5–60, defaults to40, wider collection can lower ordering_coverage, and the recommended strategy is to run with defaults first and inspect gaps before raising it. This turns a bare schema field into usable guidance.
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 names a specific verb+resource: it constructs a work sequence by collecting related process nodes and topologically sorting them via enables/requires edges into an ordered step flow. It explicitly distinguishes itself from siblings by naming k_snippets, path_between, traverse, and compare as the alternatives for different request types.
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?
It states precisely when to call: for sequence/scenario requests such as 'construction order from foundation to 3rd floor' or 'temporary works procedure'. It also gives explicit exclusions by naming the sibling tools that should be used for facts, point-to-point paths, neighbor traversal, and comparisons, so an agent gets clear routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
지명·좌표를 기후·문화·관할 조건으로 바꾼다. 대지·지역·행정구역·위경도가 언급되면 다른 도구보다 먼저 부른다.
→ 그다음: 돌아온 scope 를 k_snippets·answer_why 에, jurisdiction 을 review_plan 에 넘긴다. 이 도구 자체는 기준·수치를 주지 않는다 — 수치는 k_snippets, 도면 검토는 review_plan.
★파라미터: region 을 먼저 본다. lat/lng 는 region 이 없거나 못 찾을 때의 대체 경로다 — 둘 다 주면 region 이 이긴다. region 은 등재된 지명·별칭에 맞아야 한다("부산 수영구" O). 셋 다 비우면 아무것도 못 정하고 relevance=low 로 돌려준다. ★행정구역이 확인되지 않은 좌표 결과는 추정이라고 밝힌다. 읽기 전용 · 외부 지오코딩을 부르지 않는다(적재된 지명표만 본다).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude for coordinate fallback. | |
| lng | No | Longitude for coordinate fallback. | |
| region | No | Place name such as "부산 수영구" or "Dubai". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive/closed-world annotations, the description discloses non-obvious behaviors: it never calls external geocoding (only consults the loaded place-name table), marks coordinate results without confirmed administrative district as 'estimated', and returns relevance=low when all params are empty. Nothing contradicts the annotations, and these added traits materially change what an agent should expect.
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 purpose is front-loaded in the first line and the parameter rules are clearly marked with ★, with line breaks grouping call ordering, downstream routing, param precedence, and quality flags. It is mildly dense and briefly repeats the read-only annotation, but every section carries operational content an agent needs.
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 three optional params with precedence rules, a routing integration touching four sibling tools, and an output schema that accounts for the return shape, the description covers everything non-obvious: trigger conditions, exclusions, coordinate-estimation caveats, and the geocoding constraint. Nothing needed for correct invocation 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?
With 100% schema description coverage the baseline is 3, and the description adds real operational rules on top of it: region is examined first and wins when both region and lat/lng are given, region must match a registered name or alias, and all-empty inputs degrade to relevance=low. The schema already conveys that lat/lng are fallbacks, so the uplift is meaningful but not absolute.
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 line states a specific transformation — place names/coordinates into climate·culture·jurisdiction conditions ('지명·좌표를 기후·문화·관할 조건으로 바다') — which is a distinct verb+resource. It differentiates from siblings by declaring itself the first tool to call when site context is mentioned and by delimiting what it does not do (no figures, no drawing review), so an agent can distinguish it from k_snippets and review_plan without opening their schemas.
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?
Usage guidance is explicit and actionable: call this before other tools when site/region/administrative-district/coordinates are mentioned, then route the returned scope to k_snippets·answer_why and jurisdiction to review_plan. It also states exclusions — figures belong to k_snippets, drawing review to review_plan — leaving no ambiguity about when to select this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
시공 순서와 선후 관계를 따라간다 — '무엇이 무엇보다 먼저 와야 하는가'. '기초부터 골조까지 순서', '거푸집 해체 전에 확인할 것' 같은 공정 질문에 쓴다. → 대신 쓸 것: 출발·도착 두 지점이 분명하면 path_between · 공정 전체 흐름을 한 번에 구성하려면 scenario · 두 공법 차이는 compare · 단순 수치·조문은 k_snippets. ★파라미터: relation=requires 는 선행 조건(이것보다 먼저 와야 하는 것), enables 는 후속 가능 작업, causes 는 인과, contrasts 는 대비다. 생략하면 전부 본다. direction=out 은 정방향(다음), in 은 역방향(이전) — 'X 전에 무엇을' 은 in 이다. depth 는 1~4 로 잘린다(넘겨도 4). limit 는 모든 홉을 합친 최대 스텝 수다(기본 40). 빈 결과는 den 이 그 순서를 아직 갖고 있지 않다는 뜻이다 — 순서를 지어내지 않는다. 읽기 전용 · 외부 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | 순회 홉 수 (1~4). | |
| limit | No | 최대 스텝 수. | |
| start | Yes | 시작 개념 이름/구문 (예: 거푸집). | |
| relation | No | 순회할 관계 (requires/enables/causes/contrasts 등). 생략 시 전체. | |
| direction | No | out(정방향) 또는 in(역방향). | out |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, yet the description adds real behavioral context beyond them: empty results mean the graph simply lacks that ordering, and the agent must not fabricate an order. It also discloses that depth is clamped to 1–4 regardless of input and that limit is the combined step cap across all hops. The closing '읽기 전용 · 외부 호출 없음' merely restates the annotations, which keeps this from a 5.
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?
Front-loaded with the bolded purpose, then the alternative-routing list, then a ★-marked parameter block — a deliberate, scannable structure. It is dense but every section earns space; only the redundant read-only/no-external-calls restatement at the end is filler.
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?
An output schema exists, so return format need not be explained. Across the description and schema the agent gets purpose, routing conditions, all five parameters' semantics, clamping/default behavior, and the empty-result caveat — everything needed to invoke this traversal 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?
Schema coverage is 100%, so 3 is the baseline, but the description goes further by defining each relation value's meaning (requires = prerequisite, enables = follow-up, causes = causal, contrasts = contrast; omit = all) and by disambiguating direction with a worked example — 'what comes before X' is direction=in, not out. That resolves a genuine ambiguity in the schema's bare 'in(역방향)'.
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?
Opens with a bolded, specific verb+resource: following construction sequence and precedence relations ('what must come before what'), with concrete example questions. It also explicitly states what it is not, naming path_between, scenario, compare, and k_snippets with their selecting conditions, so an agent can distinguish it from all relevant siblings without reading any schema.
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?
Gives explicit when-to-use phrasing ('기초부터 골조까지 순서', '거푸집 해체 전에 확인할 것') plus a routing list of four alternatives each paired with the condition that selects them (two endpoints → path_between, whole workflow → scenario, difference → compare, plain text/law → k_snippets). Nothing is left to inference.
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.
answer_whycomparedefineemotional_paletteenumerateevidence_forfeedbackk_snippetspath_betweenreview_planscenariosite_contexttraverseKorean statutes, precedents, local business-district stats and public procurement for AI agents.
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Seoul building context for AI agents, delivery/logistics, maps and robotics.
Add one secure layer between your agents and this server.
