Skip to main content
Glama

법령 조문 검색

search_law
Read-onlyIdempotent

법령 조문 검색 — 키워드 또는 조문번호로 조문 스니펫 반환(상위 top_k건).

**코퍼스가 둘이고 한 응답은 한 쪽에서만 온다(2026-08-29).** 공공계약(국가·지방계약법
계열 38개 법령)과 **세법**(소득세법·법인세법·부가가치세법·조세특례제한법·지방세법 등
64개 법령)이다. 축은 자동으로 정해진다 — 질의가 세법 법령을 이름으로 부르면 세법
코퍼스로 가고, 그 밖에는 공공계약 코퍼스에서 찾다가 **거기서 못 찾을 때만** 세법
코퍼스를 본다. `corpus="tax"`/`"contract"`로 강제할 수도 있다.
응답의 `corpus`가 **어느 코퍼스를 봤는지**다 — 세법 결과를 공공계약 근거로,
공공계약 결과를 세법 근거로 인용하지 마라. `note_corpus`가 있으면 왜 그 축이었는지다.

전문이 필요하면 get_law_article(ref)로 이어서 조회.
hit에 note가 있으면 삭제·폐지된 조문이다 — 판단 근거로 인용하지 마라.
**hit의 `implementing_articles`가 있으면 다음 호출이 이미 정해진 것이다.** 그 조문은
"대통령령으로 정하는 바에 따라"라고만 하고 구체적 사유·요건·수치는 거기 적힌 하위
조문에 있다(예: 국가계약법 제7조 → 시행령 제26조 수의계약에 의할 수 있는 경우).
**다른 도구로 다시 검색하지 말고** 그 참조를 그대로 get_law_article에 넣어라.
hit의 `delegated`가 true인데 `implementing_articles`가 없으면 하위 조문이 조문 단위로
특정되지 않은 것이다 — get_law_article로 전문을 열어 `delegations`를 보고 가라.
hit의 `article`이 "[별표 N]"이면 **표**다(2026-08-20 색인). 표 전문은 그 히트의
`law_ref`를 그대로 get_law_article에 넣어 읽는다(조문과 같은 경로다). `related_article`이
있으면 그 표의 근거 조문이니 함께 밝혀라 — 제재 기간·요율 같은 값의 실제 출처가
여기다(근거 조문이 둘 이상이면 `related_articles`에 전부 온다). 별표 제목에
"(제N조 관련)" 표기가 없는 표는 이 필드가 **없다** — 그때는 표 자체를 근거로 인용하라.
error가 "no_corpus_match"면 질의한 법령이 이 코퍼스 밖이다 — **그런 규정이 없다는
뜻이 아니므로** 그렇게 답하지 말고 corpus_laws로 범위를 밝힌 뒤 law.go.kr을 안내하라.

**범위 공시를 먼저 읽어라(2026-08-29).** `total_found`는 코퍼스에서 맞은 **총수**이고
`count`는 네가 지금 받은 건수다. 둘이 다르면 `note`/`note_coverage`가 왜 잘렸는지
말해 준다 — 그때 "관련 조문은 N건뿐"이라고 답하면 거짓이다. `truncated:true`면 백엔드
반환 상한(`backend_cap`)에 걸린 것이고, `complete:false`면 total_found조차 **하한**이다.
`total_found_is_lower_bound:true`면 `total_found`는 **"최소 N건 이상"**이라는 뜻이다 —
우리가 스캔 상한(`scan_limit`)에서 세기를 멈췄으므로 그 숫자를 정확한 총수로 인용하지
마라. 더 필요하면 top_k를 올리거나(최대 20) 법령명·조문번호로 질의를 좁혀 다시 불러라.
`search_scope`/`searched`는 어느 가지로 찾았는지다(article·keyword·token·semantic).
`degraded:"semantic_unavailable"`이면 의미(임베딩) 검색이 장애로 못 돌아 **키워드
매치만**으로 답한 것이다 — 이때의 0건은 부재의 근거가 아니다. 사용자에게 그 사실을
밝히고 핵심어를 바꿔 재검색하라.

Args:
    query: "수의계약", "시행령 제26조", "제21조", "소득세법 제55조" 등
    top_k: 반환 건수 (기본 8, 최대 20)
    corpus: 코퍼스 강제 지정 — "contract"(공공계약) | "tax"(세법). 생략하면 자동.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
top_kNo
corpusNo

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the operation read-only/idempotent, and the description adds substantial non-obvious behavior: two-corpus routing with fallback, response fields like truncated/complete/total_found_is_lower_bound meaning lower-bounded counts, degraded semantic search, and cautions about deleted/repealed provisions. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long, but every block addresses a real hazard: corpus misattribution, delegated articles, attached tables, truncation semantics, and degraded search. It is front-loaded with the one-line purpose before deep behavioral detail, and uses bold to mark the most critical warnings.

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?

With no output schema, the description covers the response semantics an agent must interpret correctly: corpus, total_found vs count, truncated, complete, lower-bound flag, search_scope/searched, degraded, and hit-level fields. It also specifies follow-up actions (get_law_article, law.go.kr) and error handling, so nothing required for a safe call 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 0%, but the Args section fully compensates: query gets concrete examples ('수의계약', '시행령 제26조', '소득세법 제55조'), top_k gets default and max, and corpus gets exact allowed values 'contract'/(공공계약) and 'tax'/(세법). This is far beyond what the schema provides.

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?

The opening line '법령 조문 검색 — 키워드 또는 조문번호로 조문 스니펫 반환(상위 top_k건)' names a specific verb, resource, and return shape. It also distinguishes itself from get_law_article by explicitly handing off full-text needs to that sibling.

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?

The description explicitly states when to use this tool versus get_law_article ('전문이 필요하면 get_law_article(ref)로 이어서 조회'), instructs not to re-search when implementing_articles exist ('다른 도구로 다시 검색하지 말고'), and explains when to force corpus with top_k guidance. Error handling for no_corpus_match also prescribes the correct response behavior.

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.

TDQS

A4.6/5.0
Disambiguation4/5

Most tools have clearly distinct purposes: calculation tools (check_price_adjustment, estimate_delay_penalty, decide_contract_method), reference tools (get_law_article, get_case), and search tools. The only potential confusion is between search_law and search_references since both cover statutes, but their descriptions explicitly delineate scope (statutes-only vs. statutes+guidelines+rulings).

Naming Consistency4/5

Tool names overwhelmingly follow a snake_case verb_noun pattern (check_price_adjustment, estimate_delay_penalty, get_law_article, search_cases). One outlier is delay_exemption_guide, which uses a noun-led pattern rather than a verb-led one, but it is still readable and consistent in style.

Tool Count5/5

Eleven tools is well within the ideal range for a specialized legal advisory server. Each tool covers a distinct function: rule-based determinations, calculations, legal research, historical lookup, case retrieval, and issue reporting. No tool feels redundant or superfluous.

Completeness4/5

The toolset covers the core advisory workflow well: searching statutes, guidelines, and cases; retrieving full texts and historical versions; and performing key calculations for price adjustments and delay penalties. Minor gaps exist such as calculators for other contract lifecycle adjustments, but those are reasonably addressable through the search and reference tools.