legal-search-mcp

statute_lookup

Read-onlyIdempotent

Retrieve the exact text of Korean statutes and administrative rules by searching name, keyword, or ID, then selecting specific articles. Optionally specify an offense date to get the version in force at that time.

Instructions

법령·행정규칙 조회 — 법령의 요건·효과·기간·절차가 답의 뼈대가 되는 국면의 기본 도구이며, 죄명·법조 식별 후 조문 본문 확인에도 씁니다. 조문은 개정되므로 현행 본문은 이 도구만 압니다. 법률·대통령령·부령·규칙과 행정규칙(고시·훈령·예규)을 한 번에 검색합니다 — 종류를 가리는 인자는 없고 관련도 순으로 함께 나오며 각 결과에 종류가 붙습니다. 자주 쓰는 법령은 quick-access id로 바로 호출(statute_id+articles): 헌법 468·민법 584·상법 583·민사소송법 581·형법 578·형사소송법 574·행정기본법 4953·행정절차법 437·행정소송법 386·헌법재판소법 3629. query 또는 statute_id가 필수. 그 외는 two-step — ① query=법령명으로 후보 id를 받고 ② statute_id+articles로 본문 호출(조문 번호는 법령마다 달라 법령을 먼저 확정). Args: query=법령명·행정규칙명 또는 본문 키워드(id 모를 때). statute_id=검색이 준 식별자를 글자 그대로 — 법령은 정수(예 584; 위 목록 밖은 추측 금지 — 574는 형사소송법), 행정규칙은 'admrul-18060'. 접두사를 떼면 같은 번호의 다른 법령이 조회됩니다. articles=조문 번호 list[str] 최대 8개('347'/'제347조'=본조+가지, '347의2'=가지만, 범위 ['3','4','5']; 미지정 시 outline; 8개 초과는 앞 8개만 조회하고 나머지를 message로 알림 — 나눠 재호출). limit=검색 모드 최대 결과 수(기본 10·최대 50). offense_date=행위 일자(예 '2013.7.30') 지정 시 행위시점 조문, 미지정 시 현행. url만 인용 링크로 쓰고, text_kind: 공식 … 원문인 조문·행정규칙 본문만 직접인용하세요.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`articles`	No
`statute_id`	No
`offense_date`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral detail beyond that: statutes are amended so only this tool knows current text, offense_date switches to the version in force at the time of the act, partial article-number prefix matching behavior, the 8-article truncation notice, and the warning that removing prefixes can fetch a different statute.

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?

The description is long but every sentence carries operational value: purpose, scope, quick-access IDs, workflow, parameter semantics, and citation rules. It is front-loaded with the tool's role and then moves systematically through usage, and the dense content is justified by the tool's complexity.

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?

Given 5 parameters, no required fields, an output schema, and complex interaction rules between query and statute_id, the description covers all necessary decision points: mode selection, article number syntax, result limits, time-based statute versions, and even citation/quoting constraints. An agent has enough information to invoke correctly in both search and article-lookup modes.

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 description coverage is 0%, so the description carries the full burden. It thoroughly explains query, statute_id (including integer vs 'admrul-18060' forms and the prefix hazard), articles syntax with examples like '347의2' and ranges, limit defaults/max, and offense_date format and semantics. This far exceeds what the bare schema provides.

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?

Description opens with a specific verb and resource: '법령·행정규칙 조회' and explains exactly when this is the basic tool — when statutory requirements, effects, periods, or procedures form the backbone of the answer. It also covers identification of criminal provisions then checking article text, which clearly differentiates it from sibling precedent-search and sentencing tools.

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?

Provides rich usage context: two-step workflow, quick-access IDs, when to use query vs statute_id, and constraints such as needing to confirm the statute first because article numbering differs per statute. It does not explicitly name sibling tools as alternatives or state when not to use this tool, so it stops short of a 5.

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

Deploy Server