Skip to main content
Glama

den — Korean AEC knowledge, curated

Find Standard Clauses (기준·조문 찾기)

k_snippets
Read-onlyIdempotent

한국 건설기준(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 이 그 자료를 갖고 있지 않다 — 스니펫을 근거로 쓰지 말고 그렇게 말한 뒤 다른 출처로 답한다. 읽기 전용 · 외부 호출 없음.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNo과거 발주도서·분쟁의 '당시 기준' 질의용. 예: as_of=2020-06-01
limitNoMaximum snippets to return.
scopeNo선택. 이 질문이 속한 **공종·기준**을 알면 넣어라 — 그 범위로 좁혀 답한다. 같은 용어라도 공종마다 규정값이 다르다(되메우기 다짐 두께는 도로·하수도·조경이 각각 다르다). 넣지 않으면 den 은 갈리는 공종을 `scope_split` 로 알려 주고, 값을 인용하기 전에 공종을 확인하라고 요구한다. 넣었는데 그 범위 밖 자료가 섞여 나가면 `scope_partial` 로, 하나도 없으면 `scope_absent` 로 알려 준다 — den 은 범위 밖 자료를 버리지 않고 **고지**한다. 형식: 공종 이름('도로'·'하수도'·'건축') 또는 기준코드('KCS 44'·'KDS 14 20 50'). ★모르면 넣지 마라 — 틀린 범위는 틀린 답을 만든다.
profileNo탐색 예산 프로파일. direct=2홉/3경로(드릴다운), standard=현행(기본), deep=6홉/12경로+교차축(쿼터 5배). 미지정 시 질의 인텐트 기반 기본값(대개 standard).
questionYesQuestion or retrieval slot for K snippets.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.