Skip to main content
Glama

판례·해석례 검색

search_cases
Read-onlyIdempotent

판례·법령해석례 검색 — law.go.kr 실시간 조회(항상 현행). LLM 미사용.

분쟁·처분취소·해석 다툼("~해도 되나", "~취소될 수 있나")에 조문만으로 부족할 때
쓰라. 본문은 get_case(kind, case_id)로 이어서 조회.

**응답은 무엇으로 몇 건을 봤는지까지 말한다**(2026-08-29). `search_scope`가
"title"이면 사건명·안건명만, "body"면 본문까지 본 것이다. `searched`에 시도한
질의·범위·law.go.kr 총계(`total_cnt`)가 시도 순서대로 실리고, 넓혀서 다시 찾았으면
`retried`가 true다. **0건은 "그런 판례가 없다"가 아니라 "이 범위에서 못 찾았다"이다**
— 사용자에게 옮길 때 `searched`가 밝힌 범위를 함께 말하고 "판례가 없다"고 단정하지 마라.

**응답에 `axis`가 있으면 축·원장의 경계가 걸린 것이다**(2026-09-02). 세법 축
질의인데 사건명·안건명 그대로는 못 찾아 **넓혀 찾은** 종류가 있을 때만 실리고,
`axis.gated_kinds`가 그 종류를 말한다. `axis.out_of_axis`는 넓히다 **다른 축의
사건이 섞여 우리가 뺀 것**이다 — 세법 근거로 인용하지 마라(판례는 판정 근거인
`case_type`·`data_source`가 항목마다 붙는다).

**두 종류의 경계가 서로 반대라는 것을 혼동하지 마라.**
· `axis.yegyu_in_corpus: false` — 세무 실무가 말하는 '예규'(국세청 서면질의 회신,
  txsi)를 이 서버가 **아예 담지 않는다**(법제처 expc와 원장이 다르다). "예규가
  없다"고 옮기지 말고 국세법령정보시스템으로 안내하라.
· `axis.prec_in_corpus: true` — **판례는 담고 있다**. 여기서 뺀 것은 원장이 비어서가
  아니라 사다리가 넓히다 민사·형사 사건을 끌어온 것뿐이니, "세법 판례가 없다"로
  옮기면 틀린 말이다. 남은 판례가 0건이면 '이 사다리로는 못 찾았다'로 전하라.

**응답에 `off_topic_warning`이 있으면 낱말만 같고 쟁점이 다를 수 있다**(2026-09-10).
**세법 질의로 판정되지 않았는데**(`axis_verdict.axis`: `contract`=공공계약 축이 더 가깝다 ·
`not_tax`=세법 축 문턱 밖일 뿐 공공계약과 견주지는 않았다) 받은 회수분이 **전부 세법 원장
소산**(국세·지방세법령정보시스템, 사건종류 '세무')일 때 붙는다 — 예: '유찰'은 공공계약에서
입찰 불성립이지만 세법에서는 공매 절차다. **빼지 않고 남긴 것**이니(빼면 0건이 되어
'판례가 없다'는 거짓이 된다) 공공계약 근거로 인용하기 전에 get_case로 본문·참조조문을
읽어 쟁점이 같은지 확인하고, 다르면 사용자에게 "공공계약 판례는 이 범위에서 못 찾았다"고
밝혀라. `evidence`가 판정 근거다.
**본 것만큼만 말한다**(2026-09-11): '전부 세법'은 받은 `judged_on`건의 판정이다 —
`unseen_cnt`>0(`truncated: true`)이면 law.go.kr 총 `ledger_total`건 중 나머지는 안 봤으니
"원장에 그것뿐"이나 "이 질의의 판례는 전부 세법"이라 옮기지 마라(`unseen_cnt: 0`일 때만
이 범위에서 본 것이 전부다, null이면 총계를 모른다). **축을 못 쟀으면**(임베딩 장애 등)
경고 대신 `axis_unjudged`가 같은 모양으로 붙는다 — 주제이탈도 세법 정답도 단정하지 않은
것이니, 사용자 질문의 쟁점이 어느 쪽인지 네가 판단해 인용 여부를 정하라.

Args:
    query: 핵심 명사 위주 검색어 (예: "부정당업자 제한", "유찰 수의계약").
        **2자 이상 100자 이하**(공백 제외 2자 미만이면 `query_too_short` 오류 —
        한 글자 질의는 받지 않는다. 넘치면 `query_too_long`). 자연어 한 문장도
        받는다 — 사건명으로 0건이면 핵심어·본문 범위로 자동 재시도한다(최대 2회).
    top_k: 종류당 반환 건수 (기본 5, **허용 1~10**). 범위 밖 값은 오류가 아니라
        **가장 가까운 허용값으로 보정**된다(0·음수→1, 10 초과→10). 보정했으면
        응답의 `top_k_applied`에 요청값·적용값·이유를 실어 공시하므로, 건수가
        요청과 다르면 그 필드를 읽어라.
    kind: "prec"(법원 판례) | "expc"(법제처 법령해석례) | "all"(둘 다, 기본)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoall
queryYes
top_kNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / kind / enum
      Added value: +[
      +  "prec",
      +  "expc",
      +  "all"
      +]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover readOnly/openWorld/idempotent, and the description adds extensive context beyond them: real-time always-current semantics, response structure (search_scope, searched, retried, total_cnt), the crucial 0-results interpretation rule ('이 범위에서 못 찾았다' not '없다'), axis boundary semantics (yegyu_in_corpus vs prec_in_corpus), off_topic_warning with axis_verdict.axis values, unseen_cnt/truncated/ledger_total, and axis_unjudged fallback. No contradiction with annotations — the description fully honors readOnly (search) and openWorld (0 results = not found in scope) hints.

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?

Information-dense with purpose front-loaded and every sentence earning its place — no fluff. The dated changelog headers (2026-08-29, 2026-09-02, etc.) are structurally unusual and read like internal dev notes rather than user-facing docs, adding clutter an agent doesn't need to call the tool correctly. The logical organization (purpose → usage → response semantics → parameters) is sound, but the dated scaffolding costs it a point.

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?

For a tool with 3 params, no output schema, and complex response semantics (axis boundaries, off_topic warnings, unseen counts), the description is remarkably complete. It covers what it does, when to use it, all parameter constraints, response field semantics, edge-case interpretation rules, and the follow-up tool. With no output schema present, the description rightly carries the full burden of return-value explanation, and it does so thoroughly — nothing an agent needs to call it correctly 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%, and the description fully compensates. query: explains keyword-based, 2-100 char constraint with specific error names (query_too_short/query_too_long), natural language acceptance, and auto-retry up to 2 times. top_k: documents default 5, allowed 1-10, clamping behavior for out-of-range values (0/negative→1, >10→10), and the top_k_applied disclosure field. kind: explains each enum value ('prec'(법원 판례), 'expc'(법제처 법령해석례), 'all'). This is comprehensive compensation for zero schema coverage.

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?

Opening states a specific verb+resource: '판례·법령해석례 검색 — law.go.kr 실시간 조회(항상 현행)'. It names the follow-up tool get_case(kind, case_id) for full text, distinguishing this search tool from the retrieval tool. The scope (precedents + legal interpretations from law.go.kr, always current) is unmistakable and separates it from siblings like search_law and search_references.

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?

Explicit when-to-use: '분쟁·처소취소·해석 다툼("~해도 되나", "~취소될 수 있나")에 조문만으로 부족할 때 쓰라' — clear triggering conditions. It also names get_case as the follow-up for full text. However, it doesn't explicitly name search_law or search_references as alternatives to route away from; the contrast with search_law is implied ('조문만으로 부족할 때') rather than stated. A small gap in exclusion guidance keeps this from a 5.

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.