Skip to main content
Glama

contract-compass

by app.sallim

판례·해석례 본문

get_case
Read-onlyIdempotent

판례/해석례 본문 조회 — 판시사항·판결요지·참조조문(판례) 또는 질의요지·회답·이유(해석례).

응답의 `source_url`은 국가법령정보센터 원문 주소다 — 판례·해석례를 인용할 때는
**이 링크를 함께 제시하라**(감사·보고서에서 근거를 되짚을 수 있어야 한다).

**`error:"case_body_unavailable"`이면 `source_url`은 null이고 `existence_verified`는
false다**(2026-09-04). 이건 "본문만 없다"가 아니다 — 우리는 ①본문 미제공(하급심·
국세청 등 타기관 제공)과 ②그런 일련번호가 없음을 **구분하지 못한다**(본문 API 응답이
같다). 그러니 **링크를 만들어 채우지 마라**: law.go.kr 뷰어는 없는 번호에도 200과 빈
페이지를 주므로 열린다는 것이 존재의 증거가 아니다. 이 case_id가 search_cases 결과에서
온 것이면 그 결과의 사건명·사건번호·source_url만 인용하고, 아니면 아무것도 인용하지
말고 search_cases로 다시 찾아라.

Args:
    kind: "prec" | "expc" (search_cases 결과의 kind)
    case_id: search_cases 결과의 case_id

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
case_idYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

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

TDQS

A4.9/5.0
Behavior5/5

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

Discloses the error behavior in detail: error:"case_body_unavailable" means source_url is null and existence_verified is false, and that the tool cannot distinguish a missing body from a nonexistent ID. It also explains that law.go.kr returns 200 for nonexistent IDs, so an open link is not proof of existence.

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?

Front-loaded with the purpose, then organized into clear paragraphs covering source_url, error behavior, and fallback rules. Every sentence earns its place, especially the warning about not fabricating links.

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 what the response contains, the meaning of key fields, the error case, and the correct action when the body is unavailable. The tool's complexity is high, and the description addresses the main pitfalls an agent would face.

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

Parameters4/5

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

Schema coverage is 0%, so the Args section carries the burden. It explains that kind must be 'prec' or 'expc' from search_cases results and that case_id comes from search_cases. It could expand the abbreviations or give an example, but it adds the critical provenance semantics.

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 the exact operation ('판례/해석례 본문 조회') and enumerates the content types returned for each case kind. The title and first line make it easy to distinguish from siblings like search_cases or get_law_article.

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?

Provides concrete guidance: use case_id from search_cases results, cite only the search_cases fields when the body is unavailable, and fall back to search_cases when the ID is not from that source. It also tells the agent when not to fabricate source_url links.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All contract-compass toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: deterministic rule engines for contract method, price adjustment, and delay penalties; separate search tools for statutes, cases, and administrative references; and get_law_article_asof provides a unique temporal capability. Even the three search tools are cleanly differentiated by corpus and result type.

Naming Consistency4/5

The vast majority follow a verb_noun snake_case pattern (check_, decide_, estimate_, get_, report_, search_). delay_exemption_guide breaks the verb-first convention, but the naming style is consistent and readable.

Tool Count5/5

With 11 tools, the server is well-scoped for Korean public contract law advisory. The set balances three rule engines, five reference/lookup tools, one temporal variant, one reporting tool, and no redundant additions.

Completeness4/5

The tool set covers core contract lifecycle determinations—method selection, price escalation, delay penalties, and exemption grounds—and provides comprehensive legal research including historical law versions. Some lifecycle areas like termination or bidder sanctions lack dedicated rule engines, but they are accessible through the search and law-article tools.

Resources