Skip to main content
Glama
scvcoder

korean-privacy-law-mcp

by scvcoder

search_law

Search Korean statutes by name, keyword, or abbreviation. Retrieve metadata and full text of privacy and general laws.

Instructions

법령 검색 (법제처 lawSearch · target=law). 법령명·메타데이터(소관부처·시행일) 조회. 약칭(개보법·정통망법 등) 자동 인식. 본 MCP는 개인정보 분야 우선이지만 일반 법령 검색도 가능. 다음: get_law_text(mst)로 본문, get_related_laws(lawId)로 관계 조회.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes법령명·키워드. 약칭(개보법·정통망법·신정법·위치정보법·통비법 등) 자동 인식 후 검색.
displayNo결과 개수 (기본 100, 짧은 법령명 후순위 quirk 회피)
pageNo페이지 번호 (기본 1)
sortNo정렬: lasc/ldes(법령명 오/내림), dasc/ddes(날짜 오/내림)

Implementation Reference

  • Main handler implementation for the search_law tool. Takes a query (with alias resolution), calls the lawSearch.do API endpoint, parses the XML response into LawItem objects, formats results with metadata (관리부처, 시행일, 공포일), and provides suggestions for follow-up tools (get_law_text, get_related_laws, get_annexes).
    export const searchLaw: Tool<typeof inputSchema> = {
      name: "search_law",
      description:
        "법령 검색 (법제처 lawSearch · target=law). 법령명·메타데이터(소관부처·시행일) 조회. " +
        "약칭(개보법·정통망법 등) 자동 인식. 본 MCP는 개인정보 분야 우선이지만 일반 법령 검색도 가능. " +
        "다음: get_law_text(mst)로 본문, get_related_laws(lawId)로 관계 조회.",
      inputSchema,
    
      async handler(args, client) {
        try {
          const resolvedQuery = resolveLawAlias(args.query);
          const xml = await client.fetchApi({
            endpoint: "lawSearch.do",
            target: "law",
            extraParams: {
              query: resolvedQuery,
              display: String(args.display),
              page: String(args.page),
              ...(args.sort ? { sort: args.sort } : {}),
            },
          });
    
          const result = parseSearchXML<LawItem>(xml, "LawSearch", "law", (itemXml) => ({
            법령일련번호: extractTag(itemXml, "법령일련번호"),
            법령ID: extractTag(itemXml, "법령ID"),
            법령명한글: extractTag(itemXml, "법령명한글"),
            소관부처명: extractTag(itemXml, "소관부처명"),
            법령구분명: extractTag(itemXml, "법령구분명"),
            공포일자: extractTag(itemXml, "공포일자"),
            시행일자: extractTag(itemXml, "시행일자"),
          }));
    
          if (result.totalCnt === 0) {
            const aliasNote =
              resolvedQuery !== args.query ? ` (정규화: "${resolvedQuery}")` : "";
            return notFoundResponse(`법령 검색 결과 없음: "${args.query}"${aliasNote}`, [
              `intelligent_law_search(query="${args.query}") — 의미 기반 검색 fallback`,
            ]);
          }
    
          const aliasNote =
            resolvedQuery !== args.query ? ` (정규화: ${resolvedQuery})` : "";
          let text = `법령 검색 — ${args.query}${aliasNote}\n`;
          text += `총 ${result.totalCnt}건 중 ${result.items.length}건 표시 (페이지 ${result.page})\n\n`;
    
          for (const item of result.items) {
            text += `[mst=${item.법령일련번호}`;
            if (item.법령ID) text += `, lawId=${item.법령ID}`;
            text += `] ${item.법령명한글}`;
            if (item.법령구분명) text += ` (${item.법령구분명})`;
            text += "\n";
            if (item.소관부처명) text += `  소관: ${item.소관부처명}\n`;
            if (item.시행일자) text += `  시행: ${item.시행일자}\n`;
            if (item.공포일자) text += `  공포: ${item.공포일자}\n`;
            text += "\n";
          }
    
          const firstItem = result.items[0];
          if (firstItem) {
            text = appendSuggestions(text, [
              {
                tool: "get_law_text",
                args: { mst: firstItem.법령일련번호 },
                reason: `${firstItem.법령명한글} 본문 조회`,
              },
              {
                tool: "get_related_laws",
                args: { mst: firstItem.법령일련번호 },
                reason: "시행령·시행규칙·고시 등 하위 규칙 + 관련 법령",
              },
              {
                tool: "get_annexes",
                args: { lawName: firstItem.법령명한글 },
                reason: "별표·서식 (처리방침·동의서 양식 등)",
              },
            ]);
            text += `\n${formatLawAttribution(firstItem.법령명한글)}`;
          }
    
          return { content: [{ type: "text", text }] };
        } catch (err) {
          return formatToolError(err, "search_law");
        }
      },
    };
  • Input schema using Zod: query (string, min 1), display (number, 1-100, default 100), page (number, min 1, default 1), sort (optional enum: lasc/ldes/dasc/ddes).
    const inputSchema = z.object({
      query: z
        .string()
        .min(1)
        .describe(
          "법령명·키워드. 약칭(개보법·정통망법·신정법·위치정보법·통비법 등) 자동 인식 후 검색."
        ),
      display: z
        .number()
        .int()
        .min(1)
        .max(100)
        .default(100)
        .describe("결과 개수 (기본 100, 짧은 법령명 후순위 quirk 회피)"),
      page: z.number().int().min(1).default(1).describe("페이지 번호 (기본 1)"),
      sort: z
        .enum(["lasc", "ldes", "dasc", "ddes"])
        .optional()
        .describe("정렬: lasc/ldes(법령명 오/내림), dasc/ddes(날짜 오/내림)"),
    });
  • LawItem interface defining the structure returned by the lawSearch API: 법령일련번호, 법령ID, 법령명한글, 소관부처명, 법령구분명, 공포일자, 시행일자.
    interface LawItem {
      법령일련번호: string;
      법령ID: string;
      법령명한글: string;
      소관부처명: string;
      법령구분명: string;
      공포일자: string;
      시행일자: string;
    }
  • Import of searchLaw from primitives/search-law.js
    import { searchLaw } from "./primitives/search-law.js";
  • Registration of searchLaw in the ALL_TOOLS array (first tool in the list, under W1.5 section).
    export const ALL_TOOLS: Tool[] = [
      // W1.5
      searchLaw,
Behavior4/5

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

No annotations provided, but the description discloses behavioral traits: automatic abbreviation recognition, a quirk about short law names affecting display ordering (from schema description), and that the MCP prioritizes personal information. This transparency is commendable despite missing annotations.

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

Conciseness4/5

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

The description is three sentences long, concise, and front-loaded with the core action. It could be better structured (e.g., using bullet points) but remains efficient and avoids redundancy.

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?

Given 4 parameters, no output schema, and the complexity of legal search, the description explains the tool's purpose and next steps but lacks any description of the return format or fields. It assumes domain knowledge of the law system. Adequate but not fully comprehensive.

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 baseline is 3. The tool description adds some meaning beyond schema (e.g., mentioning metadata fields like ministry and effective date, and abbreviation recognition), but much of this is also present in the schema descriptions, so the additional value is modest.

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 searches statutes by name and metadata, and recognizes abbreviations. It mentions its primary domain (personal information) but can also search general laws. However, it does not explicitly differentiate from similar search tools like intelligent_law_search or search_english_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 provides context on when to use (searching by name/metadata) and suggests follow-up tools. However, it lacks explicit guidance on when not to use or how to choose among sibling search tools, leaving usage decisions ambiguous.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/scvcoder/korean-privacy-law-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server