This MCP server exposes 4 Korean legal research tools with mostly adequate naming and schemas, but descriptions vary in quality and lack LLM-optimization guidance. Tool names follow verb_noun convention (laws_list, laws_get, laws_article, search) which is good. All 4 tools have descriptions and input schemas are visible in the source. However, descriptions are somewhat generic and lack actionable context for LLM decision-making (e.g., when to call laws_list vs search, or what distinguishes laws_get from laws_article). Parameter descriptions are present but inconsistent, some are well-structured (e.g., 'semantic' enum with clear semantic_date explanation), others are minimal (e.g., 'category' just lists enum values without usage guidance). Output schemas are partially documented (JSON structure visible in return statements) but lack explicit documentation of response field semantics in docstrings. Error handling returns JSON error objects but lacks recovery guidance, an LLM getting 'version not found' has no suggestion for next steps. The server targets a specialized domain (Korean law) which constrains tool design, but general quality principles still apply.

• Add explicit 'when to use' guidance to tool descriptions. Example: 'laws_get' should add 'Use this to fetch the complete text of a law. For a single article or section, use laws_article instead for more targeted results.'
• Enhance error messages with actionable recovery steps. E.g., catch LegalizeError and return 'Law not found: "{{law_name}}". Try laws_list() to see available laws in category "{{category}}".'
• Provide English aliases for non-ASCII enum values, or document that LLMs may need to use Korean strings. Consider: semantic: Literal['공포일자', '시행일자', 'promulgation_date', 'enforcement_date'] with aliases in description.
• Document the 'search' tool's return schema in the docstring. Specify what fields are included (title, url, excerpt, etc.), whether results are paginated, and what 'limit' parameter caps.
• Clarify in laws_list description what 'next_page' means (boolean indicating more results, or next page number?) and how to use it for iteration.
• Add examples to parameter descriptions showing valid inputs, e.g. article_no: '제839조', '839', '839조의2', '839-2' (move from description inline to parameter examples or JSON Schema pattern).
• Document the schema_version field in response JSON, is this a versioning contract that clients should check?