korean-law-mcp

Server Quality Checklist

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

Latest release: v4.12.1
Disambiguation4/5
The direct lookup pairs (search_law/get_law_text/get_annexes and search_decisions/get_decision_text) are clearly separated, and the meta tools have their own distinct role. The only real ambiguity is that legal_research and legal_analysis are both broad legal-workflow tools and could be confused for similar queries.
Naming Consistency3/5
Names are consistently snake_case and several follow get_/search_ patterns, but legal_research, legal_analysis, and ordinance_radar do not fit a verb_noun convention. This is still readable, but it is a mixed naming pattern rather than a predictable one.
Tool Count5/5
Ten tools is well within the ideal range for a broad legal-research server. The count is also controlled sensibly by routing 80+ specialized capabilities through discover_tools/execute_tool instead of listing every one first-class.
Completeness4/5
The surface covers statutory search and text, annexes/schedules, decision search and full text, and complex research/analysis workflows, so there are no major dead ends. The main limitation is that some specialized domains are only reachable indirectly through the discover/execute proxy.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 106 of 107 community issues answered or closed in the last 6 months
- No commit activity data available
- Last stable release on August 19, 2026
- 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?
No side effects or error behavior are described. Annotations indicate read-only and idempotent, but the description itself does not disclose potential failure modes or return characteristics. No contradiction exists 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 very brief (two lines), so it is concise, but it lacks any structured breakdown (e.g., parameter explanation, usage examples). It is not verbose but may be considered under-structured for a tool with six parameters.
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 description is incomplete for a complex tool: it does not explain the full parameter set, the relationship between annexes and articles, or how to combine with other tools in the MCP. It only hints at one usage pattern, leaving much context undeclared.
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?
The tool description only mentions lawName and the pattern '별표N', ignoring the other five parameters. While the schema provides descriptions for each parameter, the description adds minimal value beyond that, failing to explain how parameters interact (e.g., jo vs annexNo).
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 purpose: retrieving annexes (별표/서식) from Korean law, and notes that amounts/standards often reside there. This is specific and distinguishes it from general law text retrieval.
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?
Only a single usage hint is given ('lawName+'별표N'으로 내용 추출'), but no guidance on when to use this tool versus sibling tools like get_law_text, nor how to leverage the other parameters (jo, knd, query, bylSeq, annexNo). Examples are absent.
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, idempotentHint, and destructiveHint=false, covering safety and idempotency. The description adds 'proxy execute' context but does not disclose additional behaviors like error propagation or output forwarding.
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 short line, front-loaded and efficient. However, it could be structured with separate sentences for clarity. No wasted words.
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 there is no output schema, the description should explain the return format or behavior. It omits important context such as error handling, output structure, or what happens when the proxied tool fails. This is a significant gap for a proxy 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 description coverage is 100% for both parameters, so the schema already explains their meaning. The description summarises 'tool_name + params' but adds no new semantic information 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 executor for tools discovered via discover_tools, specifying the verb 'proxy execute' and the resource 'tool from discover_tools'. This distinguishes it from sibling tools which are specific law-related functions.
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 by referring to discover_tools results, but does not explicitly state when to use this tool versus calling a specific tool directly. No when-not-to-use or alternative guidance is 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?
The description discloses that when full=false (default), the body is returned in a stepwise abbreviated form, which is a significant behavioral trait beyond the read-only annotations. It does not describe other behaviors like return format or authentication.
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 concise line, front-loading the main purpose and including only essential usage details.
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 gives the core usage pattern but leaves the domain-specific options parameter unexplained (relies on schema), and the '계단식 축약' term is vague. For a tool of this complexity, more context would help.
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 covers all parameters fully (100%). The description only restates that domain+id are needed and mentions full's effect, adding no new parameter semantics 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 clearly identifies the tool as an integrated lookup for full text across 18 domains, requiring domain and id. It is specific but does not explicitly contrast with sibling tools like search_decisions or get_law_text.
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 acquiring domain+id and mentions the full parameter's default behavior, but it does not provide explicit when/when-not conditions or alternatives.
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, etc. The description adds value by explaining domain-specific options and use cases, such as including full text for precedents and specifying the nts domain for tax interpretations. 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 packed with useful information. It is concise but not overly long, with a clear structure: first states purpose, then gives specific hints. Could be slightly more structured, but overall efficient.
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 (6 parameters, nested objects, no output schema), the description does not explain return values or output format. It covers input usage well with domain-specific examples but omits what the agent can expect as output.
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% (baseline 3). The description goes beyond schema by providing practical examples for using the 'options' parameter (e.g., includeText, detailLimit) and specific domain values like 'nts', enhancing 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 clearly states it is an integrated search across 18 legal domains. It specifies the verb (search) and resource (decisions). However, it does not explicitly differentiate from sibling tools like search_law, leaving some ambiguity about when to use this tool versus alternatives.
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 specific usage hints for full-text precedents (domain='precedent' with options) and tax-related NTS (domain='nts'). However, it does not offer explicit guidance on when not to use this tool or compare it to alternatives like search_law.
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 adds behavioral context beyond annotations: it explains the extraction and comparison process and the automatic flagging of candidates for review. This is consistent with the readOnly, idempotent, and non-destructive hints.
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 concise and front-loaded with the purpose. While it is a single paragraph, it contains essential information without redundancy. Minor improvements could include bullet points 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?
The input parameters are well covered, but the output format is not described. Given the lack of an output schema, the description should briefly mention what the tool returns (e.g., a list of flagged ordinances or comparison results). The openWorldHint partially mitigates this gap.
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 limited value over the schema. However, it clarifies the relationship between id/ordinSeq and query/ordinanceName, and provides example usage, which supports effective parameter selection.
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 function: extracting higher-level laws from ordinances, comparing effective dates, and flagging discrepancies for maintenance review. It distinguishes itself from sibling tools like search_law or legal_analysis by focusing on ordinance alignment with parent legislation.
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 indicates the target users (ordinance officials) and required parameters (ordinSeq or ordinanceName), but it does not explicitly state when to avoid using this tool or compare it to alternatives. The context of sibling tools is implied but not directly addressed.
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 the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral details beyond annotations, especially the jo natural-language conversion and the 6-digit code formatting pitfall. It does not mention response format, but annotation coverage lowers that burden.
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 sentence with front-loaded purpose followed by necessary usage details. The jo code examples and the explicit error case '234002 아님' carry high information value with no filler.
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?
For a read-only retrieval tool, this description covers purpose, required identifiers, optional jo behavior, and the tricky JO code transformation. No output schema exists, but '전문 조회' implies the return is the full provision text. It could be more complete by explaining the mst/lawId ambiguity and return behavior explicitly, but it is largely sufficient.
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 extra meaning by declaring mst/lawId as required and emphasizing jo as the recommended way to target a specific article. It is partly redundant with the schema's detailed jo explanation, but still adds selection semantics absent from the required array.
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?
Description clearly states this is a law-article full-text lookup ('조문 전문 조회') using mst/lawId and optional jo, which distinguishes it from search-oriented siblings like search_law and get_annexes. It is specific about the resource and action, though it does not explicitly contrast itself with sibling tools.
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 clear usage context: mst/lawId are required, jo narrows to a specific article, and natural-language jo input is recommended. It does not state explicit when-not-to-use guidance or name alternatives, but the context is unambiguous enough for an agent to decide when this tool applies.
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?
Despite rich annotations (readOnly, openWorld, idempotent, non-destructive), the description adds substantial behavioral context beyond them: the 실존불가/미확인 (impossible/unconfirmed) distinction for cases, change/abolition detection for lineage, temporal act-time analysis with 부칙 경과조치, and graph+mermaid output generation. It discloses internal decision logic and output characteristics that annotations alone cannot convey, with no contradiction against the visible hints.
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 and front-loaded with the value proposition ('법제처 DB 교차검증, LLM 환각 방지') before mode breakdowns, using clear '|' and '—' separators to partition the four modes. It is a long single block, but every segment earns its place given the 4-mode complexity; slightly more whitespace or bullet structure would improve scannability.
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?
For a complex 4-mode tool with 11 parameters and no output schema, the description covers each mode's trigger, required inputs, and key behaviors, including output hints like mermaid graphs and the '빠르지만 변경·폐기 감지 생략' tradeoff. It does not detail exact return structures, but given the mode-specific nature and rich schema, this is adequately complete for the complexity.
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% — every parameter already documents its format and mode-required markers (e.g., jo's natural-language and 6-digit code acceptance, deepScan's fast-scan tradeoff). The description's mode↔parameter mapping table and jo format acceptance adds a consolidated perspective but largely restates what the schema already encodes, so it does not significantly exceed the baseline.
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 a specific aggregate verb ('검증·분석 4종 통합') and unpacks four distinct analysis operations with concrete outcomes: cross-validating citations against the Ministry of Government Legislation DB, reverse-tracing case citations, determining act-time applicable law, and generating reverse citation graphs. It distinguishes from siblings (search_law, search_decisions, get_law_text) by being an analysis/verification tool rather than a retrieval tool, with each mode's purpose precisely named (verify_citations, cite_check, applicable_law, impact_map).
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?
Each mode includes explicit purpose and required parameters ('text 필수', 'caseNumber 필수', 'lawName+date 필수', 'lawName+jo 필수'), effectively telling the agent which mode fits which scenario (e.g., 'LLM 환각 방지' for verification, '행위시법 판단' for temporal applicability). However, it lacks explicit when-not-to-use guidance or alternatives versus sibling tools like legal_research or search_law — exclusions are implied rather than stated.
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 readOnly/openWorld/idempotent, and the description adds valuable behavioral details: automatic fallback to autonomous/administrative rules on zero results, abbreviation conversion, automatic notation of title changes and pending amendments, and repeal handling with successor rules. 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 dense but front-loaded with the core purpose and each clause adds a distinct behavioral detail. It is a single long sentence with multiple em-dash segments, which is compact but slightly harder to parse than a short structured summary.
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?
For a search tool with no output schema, the description adequately conveys scope, fallback behavior, special handling of repealed laws, and the intended pre-lookup role. It does not detail the exact return shape beyond lawId/mst, but that is sufficient for identifier acquisition.
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 covers both parameters at 100%, so baseline is 3; the description adds extra meaning by giving example query forms ('광진구 복무조례', '외국환거래규정') and explaining automatic abbreviation/fallback behavior tied to the query parameter. This goes beyond the schema's field 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 opens with '[법령검색] 법령명·조례명·행정규칙명 키워드검색 → lawId, mst 획득', specifying a concrete verb (keyword search), resource (Korean statutes/ordinances/admin rules), and output (identifiers). It further distinguishes itself from text-retrieval siblings by stating it is for '조회 전 식별자 확보용'.
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 clearly states the tool is for securing lawId/mst before looking up statutes, ordinances, or administrative rules, giving a clear when-to-use context. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.
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 read-only, open-world, idempotent, and non-destructive behavior. The description adds value by clarifying that it is a meta-search over tool categories rather than a direct source of legal content, which helps prevent the agent from expecting legal text or decisions from it.
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 one dense sentence that front-loads the meta label and usage condition. It is appropriately short, though the deictic phrase '위 도구로 안 되는 경우' is slightly ambiguous when read outside the full tool list context.
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?
For a one-parameter discovery tool, the description covers purpose, usage context, and search categories well. However, since there is no output schema, the description does not explain what the tool returns, such as matching tool names or recommendations, leaving some inference burden on the agent.
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?
The single 'intent' parameter is fully documented in the schema with examples. The description reinforces and expands the parameter semantics by listing additional valid category examples such as 조세심판, 관세, 개인정보위, and 영문법령, giving the agent richer vocabulary for invoking the tool.
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 function: it is a meta tool that performs category searches over 80+ specialized Korean-law tools. The '[메타]' marker and focus on tool discovery distinguish it from sibling legal-search and retrieval tools like search_law, get_law_text, and search_decisions.
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 this tool '위 도구로 안 되는 경우' (when the above tools do not work). It also gives a broad set of categories and examples, helping the agent recognize when this discovery tool is the right fallback.
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, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond this: parallel API orchestration ('여러 API를 병렬로 엮는'), auto-detection of task/scenario when unspecified ('미지정 시 쿼리에서 자동 감지'), and task-specific parameter requirements (document_review requires text, query required for all other tasks). 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 dense but well-structured: header stating purpose, task table with pipe-separated values and examples, scenario section with compatibility mapping, and a closing alternative-guidance sentence. Every segment earns its place for a 12-parameter, 8-task, 9-scenario complex tool. Slightly compressed formatting (pipe-separated) could hinder parsing, but no word is wasted.
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 the complexity (12 params, 8 task modes, 9 scenarios, no output schema), this description is remarkably complete. It covers all task types with examples, all scenarios with task compatibility, auto-detection fallback behavior, parameter requirements per task, and alternative tool guidance. The opaqueness of no output schema is mitigated by clear task-result expectations embedded in each task description. This is a model description for a composite orchestration 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 coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema by mapping parameters to tasks (mst/lawId→amendment_track, domain→dispute_prep, parentLaw→ordinance_compare, articles→law_system, text→document_review, fromDate/toDate→time_travel), providing the scenario compatibility matrix, and clarifying that document_review requires text while query is required for all other tasks. This contextual binding of parameters to workflows exceeds what the schema alone conveys.
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 multi-stage legal research integration tool ('다단계 법령 리서치 통합 — 여러 API를 병렬로 엮는 복합 질문 전용'), enumerates 8 distinct task types with concrete examples ('음주운전 처벌 기준', '관세법 체계', '영업정지 근거'), and explicitly distinguishes it from siblings via the closing instruction to use search_law/get_law_text for single-lookup queries. The verb+resource+scope is specific and non-tautological.
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 this is for complex questions only ('복합 질문 전용') and names search_law/get_law_text as alternatives for simple lookups. It also documents task-scenario compatibility (law_system=delegation·impact, action_basis=penalty, etc.) and auto-detection behavior. However, it doesn't explicitly address how this tool relates to other siblings like ordinance_radar, legal_analysis, or search_decisions, which could be relevant alternatives for specific tasks.
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 MCP server](https://glama.ai/mcp/servers/chrisryugj/korean-law-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrisryugj/korean-law-mcp)

Score Badge

Copy to your README.md:

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

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/chrisryugj/korean-law-mcp'

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