Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@law-search-mcp search precedents about inheritance tax deduction"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
한국 법령정보센터(law.go.kr) 공식 Open API를 통해 판례를 검색하는 MCP 서버.
Transport: stdio (FastMCP)
Backend: law.go.kr/DRF/lawSearch.do + law.go.kr/DRF/lawService.do
인증: OC 파라미터 (law.go.kr 신청 시 발급되는 사용자 식별자)
cd /data_raid/ruci_workspace/law-search-mcp
uv sync # .venv 생성 + 의존성 설치
echo "LAW_API_OC=your-oc-id" > .env # 실제 값으로 교체 (law.go.kr 신청 시 발급)
.venv/bin/python server.py # MCP stdio 서버 시작~/.claude.json 또는 프로젝트 .mcp.json:
{
"mcpServers": {
"law-search": {
"command": "/data_raid/ruci_workspace/law-search-mcp/.venv/bin/python",
"args": ["/data_raid/ruci_workspace/law-search-mcp/server.py"]
}
}
}Related MCP server: korean-law-mcp
변수 | 필수 | 기본값 | 설명 |
| ✅ |
| law.go.kr OpenAPI 식별자. 발급 신청: https://open.law.go.kr |
search_precedents(query, max_results, page, sort, org, date_range)판례 목록을 키워드로 검색.
파라미터 | 타입 | 기본값 | 설명 |
| str | (필수) | 검색 키워드 (예: |
| int | 20 | 페이지당 결과 수 (최대 100) |
| int | 1 | 페이지 번호 |
| str |
|
|
| str |
| 법원종류코드. |
| str |
|
|
반환: 사건명·법원명·선고일자·사건번호·판례일련번호(precSeq) 포함 목록 텍스트.
get_precedent_detail(precedent_id)특정 판례 상세 본문 조회 (판시사항/판결요지/참조조문/참조판례/판례내용 전문).
파라미터 | 타입 | 설명 |
| str |
|
law.go.kr 공식 OpenAPI의 정책상, get_precedent_detail은 대법원 판결문에 대해서만 전문을 반환합니다. 고등법원·행정법원·지방법원·조세심판원 결정문은 검색 목록에는 나오지만 상세 조회 시 다음과 같이 응답:
{"Law": "일치하는 판례가 없습니다. 판례명을 확인하여 주십시오."}실측 결과 (2026-05-19, query="부당행위계산" org=400201 display=10 기준):
검색 결과 10건 중 법원명="대법원"으로 채워진 건은 1건뿐
그 1건만 상세 조회 성공, 나머지 9건은 모두 위 에러
# 1. 검색 (관련도순 or 날짜순 모두 OK)
results = search_precedents(query="...", max_results=50)
# 2. 응답 텍스트에서 [court='대법원'] 인 항목만 골라낸 뒤
# 그 항목의 판례일련번호로만 detail 조회
# (org=400201 필터를 걸어도 90%는 법원명이 빈 문자열이므로 사후 필터 필수)
# 3. 대법원 외 판례 본문이 필요하다면:
# - 조세심판원/국세청 자료는 별도 데이터셋(예: papers.db) 활용
# - 하급심 판결문은 대법원 종합법률정보(glaw.scourt.go.kr) 등 별도 경로 필요lawSearch.do{
"PrecSearch": {
"totalCnt": 14,
"prec": [
{
"판례일련번호": "241203",
"사건명": "...",
"사건번호": "...",
"선고일자": "20250207", // YYYYMMDD
"법원명": "대법원", // ← 비어있으면 detail 조회 불가 가능성 높음
"사건종류명": "세무",
"판결유형": "...",
"선고": "..."
}
]
}
}prec는 결과가 1건이면 dict, 2건 이상이면 list로 옴 → 코드는 dict→list 변환 처리됨.
lawService.do (성공){
"PrecService": {
"사건명": "...", "사건번호": "...", "선고일자": "...",
"법원명": "대법원", "사건종류명": "...", "판결유형": "...",
"판시사항": "...", "판결요지": "...",
"참조조문": "...", "참조판례": "...",
"판례내용": "..." // 판결문 전문
}
}lawService.do (실패: 대법원 외 ID){ "Law": "일치하는 판례가 없습니다. 판례명을 확인하여 주십시오." }Law wrapper 에러를 빈 결과로 silent failget_precedent_detail() 의 응답 파싱 로직 (server.py:198):
item = data.get("PrecService", data) if isinstance(data, dict) else data응답이 {"Law": "일치하는 판례가 없습니다."} 일 때 fallback인 data 전체가 item이 되고, item.get("사건명", "") 등이 모두 빈 문자열을 반환 → 사용자에게는 "빈 판례 정보"로 보임. 에러 메시지를 명시적으로 surfacing 하는 로직 추가 필요:
# 권장 수정 (server.py:197~ 부근)
if isinstance(data, dict) and "Law" in data and "PrecService" not in data:
return f"오류: 상세 조회 실패 — {data['Law']}\n" \
f"(law.go.kr 상세 API는 대법원 판례만 지원합니다. " \
f"precedent_id={precedent_id}의 법원명을 확인해주세요.)"
item = data.get("PrecService", data).env 설정 후:
.venv/bin/python -c "
import asyncio, httpx
async def t():
async with httpx.AsyncClient(timeout=30) as c:
r = await c.get('http://www.law.go.kr/DRF/lawSearch.do',
params={'OC':'your-oc-id','target':'prec','type':'JSON',
'query':'부당행위계산','display':'3'})
print(r.json()['PrecSearch']['totalCnt'], '건 검색됨')
asyncio.run(t())
"검색 건수가 양수면 정상.
NTS 검색 데이터(papers.db): 조세심판원 결정문·하급심 판례 (289K건) — 이미 보유 중
law-search-mcp 보강 용도:
사용자가 특정 대법원 판례를 지정 인용할 때 풀텍스트 fetch
최신 대법원 판례 (papers.db 크롤 이후 시점) 보강
하급심/심판례 검색: 본 MCP는 검색 메타데이터만 활용, 본문은 papers.db에서 매칭 (사건번호 기준)
판례일련번호(precSeq)로 특정 판례의 상세 내용을 조회합니다.
law.go.kr 공식 Open API를 통해 판례 상세 정보를 반환합니다.
판례일련번호는 search_precedents() 검색 결과에서 확인할 수 있습니다.
반환 정보:
- 사건명, 사건번호, 선고일자, 법원 정보
- 판시사항: 법원이 판단한 주요 법률 쟁점
- 판결요지: 판결의 핵심 내용 요약 (없을 수 있음)
- 참조조문: 관련 법령 조문
- 참조판례: 관련 선례 판례
- 판례내용: 판결문 전문
Parameters:
precedent_id: 판례일련번호 (예: "225429"). search_precedents()로 조회한 번호를 사용합니다.
Returns:
판례의 상세 정보 (판시사항, 판결요지, 판례내용 등 가용한 모든 섹션 포함)
| Name | Required | Description | Default |
|---|---|---|---|
| precedent_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the official API source, lists return sections (including possibility that some may be missing), and implies read-only behavior. It does not disclose rate limits or authentication, but for a read-only detail retrieval tool, this is adequate.
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?
The description is well-structured: a clear purpose sentence, followed by data source, prerequisite (search), return sections, and parameter details. Every sentence serves a purpose, and the most important information is front-loaded.
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 tool with one parameter, no enums, and an output schema, the description provides complete context: how to invoke, what to expect as input and output, and the relationship to its sibling tool. It even notes potential absence of certain return fields.
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?
With 0% schema description coverage, the description compensates by explaining the parameter in detail: its meaning ('판례일련번호'), an example value, and how to obtain it ('search_precedents()로 조회한 번호를 사용합니다'). This adds significant value beyond the bare schema.
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 clearly states the verb ('조회합니다' - retrieve), the resource ('특정 판례의 상세 내용' - specific precedent details), and the key parameter (판례일련번호/precedent_id). It also distinguishes from the sibling tool search_precedents by noting that the ID comes from search results.
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?
The description specifies when to use the tool: when a precedent_id is available from search_precedents() results. It explains what it returns but does not explicitly mention when not to use it or provide alternative usage scenarios, though the context with the sibling is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한국 법원 판례 목록을 키워드로 검색합니다.
law.go.kr 공식 Open API를 통해 판례를 검색하고 기본 정보 목록을 반환합니다.
검색 결과에는 사건명, 법원 및 선고 정보, 판례일련번호(precSeq)가 포함됩니다.
판례일련번호를 사용하여 get_precedent_detail()로 상세 내용을 조회할 수 있습니다.
Parameters:
query: 검색 키워드 (예: "손해배상", "계약해제", "부당해고")
max_results: 최대 결과 수 (기본값: 20, 최대 100)
page: 페이지 번호 (기본값: 1)
sort: 정렬 기준 (예: "date" 선고일자순, 기본값: 관련도순)
org: 법원종류코드 (예: "400201" 대법원, 빈 문자열이면 전체)
date_range: 선고일자 범위 (형식: YYYYMMDD~YYYYMMDD, 예: "20200101~20231231")
Returns:
검색된 판례 목록 (사건명, 법원/선고 정보, 판례일련번호 포함)
판례일련번호로 get_precedent_detail(precedent_id)를 호출하면 상세 내용을 조회할 수 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No | ||
| page | No | ||
| sort | No | ||
| org | No | ||
| date_range | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It mentions using a public API and returning a list of basic information, indicating a read-only operation. It does not discuss rate limits or authentication, but for a search tool, the core behavior is clear and no contradictions exist.
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?
The description is well-organized: a brief purpose statement, then source and output explanation, then a labeled parameter list. Some repetition occurs (serial number usage mentioned twice), but it remains concise and front-loaded with key information.
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?
Given 6 parameters, no schema descriptions, and an output schema, the description covers the essential aspects: each parameter, example values, and the output structure. It connects to the sibling tool. However, it could be more complete by clarifying pagination behavior or error handling, but it is adequate for a search tool.
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 0%, so the description fully compensates by listing each parameter with examples and default values. It explains query, max_results, page, sort, org, and date_range with concrete usage hints, adding meaning well beyond the bare schema.
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?
Description clearly states the tool searches Korean court precedents by keyword, specifying the source (law.go.kr official API) and the returned information (case name, court, serial number). It explicitly differentiates from sibling get_precedent_detail by indicating that the serial number can be used for detailed lookups.
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?
The description provides clear context on when to use this tool (for keyword-based searches) and implies that get_precedent_detail should be used for full details. It does not explicitly state when not to use it, but the differentiation is sufficient for an agent to understand the tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_precedent_detailsearch_precedentsScored across 2 tools
The two tools have clearly distinct purposes: search_precedents for listing/searching and get_precedent_detail for retrieving full details of a specific precedent. No functional overlap.
Both tool names follow a consistent verb_noun pattern (search_precedents, get_precedent_detail) using snake_case, making them predictable and easy to understand.
With only 2 tools, the server covers the core workflow (search and detail retrieval) but feels slightly minimal compared to typical MCP servers that often include additional utilities or filtering options.
The tools adequately support search with multiple filters and detail retrieval, covering the primary use case. However, missing features like pagination control for detail views or batch retrieval are minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Resolve, search and verify legal citations against the official sources, with provenance.
Case law search, court decisions and súmulas, across indexed public sources (STF, STJ, TST, state co
Search US court opinions, federal dockets, judges, citations, and oral arguments via CourtListener.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/memorise8/law-search-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
