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 role: search_law retrieves identifiers, get_law_text fetches full law text, ordinance_radar tracks ordinance revision needs, get_annexes extracts annexes, legal_research handles multi-step investigations, legal_analysis performs verification and citation checks, discover_tools and execute_tool provide meta extensibility, search_decisions and get_decision_text cover decision search and retrieval. No significant overlap exists; the composite tools are differentiated by their task modes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_law, get_law_text, discover_tools, get_decision_text). The pattern is uniform, with no mixing of conventions like camelCase or inconsistent verb forms. Even ordinance_radar follows a descriptive noun style that fits the overall system.
Tool Count5/5
With 10 tools, the server is well-scoped for the Korean legal domain. It covers core functions (search, text retrieval, annexes, ordinance radar), advanced research and analysis composites, decision databases, and a meta extension mechanism. Each tool earns its place without redundancy or bloat.
Completeness5/5
The tool set provides comprehensive coverage for legal research: law search/retrieval, ordinance revision tracking, annex extraction, multi-step research tasks, citation verification, case law citation tracking, temporal law versioning, impact mapping, unified decision search across 18 domains, and meta tools for discovering hundreds of additional specialized sources. No obvious gaps remain for the stated purpose.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 3/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 is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. However, the tool is described as executing other tools (including potentially mutable ones), which contradicts readOnlyHint. The description provides no extra behavioral context (e.g., whether proxied tool outputs are returned, error handling, permissions). The contradiction and lack of detail leave the agent poorly informed.
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 very short (one line) and front-loads the service name and purpose. However, it lacks structure (e.g., separate sentences for when, how, what). It is minimally acceptable but could be better organized for agent readability.
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?
The tool is a meta-tool with complex behavior (dynamic invocation of other tools) and no output schema. The description fails to explain that the tool returns the result of the proxied tool, how errors are handled, or that tool_name must be from discover_tools. For the tool's complexity and the absence of output schema, the description is insufficient.
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 clear parameter names and types. The description 'tool_name + params' adds no meaning beyond the schema. For the params object, no details on required subfields or structure are provided. Baseline score of 3 is appropriate given full schema coverage, but the description does not enhance parameter understanding.
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 it is a proxy execution tool for tools discovered via discover_tools, naming the two required parameters (tool_name and params). This clearly identifies the tool as a meta-tool for dynamic invocation, distinguishing it from domain-specific siblings like search_law and get_law_text. However, the mixed Korean-English phrasing and lack of explicit 'execute another tool' phrasing slightly reduces clarity for non-Korean agents.
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 after discover_tools by mentioning 'discover_tools 결과 도구를 프록시 실행'. No explicit guidance on when to use this tool versus directly calling the specific tool, nor any exclusion cases. An agent can infer the intended workflow, but explicit alternatives and when-not-to-use conditions are missing.
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 destructiveHint false, so the agent knows it's safe and non-destructive. The description adds value by noting that the tool extracts content from annexes and that amounts/standards are often there, which is useful behavioral context beyond what annotations provide.
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 short (2 sentences) but mixes Korean and English, which may reduce clarity for non-Korean-speaking agents. The second sentence is redundant with the first. It could be more concise and front-loaded with a clear English statement.
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 tool has 4 parameters, no output schema, and moderate complexity, the description is somewhat complete for basic usage but lacks explanation of return values, error handling, or how to specify annexes precisely. The schema covers parameters, but the description could include more about the output format.
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 schema already documents all 4 parameters. The description adds minimal extra meaning (e.g., 'bylSeq' for downloading a specific file, 'annexNo' as alternative), but mostly restates the enum values for knd. It does not significantly enhance understanding beyond the schema.
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 this tool retrieves Korean law annexes (별표/서식) by law name, with a specific format 'lawName+'별표N''. It distinguishes it from sibling tools like search_law or get_law_text by focusing on annexes, but the purpose is somewhat obscured by the Korean text and lack of explicit English summary.
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 gives some context on when to use (to extract amounts/standards often in annexes) and hints at specifying annexes with '별표N' in lawName, but it does not clearly differentiate from siblings like get_law_text or explain when not to use this tool. No explicit alternatives are mentioned.
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=true, idempotentHint=true, and openWorldHint=true, making safety and idempotency clear. The description adds context about the scope (category search, 80+ tools) but doesn't disclose additional behavioral traits like response format or whether results are external. No contradiction with 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 sentence, containing the tool name, a meta indicator, a usage condition, and the action with examples. It is concise with no wasted words, though the initial 'Korean-law-mcp — [메타]' and the condition could be slightly better organized for immediate clarity.
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 simplicity (1 param, no output schema, strong annotations), the description covers purpose, usage context, and the scope of categories. It doesn't explain the return format, but the parameter description implies it returns matching tools. This is adequate for the complexity level.
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 the 'intent' parameter well-described as the category or intent to search. The tool description reinforces this by mentioning 'category search', but adds no new parameter-level detail. Baseline 3 is appropriate since the schema already does the heavy lifting.
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 it performs a category search for specialized tools (80+ types like tax tribunal, treaties, terms) and positions it as a fallback when 'the above tool' fails. This clearly identifies it as a tool discovery meta-tool, distinguishing it from siblings like search_law and get_law_text which handle specific legal content.
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 says 'when the above tool doesn't work' as a usage condition, implying this is a fallback for failed searches. It also specifies it searches by category for specialized tools, which contrasts with sibling tools that handle specific legal texts or analyses. However, it doesn't name alternatives explicitly.
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 readOnlyHint, idempotentHint, not destructive. The description adds that mst or lawId are required (though schema marks none required), which is critical behavioral context. No contradictions detected.
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 short and front-loaded with purpose. It wastes no words, though the Korean-English mix may slightly hinder clarity for non-Korean agents.
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 there is no output schema and the tool has 4 parameters, the description adequately explains purpose and key parameters, but omits return format or what 'full text' entails (e.g., structured sections, plain text). This is acceptable for read-only fetch.
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 description mentions mst, lawId as required, and jo for specific articles, but does not add new semantic meaning beyond what the schema's parameter descriptions already provide (e.g., jo format examples).
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 the tool retrieves the full text ('조문 전문 조회') of a law article, and specifies that 'mst/lawId' are required despite the schema not marking them as required. It distinguishes by noting it can fetch a specific article using 'jo'.
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: use when needing the full text of a law or a specific article. It mentions that mst and lawId come from search_law, but does not explicitly state when not to use it or recommend alternatives among siblings like get_decision_text.
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=true, idempotentHint=true, destructiveHint=false, so the core safety profile is clear. The description adds value by detailing the 'full' parameter's effect (본문 계단식 축약) and the 18-domain scope, but does not disclose potential rate limits or error handling 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the tool's main identity, then domain count, key parameters, and default behavior. The single sentence is efficient, though the Korean-English mix and shorthand ('계단식 축약') could be clearer for an English agent.
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 moderate complexity (4 params, nested objects), the description covers the essential lookup pattern. The absence of an output schema is mitigated by the detailed input schema, but the description does not explain return structure or error cases, slightly reducing 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%, so the schema already documents all parameters. The description adds a bit of context about 'options' being domain-specific and examples for treaty/english_law, but largely repeats schema info. 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 uses a specific verb '조회' (lookup) and resource 'Korean-law-mcp', and clearly states the tool retrieves full text for 18 domains. It distinguishes from siblings like 'search_law' or 'get_law_text' by emphasizing the aggregated domain coverage and the 'full' parameter behavior.
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 implies usage with domain+id from search results, and notes the default 'full=false' behavior. However, it does not explicitly state when to use this tool vs alternatives like 'get_law_text' or 'search_decisions', leaving differentiation to the agent's inference.
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, openWorldHint, and destructiveHint false, so safety traits are covered. The description adds behavioral context: it extracts text from the ordinance body, compares dates, and auto-flags. This goes beyond the annotations by explaining the internal logic and output meaning. No contradiction is present.
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 multi-sentence but each sentence contributes value. It is front-loaded with the tool name and primary action. While slightly verbose with both Korean and English, it remains clear and efficient. No superfluous information is present.
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 no output schema, and the description does not describe the return format. For a tool that produces a flagged list, the lack of output details is a minor gap. Annotations cover safety, and the description explains the logic, but completeness is hindered by the missing output specification. With sibling tools and complexity considered, a 3 is fair.
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 each parameter. The description reiterates that one of ordinSeq/id or ordinanceName is needed and provides an example for ordinanceName. It does not add significant new meaning beyond the schema, so the baseline score of 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's purpose: it extracts cited higher-level laws from an ordinance, compares effective dates, and flags ordinances where the higher law was amended after enactment. This is a specific verb+resource combination that distinguishes it from siblings like search_law or legal_analysis. The target audience and use case are also explicitly mentioned.
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 identifies the target users (ordinance officers) and the context (tracking higher law amendments for maintenance review). It also specifies that either ordinSeq/id or ordinanceName must be provided. However, it does not explicitly state when not to use this tool or compare it to sibling tools, though the purpose is distinct enough that the guidance is clear.
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?
The description significantly enriches the annotations (readOnlyHint, idempotentHint, etc.) by detailing specific behaviors: automatic fallback to autonomous/administrative rules on zero results, automatic abbreviation conversion, automatic annotation of name changes and upcoming amendments, and identifier acquisition. No contradictions with annotations.
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 adequately structured with the main function first, but it is relatively long with multiple clauses and examples. Some redundancy exists (e.g., listing document types multiple times). A more streamlined version would improve conciseness without losing key 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 complexity (2 parameters, no output schema, rich annotations), the description covers core behaviors, fallback, and special features. It lacks an explicit specification of the output format beyond 'lawId, mst', which may require some domain inference from the agent. Overall, nearly complete.
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% for both parameters (query and display), so the baseline is 3. The tool description does not add new semantic detail about the parameters beyond what the schema already provides (e.g., examples and caution about display default). No gap to compensate.
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 keyword searching of Korean law names, ordinance names, and administrative rule names to obtain lawId and mst identifiers. It distinguishes itself from siblings like get_law_text (which retrieves full text) by emphasizing identifier acquisition and search fallback behaviors.
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 indicates when to use the tool: before querying legal documents to secure identifiers. It explains automatic fallback and abbreviation conversion, providing context for effective use. However, it does not explicitly state when not to use it or directly compare with alternatives like ordinance_radar or legal_analysis.
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, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond annotations, such as how to obtain full text via options and the integrated nature of the search. No contradictions. It appropriately complements the annotated safety profile.
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 moderately sized but front-loaded with the core purpose. Every sentence adds value: domain enumeration, usage hints for specific cases. While it could be slightly more compact (e.g., removing the repeated domain list already in schema), it remains well-structured and informative.
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 6 parameters, a nested object, and no output schema, the description covers major behavioral aspects: which domains exist, how to activate full text, and a special case for NTS. It does not explain response format, but given the readOnly and idempotent annotations, the description is sufficiently complete for typical search usage.
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%, so every parameter has a description. The description goes further by illustrating concrete usage for domain and options (e.g., 'domain='precedent', options.includeText=true, options.detailLimit=N'), which adds practical meaning beyond the schema's generic descriptions. This extra guidance helps the agent form correct calls.
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 an integrated search across 18 specific domains, using a domain selector. It distinguishes itself from siblings like search_law or get_decision_text by emphasizing its multi-domain scope. The verb '통합 검색' (integrated search) and explicit domain list make purpose unmistakable.
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 specific guidance on when to use certain domains: domain='precedent' with options.includeText=true for full text, and domain='nts' for tax interpretations. It implicitly tells when not to use other siblings (e.g., get_decision_text for a single decision). Lacks explicit exclusions or alternatives among siblings, but sufficiently covers common use cases.
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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description complements this by explaining that the tool is for complex, multi-API queries and should be fall back for vague natural language queries. No contradiction found.
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 dense block of Korean text approximately 400 characters. It front-loads the core concept and lists tasks, but the tasks are embedded in inline text with shorthand and examples that may be hard to parse. The structure is compact but sacrifices readability.
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 12 parameters, no output schema, and no nested objects, the description does a good job of explaining task-switching behavior, parameter dependencies, and fallback rules. It covers the main usage patterns but could be more explicit about the tool's expected output format or response structure.
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 beyond the schema by explaining the purpose of each task and how task-specific parameters relate (e.g., text required for document_review, domain for dispute_prep). It also clarifies default behavior (e.g., query required for all tasks except document_review).
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 Korean law multi-level research integration tool that uses multiple APIs in parallel. It lists 9 specific tasks (e.g., full_research, law_system, action_basis) with examples, effectively distinguishing from sibling tools like search_law and get_law_text which are 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use search_law/get_law_text for simple queries that can be answered in a single call. It also defines which scenario values are compatible with which tasks, providing clear context for when to use this complex tool versus alternatives.
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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as safe. The description adds substantial behavioral context beyond annotations: verify_citations cross-checks against the law DB to prevent LLM hallucination; cite_check performs reverse citation tracking and detects changes/abandonment; applicable_law retrieves the correct law version with transitional provisions; impact_map generates a reverse reference graph with mermaid output. It also discloses behavior for optional parameters like deepScan (default true, skipping detection if false). No contradiction with 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 compact and information-dense, covering four modes in a single paragraph without excess verbiage. It is front-loaded with the title 'Korean-law-mcp — [정밀분석] 검증·분석 4종 통합.' However, the structure mixes Korean and English with pipe separators, which reduces scanability for an English-speaking AI agent. A bulleted or sectioned format would improve clarity without sacrificing conciseness.
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 high complexity (11 parameters, 4 modes, no output schema), the description provides adequate contextual coverage: it explains the purpose and required inputs for each mode, hints at output types (e.g., 'mermaid 그래프 코드 출력' for impact_map, '법령 버전+그 시점 조문+부칙 경과조치' for applicable_law), and details behavior like default settings. It does not fully specify return structures, but without an output schema, that is acceptable. The description could be more complete by clarifying what verify_citations returns (e.g., a list of validated citations).
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 100%, so baseline is 3, but the description adds significant value: it groups parameters by mode, specifies which parameters are required for each mode (using '필수' markers), provides clear examples (e.g., '제103조', '2023-05-10', '2013다61381'), and explains defaults (e.g., '기본 15' for maxCitations, '기본 true' for deepScan). This meaningfully enriches the bare 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 explicitly states it is an integrated verification/analysis tool for Korean law with four distinct modes (verify_citations, cite_check, applicable_law, impact_map), each with a specific verb and resource (e.g., '검증·분석 4종 통합' and 'mode: verify_citations=텍스트 속 조문 인용...이 실존하는지 법제처 DB 교차검증'). This clearly distinguishes it from sibling tools like search_law or get_law_text, which are for retrieval, not analysis.
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 clear usage context by specifying required parameters per mode (e.g., 'text 필수' for verify_citations, 'caseNumber 필수' for cite_check, 'lawName+date 필수' for applicable_law, 'lawName+jo 필수' for impact_map). It implies when each mode is appropriate but does not explicitly state when not to use this tool or list alternatives (e.g., using get_law_text for plain text retrieval). However, the mode selection paradigm effectively guides the agent.
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

Korean Law MCP MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![Korean Law MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/episodic-rush/korean-law-mcp-unclean/badges/card.svg)](https://glama.ai/mcp/servers/episodic-rush/korean-law-mcp-unclean)

Score Badge

Copy to your README.md:

[![Korean Law MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/episodic-rush/korean-law-mcp-unclean/badges/score.svg)](https://glama.ai/mcp/servers/episodic-rush/korean-law-mcp-unclean)

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/episodic-rush/korean-law-mcp-unclean'

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