Skip to main content
Glama
woongaro

Legal Search MCP

by woongaro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Legal Search MCP

한국 법제처 법령정보 API를 활용한 MCP(Model Context Protocol) 서버입니다. AI 에이전트가 한국 법령을 검색하고 조문 내용을 조회할 수 있도록 지원합니다.

기능

🔍 search-law

법령을 검색합니다.

파라미터

타입

필수

설명

query

string

✅

검색 키워드 (예: "자동차관리법", "개인정보")

searchType

enum

-

name: 법령명 검색(기본), content: 본문 검색

lawStatus

enum

-

current: 현행, scheduled: 시행예정, history: 연혁, all: 전체

display

number

-

결과 개수 (기본: 20, 최대: 100)

page

number

-

페이지 번호 (기본: 1)

sort

enum

-

lasc/ldes: 법령명순, dasc/ddes: 공포일순, efasc/efdes: 시행일순

org

string

-

소관부처 코드 (예: "1613000"=국토교통부)

📖 get-law-detail

법령의 상세 내용(조문)을 조회합니다.

파라미터

타입

필수

설명

lawId

string

⚡

법령 ID (search-law 결과에서 확인)

mst

string

⚡

법령 마스터 번호

efYd

string

조건부

시행일자 (mst 사용시 필수, 형식: YYYYMMDD)

articleNumber

string

-

특정 조문 번호 (6자리: 조번호4자리+가지번호2자리)

⚡ lawId 또는 mst 중 하나는 반드시 입력해야 합니다.

Related MCP server: e-Gov Law MCP Server

설치

# 의존성 설치
npm install

# 빌드
npm run build

설정

환경 변수

.env.example을 .env로 복사하고 법제처 API 인증 정보를 설정합니다.

cp .env.example .env
# 법제처 API OC 값 (이메일 ID 부분)
# 예: g4c@korea.kr → LAW_API_OC=g4c
# 주의: https://open.law.go.kr 에서 IP 등록이 완료된 환경에서만 작동합니다.
LAW_API_OC=your_email_id_here

⚠️ 중요: 법제처 API는 IP 기반 접근 제어를 수행합니다. API를 호출하는 서버(또는 로컬 PC)의 IP가 국가법령정보센터 Open API 관리 페이지에 등록되어 있어야 합니다.> 💡 법제처 API는 별도 인증 키 없이 이메일 ID(OC)만 입력하면 사용할 수 있습니다.

연결 및 기능 검증

설정 후 아래 명령어로 API 연결과 기능이 정상 작동하는지 확인할 수 있습니다.

npm test

MCP 클라이언트 설정

Cursor / Claude Desktop

~/.cursor/mcp.json 또는 claude_desktop_config.json에 추가:

{
  "mcpServers": {
    "legal-search": {
      "command": "node",
      "args": ["/path/to/legal-search-mcp/dist/index.js"],
      "env": {
        "LAW_API_OC": "your_email_id"
      }
    }
  }
}

npx로 실행 (개발용)

npx @modelcontextprotocol/inspector dist/index.js

사용 예시

법령 검색

"자동차관리법" 검색해줘
국토교통부 소관 법령 중 "도로"가 포함된 법령 찾아줘

법령 상세 조회

자동차관리법(법령ID: 1747)의 전체 내용 보여줘
자동차관리법 제3조 내용만 조회해줘

개발

# 개발 모드 (TypeScript 감시)
npm run dev

# MCP Inspector로 테스트
npm run inspector

라이선스

MIT License

참고

배포 및 공유 방법

1. GitHub에 배포하기 (소스 코드 공유)

소스 코드를 GitHub에 올려 다른 사람들과 공유하거나, 다른 컴퓨터에서 git clone하여 사용할 수 있습니다.

  1. GitHub에서 새 레포지토리(Repository) 생성 (예: legal-search-mcp)

  2. 로컬 프로젝트를 GitHub에 연결 및 푸시:

# git 초기화 (이미 되어 있다면 생략)
git init

# 파일 추가 및 커밋
git add .
git commit -m "Initial commit"

# 원격 저장소 연결 (URL은 본인의 레포지토리 주소로 변경)
git remote add origin https://github.com/YOUR_USERNAME/legal-search-mcp.git
git branch -M main
git push -u origin main

2. NPM에 배포하기 (패키지 공유)

NPM에 배포하면 npx 명령어로 누구나 설치 없이 바로 실행할 수 있습니다. (NPM 계정 필요)

  1. package.json의 name이 유니크한지 확인 (이미 누가 쓰고 있다면 변경 필요)

  2. NPM 로그인 및 게시:

# NPM 로그인
npm login

# 패키지 게시
npm publish --access public

사용법 (배포 후):

npx your-package-name

(물론 .env 설정이나 환경 변수 주입은 필요합니다.)

3. Docker로 실행하기 (권장)

Docker를 사용하면 환경 설정 없이 바로 실행할 수 있습니다.

1. 이미지 빌드

docker build -t legal-search-mcp .

2. 실행 (테스트)

docker run -e LAW_API_OC="본인_OC_코드" legal-search-mcp

3. Claude Desktop 설정 (Docker 사용)

claude_desktop_config.json에 다음과 같이 추가합니다:

{
  "mcpServers": {
    "legal-search-docker": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e", "LAW_API_OC=본인_OC_코드",
        "legal-search-mcp"
      ]
    }
  }
}

4. 상시 실행 (PM2 사용)

로컬 컴퓨터에서 서버를 끄지 않고 계속 실행해두고 싶다면 pm2를 사용할 수 있습니다.

npm install -g pm2
npm run build
pm2 start dist/index.js --name "legal-search-mcp"

Available Tools

2 tools
get-law-detailB

특정 법령의 상세 내용(조문)을 조회합니다. 법령 ID 또는 법령 마스터 번호로 조회할 수 있습니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
mstNo법령 마스터 번호. lawId 또는 mst 중 하나 필수.
efYdNo시행일자 (mst 사용시 필수, 형식: YYYYMMDD. 예: '20231001')
lawIdNo법령 ID (search-law 결과에서 확인. 예: '1747'=자동차관리법). lawId 또는 mst 중 하나 필수.
articleNumberNo특정 조문 번호 (6자리: 조번호4자리+가지번호2자리. 예: '000200'=2조, '001002'=10조의2)

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits, but it only states the basic function. It implies a read-only lookup ('조회') but does not mention any side effects, error conditions, authentication requirements, or rate limits.

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 two short sentences, front-loaded with the core action, and contains no filler or redundant information. Every word contributes to clarifying the tool's purpose.

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

Completeness3/5

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

The tool has four parameters with conditional requirements and no output schema. The description gives a high-level overview but omits usage context such as the need to have a lawId from search-law or the conditional need for efYd. It is adequate but relies heavily on the schema for operational details.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal meaning by mentioning the two identifier modes (lawId or mst), but does not elaborate on conditional requirements (e.g., efYd required with mst) beyond what the schema already provides.

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?

The description clearly states the tool retrieves detailed content (articles) of a specific law, using a law ID or master number. It provides a specific verb (조회/retrieve) and resource (법령 상세 내용), but does not explicitly contrast with the sibling tool 'search-law'.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus 'search-law'. It only states what it does and the lookup methods, without mentioning prerequisites (e.g., use search-law first) or when to prefer one identifier over the other.

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

search-lawB

한국 법령을 검색합니다. 법령명이나 본문 내용으로 검색할 수 있습니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
orgNo소관부처 코드 (예: '1613000'=국토교통부)
pageNo페이지 번호 (기본: 1)
sortNo정렬: lasc/ldes=법령명순, dasc/ddes=공포일순, efasc/efdes=시행일순
queryYes검색할 법령명 또는 키워드 (예: '자동차관리법', '개인정보')
displayNo검색 결과 개수 (기본: 20, 최대: 100)
lawStatusNo법령 상태: 'current'=현행, 'scheduled'=시행예정, 'history'=연혁, 'all'=전체
searchTypeNo검색 범위: 'name'=법령명 검색(기본), 'content'=본문 검색

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only mentions the ability to search by name or content, which is already present in the searchType parameter of the schema. It does not disclose whether the operation is read-only, the response format, pagination behavior, or any side effects. This is a minimal disclosure that adds little beyond the schema.

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 two short, clear sentences in Korean. It front-loads the core purpose and uses no unnecessary words. Every word earns its place, making it highly concise and well-structured.

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

Completeness2/5

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

Given the tool has 7 parameters, 3 enums, no annotations, and no output schema, the description is too sparse. It does not explain the typical search workflow (e.g., that results can be followed up using get-law-detail), nor does it clarify return behavior or default settings. The description only conveys the basic search capability, leaving the agent without enough context for effective invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so all 7 parameters are already documented with descriptions. The tool description adds no additional parameter semantics beyond restating that searching by law name or content is possible, which mirrors the searchType parameter. The baseline of 3 applies because the schema does the heavy lifting.

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?

The description clearly states the tool searches Korean laws and specifies the two search modes (by law name or content). This is a specific verb+resource pairing and implicitly distinguishes it from the sibling tool get-law-detail, which presumably retrieves details of a specific law.

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 description implies the tool should be used for searching laws, but it provides no explicit guidance on when to prefer this tool over get-law-detail, nor does it mention any exclusions or prerequisites. The context signal shows get-law-detail as a sibling, but the description itself does not reference it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedget-law-detail
    • First observedsearch-law
Deploy Server
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

TDQS

A3.6/5.0

Scored across 2 tools

Disambiguation5/5

search-law and get-law-detail have clearly distinct roles: the former finds laws by query, the latter retrieves specific articles by ID. No overlap in functionality.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern with hyphen separation: search-law and get-law-detail. Predictable and readable.

Tool Count3/5

Only two tools, which is on the thin side. While they cover the essential search-and-retrieve workflow, the small number may limit broader legal research tasks.

Completeness5/5

For a legal search server, the two tools provide a complete workflow: search for relevant statutes and retrieve their detailed provisions. No evident dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • open-assembly-mcp

    kyusik-yang
    A
    license
    A
    quality
    D
    maintenance
    MCP server for the Korean National Assembly Open API, enabling querying of bills, members, votes, committees, and more via natural language.
    20
    Apache 2.0

  • Korea Housing MCP

    doorijaehyuk
    F
    license
    Not graded
    quality
    C
    maintenance
    This MCP server integrates South Korea's national law information, building registers from MOLIT, and KOSIS statistics for housing development research. It enables searching laws, retrieving building details, and accessing statistical data through natural language.
    -

  • Korean Law MCP Server

    woongaro
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables searching and retrieving Korean statutes, precedents, and constitutional court decisions via MCP, using the National Law Information Center API.
    4,664 npm
    1
    MIT