korean-law-mcp

Server Quality Checklist

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

Latest release: v0.4.4
Disambiguation5/5
Each tool has a clearly distinct purpose: searching, reading, exploring legal chains, retrieving history, comparing versions, etc. Even the search tools are differentiated by scope (general search vs. article-specific keyword search vs. terms vs. interpretations).
Naming Consistency4/5
All tool names follow a verb_noun pattern with snake_case, using verbs like search, get, read, explore, compare. There is some variety in verbs, but the pattern is consistent and predictable.
Tool Count5/5
10 tools is well-scoped for a legal research server, covering search, retrieval, exploration, history, comparison, and external linking without being excessive or insufficient.
Completeness4/5
The tool set provides comprehensive coverage for legal research: searching, reading, deep exploration, history, comparisons, and external links. Minor gaps like direct download or advanced filtering are handled via external links, so the surface is quite complete.
Average 4.3/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 annotations are present, so the description carries the full burden of behavioral disclosure. It only states the semantic scope (statutory interpretations) and does not mention whether the tool is read-only, what the response contains beyond the output schema, or any rate limits or auth requirements. The additonal context about the Ministry adds a content qualifier but no behavior.
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 sentence that front-loads the verb ('Search') and resource ('statutory interpretations'), with a brief clarifying parenthetical. Every word contributes to the meaning, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so return values need not be described. However, the lack of usage guidelines and parameter semantics in the description leaves gaps, especially given the many search-related sibling tools. The core purpose is clear, but it is minimally complete.
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 0%, and the description offers no explanation of how the 'query' parameter should be used. The parameter name implies a search string, but there is no guidance on query syntax, language, or format, so the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for statutory interpretations' with the parenthetical specifying 'authoritative interpretations by Ministry of Government Legislation.' This uses a specific verb and resource, distinguishing it from sibling search tools like search_law_articles and search_legal_terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling alternatives. The description only defines what it does, without mentioning any exclusions, alternatives, or specific scenarios where it should be preferred.
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?
With no annotations provided, the description carries the transparency burden. It adds useful behavior by stating it returns a list of matching terms with IDs, but it does not disclose any limitations, authentication needs, or side effects. For a simple search, this is adequate but not rich.
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 at two short sentences, with the main action 'Search for legal terms' front-loaded. Every word contributes meaning, and there is no fluff or repetition.
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?
The tool is simple (one parameter, no nested objects) and has an output schema, so the description need not explain return values in depth. It covers the core action and return format. However, it omits any mention of read-only status or potential prerequisites, which would be useful but are not critical for a search 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?
The schema has one required parameter 'query' with zero description coverage. The description compensates minimally by implying that the query is the legal term to search for, but it provides no detail on matching behavior or expected format. This adds some meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for legal terms and specifies that it returns definitions. The resource "legal terms" distinguishes it from sibling tools like search_law_articles and search_statutory_interpretations, which target different content types.
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 intended use is implied by the purpose: use this when you need to find or define legal terms. However, there is no explicit guidance on when to choose this over siblings or any exclusions noted, so it stops at implied usage.
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?
With no annotations, the description carries the full burden. It discloses that results are returned as Markdown formatted text and that the search is limited to article text, which is useful. However, it does not mention potential edge cases, read-only behavior, pagination, or handling of no matches, leaving some behavioral aspects implicit.
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 well-structured, with a one-sentence purpose, clear Args, and Returns sections. Every sentence adds value, and there is no redundant or vague 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 search tool with two parameters, the description covers the core requirements: purpose, parameter meanings, and return format. The absence of usage guidance compared to sibling tools is a minor gap, but the tool is otherwise self-contained and correctly invokable.
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?
The Args section explains both parameters with concrete details: law_id includes an example format, and keywords clarifies space-separated values. Since the schema provides no descriptions (0% coverage), this fully compensates and adds meaningful semantics beyond the raw 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 uses a specific verb ('Search') and a specific resource ('articles of a statute'), clearly defining the operation as keyword search within law articles. This distinguishes it from sibling tools like search_korean_law or search_legal_terms, which focus on different resources or query types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives such as search_statutory_interpretations or search_legal_terms. The description only states what the tool does, without context about preferred use cases or exclusions.
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?
No annotations are provided, so the description carries the burden. It discloses that it returns 'a comprehensive markdown document containing the main article and all connected legal texts' and mentions the graph nature. It does not disclose side effects or safety info, but as a read-only search tool, that is acceptable though not richly detailed.
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 well-structured with a purpose statement, numbered list, usage examples, and returns. It is efficiently written without redundancy, 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?
The description covers the tool's purpose, usage context, and return format. Given the single parameter and presence of an output schema, it is sufficiently complete. It does not discuss limitations, but none are apparent. Score 4.
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 schema has one required 'query' parameter with no description (coverage 0%). The description compensates by providing two concrete usage examples ('Higher Education Act Article 20', '고등교육법 제20조'), which clarify expected query format. However, it could explicitly state that the query should be a legal provision reference, so 4.
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 'Perform a Deep Search' and names the resource (Legal Graph). It clearly distinguishes from siblings by stating it provides 'full context of a law provision' including references and presidential decrees, which is distinct from simple search tools like search_law_articles.
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 'Use this when you want to understand the full context of a law provision', providing clear context. It also includes usage examples. It does not name alternatives or exclusions, but the context is clear enough for a 4.
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?
With no annotations, the description carries the full transparency burden. 'Get a list' clearly implies a read-only operation, and the ID format note ('e.g. "12345" or "statute:12345"') adds useful context. However, it does not disclose any potential side effects, auth requirements, error conditions, or rate limits, so transparency is only average.
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: a single purpose sentence plus an argument label with example. Every sentence adds value, and the structure is front-loaded with the core verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool and the presence of an output schema, the description covers the essential purpose and parameter semantics. It lacks explicit usage boundaries or edge-case behavior, but for a straightforward list-retrieval operation, the provided information is sufficient to select and invoke the tool correctly.
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 0%, but the description compensates by explaining law_id: 'The ID of the law (e.g. "12345" or "statute:12345")'. This provides meaning, format examples, and acceptable input styles beyond the schema's mere type declaration. It doesn't fully specify constraints or defaults, so a 5 is not warranted.
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 that the tool 'Get a list of attached forms and tables (별표/서식) for a specific statute,' using a specific verb ('Get'), a specific resource ('attached forms and tables'), and a specific scope ('for a specific statute'). This makes it distinct from the sibling search/read tools, which focus on articles, terms, or legal chains.
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 context: it is used when you need attachments for a specific statute, and it requires a law_id. It doesn't explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to infer when to use this tool. Lacking explicit when-not-to-use guidance prevents 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?
No annotations are provided, so the description carries the full burden. It discloses that it compares the most recent amendment, returns Markdown formatted output, and shows changed articles. While it does not explicitly state read-only behavior or edge cases, the verb 'Get' and return format provide adequate transparency for a read-only tool.
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 and well-structured: a one-sentence purpose, a bulleted usage list, and clearly labeled Args/Returns sections. Every sentence adds value without redundancy.
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 tool's simplicity (one parameter, no annotations, output schema present), the description covers purpose, usage, parameter format, and return format comprehensively. It adequately prepares the agent to use the tool correctly, with no major gaps.
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?
The schema only provides a raw parameter name with no description (0% coverage). The description fully compensates by explaining that law_name_or_id accepts either a law name (e.g., '고등교육법') or an ID (e.g., 'statute:12345' or '12345'), with concrete examples for both formats.
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: 'Get the old/new article comparison (신구조문대비) for a law' and specifies it compares the most recent amendment side by side. This specific verb+resource+scope distinguishes it from sibling search and history 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?
The description includes an explicit 'Use this tool when' section listing three concrete scenarios (see what changed, compare before/after, understand revision scope). However, it does not explicitly name alternatives or state when not to use the tool, so it falls 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?
With no annotations, the description carries the burden of behavior disclosure. It states that the output is a 'Markdown formatted list of amendments with dates and summaries', which gives the agent a clear picture of what to expect. It doesn't mention error cases or edge scenarios, but for a read-only history tool, this is adequate.
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 structured into a purpose statement, a bulleted 'use when' list, and explicit Args/Returns sections. Every sentence adds value, and the layout makes it easy to scan.
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?
The tool is simple with a single required parameter. The description covers what it does, when to use it, how to pass the parameter, and what the return looks like. Given the presence of an output schema, no additional return details are needed. The description is fully sufficient for this tool's complexity.
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?
The schema's property 'law_name_or_id' has no description, leaving 0% schema coverage. The description compensates with a detailed explanation of accepted formats: law name (with example) or ID (with example). This is exactly the kind of semantic enrichment the agent needs for correct invocation.
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 a clear verb+resource: 'Get the revision history (연혁) of a law.' It goes on to specify what information is shown (enactment, amendment, changes). This clearly differentiates it from sibling tools like search_law_articles and get_external_links, which serve different purposes.
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 lists three concrete user intents for using this tool ('Know when a law was last amended', 'Track the evolution...', 'Find historical versions...'). It does not mention alternative tools or exclusions, but provides clear context for when this is the right choice among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the output format (Markdown formatted links) and that the tool provides access to features not available via the MCP. It could mention validation behavior, but for a simple link generator, this is adequate.
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 well-structured with an intro, bullet-point use cases, and clear Args/Returns sections. Every sentence contributes value, and there is no unnecessary information.
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?
For a simple tool with one parameter and an output schema, the description covers purpose, usage scenarios, parameter semantics, and return type. It provides enough context for an agent to select and invoke the tool correctly.
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?
The schema provides zero coverage, but the description compensates fully by explaining the parameter format with examples (e.g., 'statute:12345') and indicating it comes from search results. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates external links to the National Law Information Center website, with a specific verb+resource. The listed use cases (view original source, share direct link, access extra features) distinguish it from sibling search and read 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?
The description explicitly lists when to use the tool via 'Use this tool when the user wants to' followed by three concrete scenarios. It does not name alternatives or exclusions, but the context makes the differentiation 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?
With no annotations, this description carries the full burden of behavioral disclosure. It details two distinct behaviors: for specific article lookup it returns exact content directly with no further steps, and for broad keyword search it returns a summarized list with Typed IDs that must be used with read_legal_resource. This is strong behavioral transparency, though it omits potential edge cases or error handling.
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 well-structured with a one-line summary followed by clear capability sections and usage tips. It is somewhat longer than strictly necessary but every sentence contributes meaningful information and it is effectively front-loaded.
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?
Despite having only one parameter and no annotations, the description thoroughly covers the tool's dual-mode behavior, how to use its results, and directs users to sibling tools when appropriate. It is complete enough for an agent to select and invoke the tool correctly, especially with the output schema available.
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?
The input schema only has a query parameter with no description (0% coverage). The description compensates richly by providing concrete query examples ('Civil Act Article 103', '민법 제103조', '2010다102991') and explaining how the query type affects behavior. This gives an agent a clear understanding of how to construct queries.
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 the 'Primary interface for searching Korean laws, precedents, and administrative rules,' with a specific verb and resource. It also distinguishes itself from sibling tools by explaining it is a 'Smart Search' that adapts to query type and explicitly references alternatives like search_law_articles for article-level keyword searches.
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 explicit when-to-use guidance: ALWAYS try to be specific, and for finding articles containing keywords, first search for the law to get its ID, then use search_law_articles(law_id, 'keywords'). It also mentions read_legal_resource for obtaining full text of broad search results, clearly covering alternatives and exclusions.
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?
With no annotations, the description carries the full burden and does excellent work: it discloses automatic reference resolution appending content, fallback handling for outdated IDs ('ID -> MST -> Detc'), and the markdown return format. These behavioral traits are not evident from the schema or annotations, adding substantial transparency.
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 well-structured with clear sections (Args, Features, Return), uses bullet points for readability, and every sentence adds value. It is appropriately sized for a tool with one parameter and notable behavioral nuances, without being verbose or repetitive.
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?
For a tool with a single parameter and no annotations, the description is remarkably complete. It covers the exact purpose, parameter format and source, behavioral features, and return output. The sibling context suggests a workflow where this tool logically follows a search, and the description supports that. The presence of an output schema is a bonus but not needed here since the description already explains the return format.
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?
The schema only defines resource_id as a string with no description (coverage 0%). The description fully compensates by explaining the required 'type:id' format with examples, and explicitly states the ID is sourced from search_korean_law output. This adds essential semantic meaning that the schema lacks.
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 a clear, specific action: 'Reads the full content of a specific legal resource using its Typed ID.' This distinguishes it from sibling search tools by specifying a resource retrieval action rather than a search. The mention of 'statutes, precedents, or rules' further clarifies the resource scope.
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 context by stating that the resource_id is obtained from 'search_korean_law' output, telling the agent when this tool fits in a workflow. It also highlights 'saving extra round-trips' as a benefit, implying use when you need full content and resolved references. However, it does not explicitly mention when not to use it or directly contrast with sibling tools, so it stops short of full exclusion guidance.
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/joohyukjung/korean-law-mcp/badges/card.svg)](https://glama.ai/mcp/servers/joohyukjung/korean-law-mcp)

Score Badge

Copy to your README.md:

[![korean-law-mcp MCP server](https://glama.ai/mcp/servers/joohyukjung/korean-law-mcp/badges/score.svg)](https://glama.ai/mcp/servers/joohyukjung/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/joohyukjung/korean-law-mcp'

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