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

A4.9/5.0
Behavior5/5

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

The description goes far beyond the readOnly/openWorld/idempotent annotations: it discloses dual-corpus fallback behavior, truncated vs lower-bound total semantics, semantic-search degradation, deleted/repealed provision notes, delegated articles lacking implementing_articles, and table-index behavior. It also warns against citing tax results as public-contract grounds. No contradiction with annotations; openWorldHint aligns with the statement that zero results are not evidence of absence.

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?

Long but well-structured: a one-line summary, bolded critical warnings, and a final Args block. Every sentence carries operational or safety guidance, and the most important corpus and citation constraints are front-loaded. The density is high enough that parsing requires effort, but the structure mitigates the length.

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 documents the critical response fields (corpus, total_found, count, truncated, complete, total_found_is_lower_bound, search_scope, searched, degraded, hit-level notes, implementing_articles, delegated, related_articles, law_ref) and error cases. It also covers follow-up actions and citation constraints, making it complete for correct invocation and interpretation. The only minor ambiguity is the undefined `corpus_laws`, but it does not undermine the overall completeness.

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 description coverage is 0%, so the description fully compensates. The Args block gives concrete query examples ('수의계약', '시행령 제26조', '소득세법 제55조'), top_k default 8/max 20, and corpus legal values 'contract'|'tax' with auto-selection behavior. This adds meaning the schema cannot convey.

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 first line states a specific action and resource: keyword/provision-number search returning provision snippets with top_k. The '조문' (provision) focus clearly separates it from sibling case/reference searches, and the follow-up to get_law_article for full text is explicitly named. No ambiguity about what this tool does.

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 routes usage: full text needed → get_law_article(ref); implementing_articles present → pass that reference directly to get_law_article and do not search another tool; no_corpus_match → clarify scope and point to law.go.kr. It also gives conditions for forcing corpus and for raising top_k. This is explicit when/when-not/alternatives 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.

TDQS

A4.6/5.0
Disambiguation4/5

Each tool has a distinct role: decision-rules, price adjustment, delay penalties, exemption guidance, statute retrieval, case retrieval, and three specialized search tools. search_law, search_references, and search_cases look similar at first glance, but their descriptions clearly separate statutory text, full reference corpus, and caselaw/interpretation. The main ambiguity is between search_law and search_references for mixed practical queries.

Naming Consistency4/5

Almost all tools follow a snake_case verb_noun pattern: check_price_adjustment, decide_contract_method, estimate_delay_penalty, get_law_article, search_references. delay_exemption_guide is the one name that leads with a noun rather than a verb, and get_law_article_asof adds an as-of suffix that is not mirrored elsewhere, but the overall style remains predictable.

Tool Count5/5

Eleven tools are well-scoped for a Korean public-contract advisory server: three rule calculators, one exemption guide, paired search/retrieval tools, an as-of law lookup, and a feedback/question-log tool. Each tool earns its place, and the count is neither bloated nor too thin.

Completeness4/5

The server covers the main contract lifecycle well: selecting contract method, price escalation, delay penalty calculation, and delay exemption guidance, backed by statutes, references, and caselaw retrieval. Some narrower lifecycle aspects such as termination, sanctions, or post-award administration are only reachable through general search rather than dedicated decision tools, which is a minor gap agents can work around.