Korean Law MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits: it explains the two distinct search modes (specific article lookup vs. broad keyword search), describes different output formats for each mode (exact content vs. summarized list with typed IDs), and clarifies dependencies (typed IDs must be used with read_legal_resource). It doesn't mention rate limits or authentication requirements, but provides substantial behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (Capabilities, Usage Tips), uses bullet points effectively, and every sentence adds value. It's appropriately sized for a complex tool with multiple behaviors, and the most important information (primary purpose and two search modes) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple search behaviors, integration with other tools) and the presence of an output schema, the description provides excellent contextual completeness. It explains the different output formats, clarifies tool dependencies, and provides comprehensive usage guidance. The output schema will handle return value details, so the description appropriately focuses on behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for the single 'query' parameter, the description fully compensates by providing rich semantic guidance: it explains what types of queries work best (specific article references, case numbers, keywords), provides multiple concrete examples in both Korean and English, and clarifies how different query formats trigger different behaviors.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as the 'Primary interface for searching Korean laws, precedents, administrative rules' with a 'Smart Search' that adapts to query type. It distinguishes itself from siblings by being the main search entry point versus more specialized tools like search_law_articles or read_legal_resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 approaches (e.g., 'ALWAYS try to be specific if you know the law name and article number'), when to use alternatives (e.g., for finding articles with keywords, use search_law_articles instead), and distinguishes between specific article lookup and broad keyword search scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.