lawmadi-os

by io.github.peter120525-cmd

lookup_statute

[NO KEY · preview depth, 1/day] 한국 법령 조문을 조회합니다. 먼저 검증 자산(31,834개 조문, 본문 포함)을 보고, 없으면 law.go.kr 정본 색인(현행 법령 전수)으로 그 조문이 실재하는지 판정합니다. 정본 색인 경로는 본문을 갖고 있지 않으므로 실재 여부와 law.go.kr 링크만 돌려줍니다 — 본문을 지어내지 않습니다. 그 법령을 결번 없이 아는 경우에는 없다는 것도 말합니다(absent=true). LLM 미호출·결정론. 입력 예: '민법 제750조', '형법 제307조 제1항'. / Look up a Korean statute article in Lawmadi's verified-asset corpus (31,834 articles). Returns the article title, body text and law.go.kr link. Deterministic — no LLM. Callable without an API key at preview depth (title + law.go.kr link + first 200 chars of the body); a key unlocks the full article body. / 키 없이도 미리보기 깊이로 조회됩니다 — 조문 본문 전문은 키 발급 후 제공됩니다.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "reference": "<reference>"
    },
    "name": "lookup_statute"
  }
}

Input Schema

Name	Required	Description	Default
`reference`	Yes	Statute reference. Example: '민법 제750조'.
`client_tag`	No	선택. client_tag: 호출자 식별용, 응답에 영향 없음(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 23, 2026

addedInput schema / properties / client_tag

Added value: +{
+  "description": "선택. client_tag: 호출자 식별용, **응답에 영향 없음**(8~64자, 영숫자·_-.). 서버 로그에만 남아 호출을 골라 세는 데 씁니다. 형식이 어긋나면 무시합니다 — 거절하지 않습니다. 질의 본문에 섞지 마세요: 본문에 넣으면 질문의 일부가 되어 분류와 검증 결과가 달라집니다. / Optional caller label (8-64 chars). Logged only; never affects the response. Invalid values are ignored, not rejected. Do not put it in the query text — there it becomes part of the question.",
+  "type": "string"
+}

AddedAug 11, 2026

TDQS

A3.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it discloses the preview-depth truncation (first 200 chars), the 1/day unauthenticated quota, the no-LLM deterministic behavior, the explicit no-fabrication guarantee, and the absent=true signal for laws known to have no such article. These are exactly the non-obvious traits an agent needs before calling.

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

Conciseness3/5

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

The leading bracketed marker front-loads the key constraint well, but the body restates the same preview-depth limitation three times across Korean, English, and a closing Korean sentence, which is pure duplication. The bilingual format is defensible, but the third restatement is dead weight.

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

Completeness4/5

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

There is no output schema and no annotations, yet the description explains return shape (title, body, link, absent flag), truncation depth, and the quota, which is close to sufficient. It stops short of describing error or ambiguity behavior for a malformed or ambiguous reference, which is the one remaining gap.

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 100%, so the baseline is 3, and the description adds value by supplying multiple reference-format examples ('민법 제750조', '형법 제307조 제1항') that go beyond the schema's single example. The client_tag parameter is fully documented in the schema itself and needs no further explanation.

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 and resource (look up a Korean statute article) and enumerates the returned fields: title, body text, and law.go.kr link. It also explains the two-tier resolution (verified corpus first, then law.go.kr canonical index), which sets it apart from lookup_precedent. However, it never names or contrasts itself with the sibling verify_citations, even though the existence-check path overlaps with that tool's apparent job.

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

Usage Guidelines3/5

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

The usage context is implied by the examples ('민법 제750조', '형법 제307조 제1항') and by the note that a key unlocks the full body, so an agent can infer this is for fetching statute text. But the fallback order described is internal behavior, not tool-choice guidance, and no sibling alternative (e.g. verify_citations for pure existence checks) is named or excluded.

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

All lawmadi-os tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?