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건은 부재의 근거가 아니다. 사용자에게 그 사실을
밝히고 핵심어를 바꿔 재검색하라. 같은 때 `retrieval_degraded:"dense_unavailable"`이
함께 온다(search_references와 같은 이름의 도구 공통 판독값).

**`note_currency`가 있으면 조문의 현행 여부를 우리가 지금 확인하지 못한 상태다
(2026-09-23).** 코퍼스는 오프라인 스냅샷이고 law.go.kr 현행과의 대조가 실패하고
있거나 오래됐다 — `law_currency.last_verified_at`·`days_unverified`가 마지막 성공
대조와 경과일이다. 낡았다는 뜻이 아니라 **모른다**는 뜻이니, 조문을 인용할 때 그
사실을 밝히고 law.go.kr 현행 확인을 권하라. 단 note가 "현행판과 개정 이력이 갈림"이면
모르는 게 아니라 현행판의 후행 시행 개정분이 우리 판에 **빠졌을 수 있음을 아는** 것이다.

Args:
    query: "수의계약", "시행령 제26조", "제21조", "소득세법 제55조" 등
    top_k: 반환 건수 (기본 8, **허용 1~20**). 범위 밖 값은 오류가 아니라 가장
        가까운 허용값으로 **보정**되며(0·음수→1, 20 초과→20) 보정 사실은 응답의
        `top_k_applied`에 요청값·적용값·이유로 공시된다
    corpus: 코퍼스 강제 지정 — "contract"(공공계약) | "tax"(세법). 생략하면 자동.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
top_kNo
corpusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / corpus
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Corpus"
      +}
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Far exceeds what readOnlyHint/idempotentHint/openWorldHint convey: it discloses truncation (truncated/backend_cap), lower-bound totals (total_found_is_lower_bound), degraded semantic search (semantic_unavailable), currency uncertainty (note_currency), and that no_corpus_match does not mean the provision is absent. That is substantive operational context. It loses a point only because the mass of caveats is hard to apply in one pass.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The opening sentence is well front-loaded, but the body is a dense wall of dated changelog annotations, bolded asides, and response-field caveats interleaved with the core instructions. The essential call contract (query, top_k, corpus, then get_law_article) is hard to extract, and several sentences restate the same point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must explain return values — and it explains the corpus/total_found/count/truncated/degraded fields at length, which is a plus. But for a 3-parameter, dual-corpus, degraded-mode search, it omits any statement of result ordering/ranking (relevance vs article order) and what a minimal hit looks like, so an agent cannot predict the response shape beyond individual named fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the parameters — and it does document top_k's 1–20 range with out-of-range clamping to top_k_applied, and corpus values with auto behavior. But `query` gets only example strings with no described semantics (keyword vs article-number vs law-name forms are implied, not specified), leaving the required parameter underspecified for a 0% coverage schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (검색 / return article snippets) and resource (법령 조문), and distinguishes the search step from the follow-up get_law_article. It does not explicitly contrast itself with sibling search_cases or search_references, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use routing: name a tax law → tax corpus, name a 시행령/시행규칙 → restrict to that sub-law, and `corpus` to force a side. It also says when to stop re-searching and go straight to get_law_article via implementing_articles. The one gap is no explicit statement of when to prefer another sibling search entirely.

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.