Curated Korean AEC expertise for AI agents: KDS·KCS·KS, building law, practice, and the reasoning.
Scored across 13 tools
Several tools operate on the same underlying knowledge graph—answer_why, evidence_for, path_between, traverse, and scenario—and their query intents can overlap in casual phrasing, especially around 'why' and 'sequence' questions. The extensive cross-reference notes help significantly, but an agent could still hesitate between scenario and traverse for process ordering or between answer_why and path_between for causal connections.
Names mix bare verbs (compare, define, enumerate, traverse), noun phrases (scenario, site_context, emotional_palette), and preposition-suffix forms (evidence_for, path_between), with no single predictable pattern like verb_noun. They are descriptive and readable, but the style is not consistent across the set.
At 13 tools, the server is well-scoped for a broad AEC knowledge domain. Each tool earns its place by covering a distinct query mode—definitions, comparisons, standards, causal explanation, process ordering, site context, plan review, experience, and feedback—without feeling redundant or bloated.
The toolset covers most important knowledge workflows: define, enumerate, compare, why, evidence, standards/law snippets, process scenarios, traversal, site context, regulatory plan review, emotional sequence, and feedback. The main gap is a general free-text or discovery tool for surveying what knowledge den contains when the user does not already know a term; agents can partially work around this with enumerate, k_snippets, and traverse.
건축·공간의 왜·원리·득실을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다.
→ 대신 쓸 것: 이미 아는 인과 한 줄의 근거만 확인하려면 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?
The description discloses behaviors not inferable from the annotations: the meaning of abstained=true and exact=false output flags, and instructs the agent not to fabricate similar terms and to verify exact-name matches. It also restates read-only and no external calls, complementing 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 long but every sentence earns its place: purpose, sibling routing, parameter constraints, and special output semantics. The use of arrows, stars, and line breaks front-loads the most important information and makes the dense content 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?
For a tool with 12 siblings and two output flags, the description covers the full decision space: when to use, what to expect, how to set parameters, and how to interpret abstained/exact. An output schema exists, so the lack of return-format detail is acceptable. Nothing necessary 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?
Schema coverage is 100% and each parameter already has a description, so baseline is 3. The description adds value by clarifying that term must be a single term not a question sentence, that limit is truncated to 1-5 with default 3, and that as_of uses YYYY-MM-DD format—practical constraints beyond the schema.
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: '건축·건설 용어 하나의 뜻을 돌려준다' and provides concrete example queries. It also states what the tool does not return ('기준값은 주지 않는다') and names sibling tools that handle other question types, making its purpose unmistakable.
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 instructs when to call this tool ('X가 무엇인가' 질문) and lists alternatives for other intents: k_snippets for numeric/rank texts, enumerate for type/enumerations, answer_why for reasons, compare for differences, and path_between for connections. This is an explicit when/when-not/alternatives mapping.
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 are all false hints, so the description carries the full burden, and it delivers: it discloses that original conversation text is never sent, that satisfaction feeds next-day graph supplementation, that unobserved reactions must not be guessed, and that satisfied=true still requires an adoption summary. No contradiction with annotations exists.
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 long but densely packed, with ★ markers highlighting the highest-risk rules and a clear front-loaded purpose statement. Some redundancy exists between the ★★★ block and the schema's comment description, but the structure makes the nuanced conditions scannable and every section earns its place.
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 subtle conditional requirements and five parameters, the description covers the call timing, data handling, mapping rules, non-guessing constraint, and downstream effect. Since an output schema exists, the absence of return-value discussion 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?
Even though schema coverage is 100%, the description adds critical inter-parameter logic: query_id takes priority over question_text, issue_type is required only when dissatisfied, and comment has asymmetric rules depending on satisfied. This goes well beyond the schema's per-field descriptions and materially helps an agent construct valid arguments.
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 and resource: it records the user's reaction to the prior Den response as a summary-level relay tool, not a direct user-input form. It also explicitly distances itself from query tools ('이 도구는 질의가 아니다 — 답을 찾으려면 k_snippets·answer_why를 쓴다'), which cleanly differentiates it from siblings.
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 states when to call it (after using the immediate prior Den response, before the conversation ends), how to handle query_id vs question_text fallback, and when to set satisfied/issue_type. It also gives an explicit exclusion: when the agent needs an answer, use k_snippets or answer_why instead.
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). 출처를 그대로 인용한다. ★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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral context: deep profile consumes 5x quota, higher limit degrades relevance, as_of pins the standard to a date, returned snippets must be quoted verbatim, and relevance=low/lacks_answer=true means the knowledge base lacks the data—consistent with the closed-world hint. This goes well beyond the annotations without contradicting them.
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?
Long but tightly structured: purpose and examples first, then routing to alternatives, then parameter guidance, then return/negative-signal handling. The only redundancy is the closing 'read-only, no external call' line, which mostly restates annotations. Overall every functional sentence earns its place for a nuanced tool.
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 5-parameter retrieval tool with an output schema, the description is complete: it covers when to use, when not to use, how to set each parameter, cost/quota behavior, return quoting expectations, and failure semantics. 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 coverage is 100%, so the baseline is 3. The description adds the orthogonal distinction between scope (which discipline) and profile (how deep), warns to omit scope when unknown, and notes that increasing limit lowers relevance of later results—all beyond the schema field text. It also reinforces as_of format and the scope_split/scope_partial/scope_absent signals, making the parameters more actionable.
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 concrete retrieval action: finds numeric values and verbatim clause text from Korean construction standards (KDS/KCS/KS) and building statutes. It also distinguishes itself from siblings by saying term meanings go to define, lists to enumerate, sequences to scenario, differences to compare, and rationale to answer_why. This is specific and non-tautological.
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 says to use this tool before web search when attaching evidence to construction/civil/shell/structural/MEP questions, and lists the sibling tool for each other intent (define, enumerate, scenario, compare, answer_why). It also instructs calling site_context first and passing its scope when land/administrative area is involved, so an agent knows when this tool is not the entry point.
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/non-destructive. The description adds meaningful behavior beyond annotations: 'no external calls', disclosure that omitted adjacency/circulation narrows the review and that unreviewed axes are explicitly reported, and that violations are never omitted from results. No contradiction with 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 with line breaks and bold markers: purpose → usage routing → input semantics → behavioral guarantees. Each sentence carries distinctive content; it's longer than average only because the tool's domain and parameter interplay are genuinely complex. Not bloated.
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 6-parameter, domain-specific review tool with an output schema, the description is complete: it tells the agent what structured input to compute, which fields matter, what happens when optional fields are absent, how jurisdiction affects scope, and what the response guarantees. An agent has everything needed to select and invoke the tool 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%, giving baseline 3. The description adds value beyond schema: clarifies only rooms are required, explains the consequences of omitting adjacency/circulation (which review dimsensions are skipped), and specifies the KR-서울 jurisdiction format and its fallback to national law. The description doesn't detail site_scope further, but schema already covers it, so the extra guidance lifts it above baseline.
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+resource: reviews floor plans/layouts from a building-code perspective, listing concrete violation domains (lighting, ventilation, egress, area). It explicitly names sibling alternatives (k_snippets, answer_why, emotional_palette, site_context) so the tool is distinguished without needing to open 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?
Provides explicit when-to-use ('when user shares drawings or requests spatial-recomposition review') and when-not-to-use with named alternatives and conditions (specific clause cite → k_snippets; why-requirement → answer_why; atmosphere → emotional_palette; jurisdiction → call site_context first and pass its jurisdiction). This is fully actionable routing guidance.
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 는 최대 스텝 수이고 depth 와 곱해 커진다. 빈 결과는 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?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behaviors: depth is truncated to 4, limit interacts with depth multiplicatively, and an empty result means the knowledge base does not yet contain that order — the tool does not invent ordering. This is significant added behavioral context.
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-structured and front-loaded with the core purpose. Every section earns its place: usage examples, sibling routing, parameter semantics, depth/limit behavior, and empty-result interpretation. The compact formatting and symbols aid scanning without wasting words.
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 graph-traversal tool with five parameters, the description covers purpose, alternatives, parameter meanings, edge-case behavior, and result interpretation. It also explicitly notes read-only behavior and no external calls, leaving no critical gap for an agent deciding whether and how to invoke it.
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?
Even though schema coverage is 100%, the description adds real semantic value by decoding each relation value: requires is a precondition, enables is a subsequent possible task, causes is causal, and contrasts is contrastive. It also explains direction with a concrete mapping: 'what before X' means direction=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?
The description states a specific verb and resource: it follows construction sequence and precedence relations, answering 'what must come before what'. It further distinguishes itself from siblings by naming path_between, scenario, compare, and k_snippets as alternatives for different question 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?
The description explicitly gives usage context with examples like 'order from foundation to frame' and 'what to check before formwork removal'. It also provides clear alternative routing: path_between when two endpoints are clear, scenario for a whole flow, compare for differences, and k_snippets for simple numbers or articles.
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. Dates show when Glama detected each change.
answer_whycomparedefineemotional_paletteenumerateevidence_forfeedbackk_snippetspath_betweenreview_planscenariosite_contexttraverseClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Korean public procurement law: rule-engine rulings, statutes search, live court precedents
Korean business record validation and workflow safety gates for AI agents.
Korean real estate: court auctions, 10M+ MOLIT records, subscription notice facts, loan/DSR rules
Add one secure layer between your agents and this server.
