Korean Law MCP

Server Quality Checklist

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

Latest release: v4.9.1
Disambiguation4/5
Most tools have clearly distinct purposes: search/get law texts, ordinance radar, annexes, research vs analysis, and decision search/retrieval. However, legal_research and legal_analysis both handle multi-step queries, and their sub-modes (e.g., full_research vs ordinance_compare) could cause overlap confusion, though descriptions help.
Naming Consistency3/5
Tool names are mostly descriptive with verb_noun pattern (search_law, get_law_text, get_annexes, search_decisions, get_decision_text), but names like ordinance_radar, legal_research, legal_analysis, and the meta tools (discover_tools, execute_tool) break the pattern. The mix of camelCase and snake_case (e.g., includeText, detailLimit) in parameters further reduces consistency.
Tool Count4/5
10 tools is a reasonable count for a domain as broad as Korean law. The surface covers core search, retrieval, and analysis needs. Slightly on the higher side but each tool serves a distinct purpose, well-scoped for the complexity of legal research.
Completeness4/5
The tool set covers the main legal workflows: searching laws, retrieving full text, checking annexes, analyzing ordinances against higher laws, and multi-domain decision search. Minor gaps include direct version comparison (e.g., diff between two law versions) and a dedicated tool for checking law validity date ranges, but the existing legal_analysis.applicable_law mode addresses some of this.
Average 4/5 across 10 of 10 tools scored. Lowest: 2.4/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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims mst and lawId are '필수' (required), but the input schema lists no required parameters, creating a direct contradiction with the schema. Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint; the description adds no behavioral context beyond this misleading requirement.
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 concise (one short sentence), which is positive, but it omits important details and includes a false claim about required fields. It could be restructured to front-load purpose more clearly while avoiding contradictions.
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 no output schema, the description fails to explain what the tool returns beyond 'full text of a clause.' It does not mention return format, pagination, error handling, or behavior when parameters are omitted. For a tool with 4 parameters and no output schema, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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. However, the description adds misleading information by stating mst/lawId are required (contradicting the schema), and it does not explain the purpose of efYd. It adds minimal value beyond what the schema already provides, and the incorrect requirement degrades usefulness.
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 retrieving the full text of a law clause (조문 전문 조회) and specifies that mst or lawId is required, with jo for specific clauses. It effectively communicates the tool's purpose, though it does not explicitly differentiate it from sibling tools like search_law or get_annexes.
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 indicates that mst or lawId is required and that jo can be used for a specific clause, but it provides no guidance on when to use this tool versus alternatives like search_law (for finding laws) or get_annexes (for annexes). No when-not-to-use scenarios or prerequisites 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?
The annotations already indicate 'readOnlyHint: true', 'idempotentHint: true', and 'destructiveHint: false', effectively signaling safe behavior. The description adds the behavioral trait that this tool proxies execution of discovered tools, which is valuable context beyond annotations. However, it does not disclose potential side effects (e.g., that the proxied tool may have its own behaviors not covered here) or any auth or rate limit concerns. Since annotations handle the safety profile well, a score of 3 is appropriate.
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 and front-loaded with the domain prefix and key action. It uses two logical parts: an identifier and a functional explanation. Every word contributes to clarity, though the inclusion of '— [메타]' adds a meta label that could be omitted without reducing value. Overall, it is concise and well-structured, earning a 4.
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 (2 required parameters, 100% schema coverage, output schema absent) and the richness of annotations, the description covers the essential purpose and usage context. Without an output schema, a description of return values would be helpful but is not strictly necessary since this is a proxy tool—the output depends on the proxied tool. The description is adequate for an agent to select and invoke the tool correctly, though it could note that return structure matches the proxied tool's output. Score of 4.
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?
The input schema has 100% description coverage, with each parameter ('tool_name' and 'params') already having descriptions. The description adds the phrase 'discover_tools로 확인한 이름' (name confirmed via discover_tools) for tool_name, which clarifies the source of valid names but does not add new semantics beyond the schema. With full schema coverage, the baseline is 3, and the description does not significantly raise or lower it.
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 includes 'Korean-law-mcp' as a prefix to convey the domain context and states it is a proxy executor for tools discovered via 'discover_tools'. The verb '실행' (execute) and the parameters 'tool_name + params' clearly indicate what the tool does. However, it mentions a '메타' (meta) nature without elaborating, and the description does not explicitly distinguish it from sibling tools, earning a score of 4.
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 that this tool is used to run discovered tools, suggesting a prerequisite of calling 'discover_tools' first. There is no explicit guidance on when to use this vs. alternatives like 'search_law' or 'get_law_text', and no mention of when not to use it. The usage context is implicit rather than explicitly stated, warranting a score of 3.
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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context (e.g., 'extract content', amounts/standards likely in annexes) but does not reveal additional traits like rate limits or authorization. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. It front-loads the primary purpose and immediately follows with a usage hint. Every sentence earns its place.
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, but good annotations, the description is adequate but not fully complete. It explains the main purpose and gives a usage pattern, but does not describe the return format, distinguish between knd values, or clarify the difference between bylSeq and annexNo. The schema covers those details, but additional context would improve completeness.
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 the baseline is 3. The description adds value beyond the schema by providing a usage pattern: 'lawName+'별표N'으로 내용 추출' and notes that lawName can be combined with annex numbers. This gives meaningful context for parameter interaction, raising the score above baseline.
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's function: '별표/서식 조회' (annex/form inquiry) and extracting content with lawName+'별표N'. It distinguishes from siblings like get_law_text by focusing on annexes, though the differentiation is not explicit. The hint about amounts/standards being in annexes adds context.
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 (e.g., when amounts/standards are needed) but does not explicitly state when to use this tool versus alternatives like get_law_text or search_law. No exclusions or alternative tool names are mentioned. The guidance is implied but not direct.
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?
The description discloses the core behavioral logic (extraction, comparison, flagging) beyond the annotations (readOnlyHint, idempotentHint). It adds practical context about what the tool does internally, which helps the agent understand its action scope.
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 moderately concise but uses a run-on structure and specialized notation (e.g., Korean with dashes). It could be clearer and more fred-loaded while preserving the key information.
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 lack of an output schema, the description does not specify the return format, e.g., whether it returns a list of flagged items or a summary. It also does not address handling when both groups of parameters are omitted, leaving edge cases ambiguous.
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?
With 100% schema coverage, the baseline is 3. The description provides some guidance (e.g., indicating that ordinSeq/id or ordinanceName should be specified), but it does not elaborate on parameter semantics beyond what the schema already states.
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 specific purpose: extracting higher-laws cited by an ordinance, comparing enforcement dates, and flagging cases where the higher law was amended after the ordinance's enactment. This distinguishes it from sibling tools like search_law (general search) or legal_analysis (broader 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 identifies the target users (ordinance officials) and specifies that the input must include either ordinSeq/id or ordinanceName. While it does not explicitly outline when not to use this tool, the specificity makes the usage context 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 already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds significant behavioral context: it accesses external databases (법제처 DB), performs cross-validation, reverse-tracks citations, and generates graphs. 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 dense but well-structured: it leads with the tool identity, then a compact table of modes with roles and required fields. Every sentence adds value, though it could benefit from line breaks for readability.
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's complexity (4 modes, 11 parameters, no output schema), the description covers mode definitions and required parameters but leaves output format largely unspecified. For example, verify_citations returns verification results but the structure is not described. Impact_map hints at mermaid output, others do not. Sufficient for basic use, incomplete for full invocation.
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 baseline is 3. The description adds cross-reference tables linking each mode to required/optional parameters (e.g., 'mode=verify_citations: text 필수'), clarifying conditional requirements beyond schema descriptions. This helps the agent understand parameter dependencies.
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 an integrated analysis tool ('검증·분석 4종 통합') and enumerates four specific modes (verify_citations, cite_check, applicable_law, impact_map) with distinct purposes. This differentiates it from sibling tools which are primarily search/retrieval focused.
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 does not explicitly contrast this tool with siblings. Each mode is described with its use case (e.g., 'LLM 환각 방지' for verify_citations), implying when it should be used, but without direct comparison to alternatives like search_law or get_law_text.
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 readOnly, idempotent, and non-destructive behavior. The description adds value by explaining that the tool searches across 18 domains and can include full text when specified. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences, ~250 characters) and front-loaded with the tool name and core purpose. Every sentence adds value—no filler, tautology, or redundant information.
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's complexity (6 parameters, nested options, 18 domains, no output schema), the description covers key use cases but omits details like return format, pagination behavior, and whether multiple domains can be searched simultaneously. It is adequate but not exhaustive.
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%, but the description adds meaning beyond the schema by detailing how to use the options parameter for the precedent domain (includeText, detailLimit) and recommending domain='nts' for tax queries. This context helps agents select correct parameters.
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 performs an integrated search across 18 specific domains (판례, 해석례, etc.) and includes the verb '통합 검색' (integrated search). It distinguishes from siblings like search_law (which likely searches statutes) and get_decision_text (which retrieves a specific decision).
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 explicit guidance on when to use specific domain values (e.g., domain='precedent' with options for full text, domain='nts' for tax interpretations). It does not directly compare to siblings but implicitly excludes other tools by stating this is the integrated search for these domains.
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 provide readOnlyHint and idempotentHint, which describe safe read behavior. However, the description adds crucial behavioral detail: 'full=false(기본) 시 본문 계단식 축약' (full=false(default) shows cascading text abbreviation). This explains the tool's key behavioral nuance beyond the boolean parameter schema, such as why certain sections like 판시·요지·주문 are always full regardless. The description also notes it covers '18개 도메인' (18 domains), which contextualizes the scope.
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 extremely concise: two fragments totaling about 20 words. It front-loads the tool's purpose ('18개 도메인 전문 조회') and immediately follows with required parameters, then the key behavioral switch. Every word carries meaning, and there is no redundancy with annotations or schema. This is exemplary conciseness for a multilingual context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 4 parameters (2 required), 100% schema coverage, and no output schema, the description provides the necessary context: domain list origin (search results for id), full mode explanation, and domain-specific options example. The description is complete for triggering invocation, detailing the core conditional behavior that influences the response format, despite the lack of 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%, meaning all 4 parameters have descriptions. The description does not repeat parameter names but adds meaningful context: id comes from search results, full mode defaults to false with abbreviated text, and the domain enum covers 18 domains. Additionally, the description provides example usage for options, clarifying that it's a domain-specific map. This demonstrates high value beyond what the schema provides.
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 identifies the tool as a comprehensive query tool for Korean legal decisions across 18 domains, requiring domain and id. The verb is implied ('조회' = lookup/query), and the resource is decision text. It distinguishes itself from sibling tools like search_law (search) and get_law_text (different text endpoint) by specifying domain and id structure. The Korean-Konglish naming convention and contents are clear for a Korean-law-targeted agent.
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 implicitly tells when to use this tool: when you have a specific domain and id (likely from search results) and need decision text. It includes how to get full vs abbreviated text via the full parameter. However, it does not explicitly state when NOT to use it or which sibling tool to use instead—e.g., use search_decisions when you don't have an id, or query with options first. This is a minor gap for a tool with complex domain structure.
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=false. The description adds valuable behavioral details: automatic fallback to autonomous/administrative rules on zero results, automatic abbreviation conversion, and automatic notation of name changes/scheduled amendments. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose ('keyword search → lawId/mst'). Each clause adds operational detail (scope, fallback, abbreviation conversion, usage context) without redundancy or filler, making it highly efficient.
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?
Despite lacking an output schema, the description conveys essential return values (lawId, mst) and covers fallback behavior, abbreviation handling, and usage context. It does not detail result structure or pagination, but those are minor for a search tool.
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 enriches parameter understanding by explaining fallback behavior for queries returning 0 results and the rationale for the display default (preventing short-name exact-match omissions). This goes beyond 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 specifies the verb (검색/search) and resource (법령명·조례명·행정규칙명), and the outcome (lawId, mst acquisition). It also distinguishes itself from sibling tools like search_decisions by focusing on law/ordinance/rule name searches for identifier extraction, and mentions fallback to autonomous/administrative rules.
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 states the tool is for obtaining identifiers before retrieving laws/ordinances/rules ('조회 전 식별자 확보용'), indicating when it should be used in a workflow. It does not explicitly name alternative tools, but the context clearly differentiates it from content-retrieval functions.
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, openWorldHint=true, and idempotentHint=true, which tell the agent this is a read-only, non-destructive, and idempotent tool. The description adds context that this tool integrates multiple APIs in parallel and falls back to full_research by default. It also notes that domain and scenario can be auto-detected, which is useful behavioral transparency beyond the 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 long but dense with information, organized into a single paragraph with clear task list for different research types. Each task gets a short code+example. It ends with a sibling-tool reference. While slightly verbose for a non-native reader, it earns its length by packing essential guidance. Could be slightly more structured (e.g., bullet points), but front-loading the core purpose is effective.
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 has 12 parameters, 3 enums, no output schema, and is a complex orchestration tool, the description does a thorough job covering task selection, parameter dependencies (e.g., query required unless document_review, text required for document_review), and auto-detection behavior. The sibling tools and schemas together provide a complete picture, though an explicit note on return format would be helpful.
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 baseline is 3. However, the description adds value by grouping parameters with task tags (e.g., '[amendment_track]', '[document_review 전용·필수]', '[time_travel]'), and explaining that query is required for all tasks except document_review, and that domain/scenario can be auto-detected. This compensates well and adds practical behavior.
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 begins with a clear label ('Korean-law-mcp') followed by an emoji, then '다단계 법령 리서치 통합' (multi-level statute research integration), which is a specific verb+resource. It distinguishes from siblings by listing explicit task types (full_research, law_system, etc.) and stating that for simple queries one should use search_law/get_law_text instead. The task enum values are also defined with concrete examples, making the purpose unambiguous.
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 provides extremely clear when-to-use guidance: it is '여러 API를 병렬로 엮는 복합 질문 전용' (for complex questions combining multiple APIs). It explicitly states a single lookup should use search_law/get_law_text. Each task type has a concrete example (e.g., '음주운전 처벌 기준' for full_research, '관세법 체계' for law_system), leaving no ambiguity about which tool to use for which kind of query.
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 as true, and destructiveHint as false. The description adds value by explaining this is a meta/discovery tool that performs category searches across 80+ specialized sub-tools, supplementing the behavioral profile without contradicting the 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 extremely concise: two clauses that front-load the meta nature and condition, then the core purpose. Every word earns its place—no fluff, and the structure immediately tells the agent when to use this tool.
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 is a simple category search with one parameter and no output schema, the description is sufficiently complete for selection and invocation. It explains the fallback context and provides examples. It could slightly improve by briefly hinting at the output format, but this is not critical.
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% (the parameter 'intent' has a clear description). The tool description reinforces this by listing example categories (e.g., 공정위, 조약, 용어, 헌재), adding context beyond the schema's generic description. This helps the agent select appropriate input values.
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 category search tool for discovering specialized legal tools when other tools fail. It uses specific verb ('category search') and resource ('specialized tools'), and distinguishes from sibling tools like search_law and get_law_text by being a meta-discovery fallback.
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 provides a usage condition: 'When the above tools do not work' ([메타] 위 도구로 안 되는 경우). It also lists example categories for the search, giving agents a clear context for when to invoke this tool versus alternatives.
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-clean/badges/card.svg)](https://glama.ai/mcp/servers/episodic-rush/korean-law-mcp-clean)

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-clean/badges/score.svg)](https://glama.ai/mcp/servers/episodic-rush/korean-law-mcp-clean)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![Korean Law MCP MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fepisodic-rush%2Fkorean-law-mcp-clean%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/episodic-rush/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/episodic-rush/korean-law-mcp-clean'

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