Retrieve one Korean legal source—precedent, ruling, interpretation, rule, ordinance, or treaty—by section, with full, digest, or keyword modes and structured cited references.
판례·결정례·해석례·심판례·행정규칙·자치법규·조약의 본문 1건을 섹션별 전문으로 가져온다(mode=digest 는 원문 문장 발췌, keywords 는 법령명·용어 빈도). 참조조문·참조판례를 구조화해 돌려준다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| mode | No | full | |
| part | No | 이어받기 번호 | |
| caseNo | No | 판례 사건번호(정확 일치) | |
| source | Yes | ||
| maxBytes | No | 응답 예산(바이트) | |
| sections | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint already establishes the safe-read profile, and the description adds real context beyond it: the three mode behaviors (full text vs. sentence excerpt vs. law-name/term frequency) and the fact that cross-referenced provisions and precedents are returned structured. It does not, however, disclose pagination behavior (the part continuation parameter) or output size handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the verb and resource front-loaded, and no filler. Dense but well-organized, though the parenthetical mode explanation is slightly buried mid-sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a seven-parameter read tool with no output schema, the description covers modes and the return of structured cross-references, which is the most important behavioral detail. It leaves notable gaps: how to obtain the id, what the 20 source values mean, and how the part/maxBytes budget interact across pages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43%, so the schema carries part of the load (part, caseNo, maxBytes are documented). The description usefully supplies the semantics of the mode enum values, which the schema leaves bare, but it says nothing about the 20-value source enum, the id field, or the sections array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (가져온다/fetches) plus a precise resource (본문 1건, the full text of a single document) and enumerates the document categories it serves. It implicitly distinguishes itself from source_search by fetching one item rather than searching, but it never names a sibling, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of alternatives such as source_search (to find the id) or article_get (for a single article). The mode glosses hint at selection between modes, but nothing routes the agent between this tool and its ten siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.