Korean Law MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v4.9.1
Disambiguation5/5
Each tool has a clearly distinct purpose: search_law finds law IDs, get_law_text retrieves full text, ordinance_radar checks ordinance updates, get_annexes gets annexes, legal_research handles multi-step research, legal_analysis does verification and analysis, discover_tools and execute_tool are meta-tools, search_decisions searches decision databases, and get_decision_text retrieves full decisions. No overlap; detailed descriptions prevent confusion.
Naming Consistency4/5
Most tools follow a consistent verb_noun snake_case pattern (search_law, get_law_text, get_annexes, search_decisions, get_decision_text). A few deviate slightly (ordinance_radar, legal_research, legal_analysis, discover_tools, execute_tool) but still maintain predictability and clarity.
Tool Count5/5
With 10 tools, the server is well-scoped for a comprehensive Korean law research assistant. Each tool provides a distinct function without redundancy, covering search, retrieval, analysis, verification, and meta-tool discovery. The count fits the domain perfectly.
Completeness5/5
The tool set covers the full lifecycle of legal research: identification (search_law), retrieval (get_law_text, get_annexes), updates (ordinance_radar), complex research (legal_research), verification (legal_analysis), decision searching (search_decisions, get_decision_text), and even extensibility via meta-tools. No obvious gaps for the stated purpose.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that it retrieves full text, but contradicts the schema by claiming mst/lawId are required when schema has required: [].
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 description is a single sentence, concise but not well-structured, lacking separation of purpose and usage.
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?
With 4 parameters and no output schema, the description is minimal. It does not explain return value format, pagination, or error handling, leaving significant gaps for an AI agent.
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 coverage is 100%, so the description adds little beyond the schema. It mentions mst/lawId are required, which contradicts the schema but adds some context.
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 it retrieves full text of provisions from Korean law using mst/lawId. It distinguishes itself from sibling tools like search_law but is in Korean, limiting English-speaking agents, and lacks a title.
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?
Implies that mst/lawId are required and jo is for specific provisions, but does not explicitly compare to siblings or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and other safety hints. The description adds no behavioral context beyond proxying. It does not describe error handling, response format, or side-effects. With annotations, score is adequate but not enriched.
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?
One concise sentence in Korean, front-loaded with key info. Very compact with no wasted words, but could benefit from a more structured format.
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?
No output schema and description does not explain return values. Missing context about required prior discovery step, permissions, or behavior when the proxied tool fails. Incomplete for a meta-tool.
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 coverage is 100% with descriptions for both parameters. The description only restates 'tool_name + params', adding no additional meaning beyond the schema.
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 it is a proxy execution for tools discovered via 'discover_tools', taking 'tool_name' and 'params'. It distinguishes itself from sibling tools which are specific domain tools.
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?
No guidance on when to use this tool versus alternatives. It implies usage after discover_tools, but does not explicitly state prerequisites, exclusions, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint false, so the agent knows the tool is safe. The description adds contextual information about amounts/standards being in annexes, but does not disclose output format, pagination, or any specific behavioral details beyond the purpose.
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 brief (two sentences plus a note) and front-loaded with the core purpose. It is efficient but could be slightly more structured to separate usage guidance and hints.
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 complexity (4 parameters, no output schema), the description is incomplete. It does not explain the relationship between 'bylSeq' and 'annexNo', nor does it describe the output format or whether a single annex or multiple annexes are returned. The note about amounts/standards provides some context but insufficient for full completeness.
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%, with each parameter well-described. The description adds a usage example ('lawName+'별표N'') but does not provide new information beyond what the schema already offers for parameter semantics.
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 states '별표/서식 조회' (annex/form inquiry) and mentions extracting content using lawName+'별표N', clearly indicating the tool retrieves annexes or forms for a given law. While it is in Korean, the purpose is specific and distinct from siblings like 'get_law_text' or '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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage pattern (lawName+'별표N') and hints that amounts/standards are often in annexes, implying when to use this tool. However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, openWorld, idempotent, non-destructive. The description adds that it is a discovery tool for categories and a fallback, which is useful behavioral context beyond annotations. No contradictions.
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?
Single sentence (with a leading title) that conveys the core purpose concisely. No filler, but the Korean text could be more accessible.
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?
Given the simple schema (one string parameter) and annotations, the description covers the tool's role as a category discovery fallback. No output schema, but return behavior can be inferred from the discovery purpose.
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 coverage is 100%, so baseline is 3. The description repeats the parameter's purpose (category search) but does not add further semantics beyond the schema's description.
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 is for category-based discovery of specialized legal tools (80+ categories) and positions it as a fallback when other tools fail. It distinguishes itself from siblings by being a meta-tool, but could be more specific about the action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('if the above tools don't work') and lists the categories it covers, giving clear guidance on when to invoke this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior; the description adds that the default 'full=false' provides step-wise abbreviation of the body while preserving certain sections. This adds behavioral context beyond 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 a single concise sentence that front-loads the main purpose and key features. However, it could be structured into separate lines for clarity.
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 the complexity of 4 parameters with an enum and nested object, and no output schema, the description is adequate but lacks details on response format, error handling, or availability. It does not fully compensate for the missing output schema.
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 coverage is 100%, but the description enriches parameter meanings by explaining the default behavior of 'full' and providing concrete examples for the 'options' parameter (e.g., treaty, english_law). This significantly clarifies parameter usage.
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 explicitly states it is a comprehensive lookup across 18 domains, requiring domain and id, with a summarization option. This clearly differentiates it from siblings like search_law and get_law_text, which target different legal sources.
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 usage for retrieving decision texts by domain and ID, but does not explicitly state when to use this tool versus alternatives like search_decisions. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds significant behavioral details: automatic fallback, abbreviation conversion, concurrent listing of title changes and amendments. No contradictions.
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 somewhat long but tightly packed with useful information. It is front-loaded with the core purpose, and each sentence adds value. Could be slightly more concise, but structure is good.
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?
With no output schema, the description mentions the return of lawId and mst but not full structure. However, annotations (readOnlyHint, openWorldHint) and the detailed purpose make it complete enough for an agent to use effectively.
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 coverage is 100% with descriptions for both parameters. The description adds example query values and a note on the display parameter, but the schema already covers meaning adequately. Baseline 3 is appropriate.
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 law names, ordinance names, and administrative rule names by keyword to obtain lawId and mst. It distinguishes from siblings by focusing on identifier acquisition for subsequent queries.
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?
The description explains use cases (acquiring identifiers before text queries) and includes fallback behavior (auto-fallback to local ordinances/rules on zero results). It lacks explicit exclusions or alternatives but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe read-only, idempotent behavior. The description adds that the tool is composite, integrating multiple APIs in parallel, which complements the annotations without contradiction.
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 description is relatively long but well-structured as a list of task types with examples. It front-loads the purpose. However, some redundancy exists and it could be more concise while retaining essential information.
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?
Given the tool's complexity (12 parameters, composite nature, no output schema), the description covers purpose, task types, parameter usage, and sibling differentiation. It lacks return value details, but annotations already provide behavioral safety cues.
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% with descriptions for all 12 parameters. The tool description adds task-specific context (e.g., '도구 설명의 task 표 참조' for task, and qualifiers like '[document_review 전용·필수]') that enhances understanding beyond the schema alone.
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 is for multi-level Korean legal research integrating multiple APIs, designed for complex queries. It lists specific task types and explicitly distinguishes from simpler siblings like search_law/get_law_text by advising to use those for simple lookups.
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?
Guidance is explicit: use this tool when a single lookup does not suffice, otherwise prefer search_law/get_law_text. Each task type is described with examples, providing clear context. However, it does not explicitly state when not to use this tool beyond the sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds behavioral context by explaining the extraction and comparison logic and the automatic flagging of potentially out-of-date ordinances. It does not contradict any annotations and provides useful insight beyond structured fields.
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 a single, dense sentence that packs all necessary information. It is front-loaded with the tool's purpose. While it is concise and efficient, the Korean phrasing is somewhat lengthy, and breaking it into two sentences might improve readability slightly.
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?
Given the lack of an output schema, the description adequately explains the tool's function and the kind of results it provides (extracted superior laws, date comparison, flagging). For a tool with four optional parameters and clear annotations, this is sufficient for an agent to understand its capabilities.
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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the relationship between parameters (one of ordinSeq or ordinanceName should be specified), provides aliases (id for ordinSeq, query for ordinanceName), and gives examples for ordinanceName. This enriches the schema's basic descriptions.
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 extracts superior laws cited by ordinances, compares effective dates, and flags when superior laws have been amended after the ordinance's effective date. It distinguishes itself from sibling tools like search_law and legal_research by focusing on the radar/flagging functionality for ordinance revision assessment.
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?
The description explicitly targets users ('조례 담당 공무원') and states the purpose ('상위법 개정 추적·조례 정비 판단용'). It mentions that either ordinSeq or ordinanceName must be specified, which provides usage context. However, it does not explicitly state when not to use this tool or provide direct alternatives from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds detailed operational context for each mode, such as citation verification against a government database, case citation tracking, and backward graph generation, which exceeds annotation coverage.
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 a single dense paragraph with a bullet-like structure using '|' to separate modes. Each mode is described concisely with key details, no fluff, and the most important information (mode list) is front-loaded.
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 description covers all modes, required parameters, and some behavioral details. However, it lacks any description of output format or return values, which is problematic given the absence of an output schema. This leaves the agent uncertain about what the tool will produce.
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%, but the description adds value by grouping parameters per mode and explaining their roles (e.g., 'jo' for impact_map required, 'date' for applicable_law required). This extra context clarifies parameter usage beyond the schema.
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 is a Korean-law analysis tool with four distinct modes (verify_citations, cite_check, applicable_law, impact_map), each with specific purposes. It differentiates from sibling tools like search_law and get_law_text by being an integrated analysis tool.
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?
The description explicitly specifies required parameters for each mode and provides context for when to use each mode. However, it does not directly tell when to avoid this tool in favor of a sibling, though the mode-specific guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context: it explains the domain-based search, the optional includeText flag for precedents, and the domain-specific options, without contradicting any annotations.
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 concise: one main sentence introducing the tool, followed by two short sentences with a critical usage example. It front-loads the key information and avoids unnecessary words.
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?
Given the tool's complexity (6 params, nested options, no output schema), the description covers the main functionality and provides a concrete example. However, it does not describe the output format or pagination behavior, which would be helpful for an agent.
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?
While the schema covers all parameters (100% coverage), the description adds substantial value by listing the 18 domain values inline and explaining the domain-specific options (e.g., for precedent and tax_tribunal). This goes beyond the minimal schema descriptions.
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's purpose: integrated search across 18 specified legal domains. It uses a specific verb ('search') and resource ('decisions'), and distinguishes from siblings like 'search_law' by listing the exact domains covered.
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?
The description provides a clear use case (searching across domains) and a detailed example for searching precedent text with options. However, it does not explicitly indicate when to use alternative tools like 'get_decision_text' or 'search_law', though the domain list implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![korean-law-mcp-clean MCP server](https://glama.ai/mcp/servers/pragato-throwaway/korean-law-mcp-clean/badges/card.svg)](https://glama.ai/mcp/servers/pragato-throwaway/korean-law-mcp-clean)

Score Badge

Copy to your README.md:

[![korean-law-mcp-clean MCP server](https://glama.ai/mcp/servers/pragato-throwaway/korean-law-mcp-clean/badges/score.svg)](https://glama.ai/mcp/servers/pragato-throwaway/korean-law-mcp-clean)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/pragato-throwaway/korean-law-mcp-clean'

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