Server Quality Checklist

Tool Scores

• get_annexesB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the extraction method (lawName+'별표N') and a note about content location, which is useful context beyond the annotations, but it does not describe download/return behavior or other nuances. Given the annotations, 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.

  Conciseness4/5

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

  The description is extremely concise: a single sentence stating purpose and extraction pattern, plus one hint sentence. It is front-loaded with the identifier '[별표]' and avoids redundant details. No filler is present, though the brevity limits the depth of guidance provided.

  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 6 parameters, no output schema, and a specialized retrieval purpose, the description provides the core purpose and a usage hint but does not explain return formats, error conditions, or comprehensive selection logic against siblings. The detailed schema compensates for parameter understanding, but the overall context is still somewhat thin for an agent deciding when to invoke this 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%, so all 6 parameters are already documented with meaning. The description's pattern lawName+'별표N' adds a small usage hint, but it largely repeats what the schema conveys (e.g., lawName can include '별표4'). No significant added value beyond the schema, so baseline 3 applies.

  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 retrieves annexes/forms (별표/서식) and gives the pattern lawName+'별표N' for extraction. It is specific to a resource type and distinguishes itself from siblings like search_law (search) and get_law_text (full text) by focusing on annex content, though it does not explicitly name those 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 offers a usage hint ('금액/기준은 별표에 있는 경우 많음' – amounts/criteria are often in the annex), implying when to use the tool for such content. However, it lacks explicit when-not-to-use guidance and does not mention alternative tools for comparison, leaving the decision partly to inference.

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

• get_decision_textB
  3.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavior beyond this: full=false (default) progressively condenses the body, which informs the agent that full=true is required for unabridged text. This complements, and does not contradict, 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 compact — a single front-loaded line with no filler. The leading 'Korean-law-mcp —' prefix is meta labeling rather than functional content, and the dense Korean shorthand (계단식 축약) reduces immediate parseability, but the description remains efficient and well-oriented.

  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 complex — an 18-domain enum, a nested options object with domain-specific structures (treaty, english_law, precedent), and no output schema. The rich schema (100% coverage) carries most of the weight, and the description supplies the key default behavior. Still, the description leaves usage context (fetch vs search) unaddressed, which is significant given the absence of an output schema.

  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%, so all four parameters (domain, id, full, options) are already documented in the schema, including the full default behavior, domain enums, and options structure. The description restates domain+id and the full=false default without adding meaning beyond the schema, so it only meets the baseline of 3.

  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 states a specific action — full-text retrieval (통합조회) of decisions across 18 domains using domain+id. It identifies the resource (decision text) and the retrieval mechanism. However, it does not explicitly name siblings like get_law_text (law text vs decision text) or search_decisions (search vs direct id fetch), so differentiation is implied rather than stated.

  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 given on when to use this tool versus alternatives. The description never mentions search_decisions, get_law_text, or when direct id-based retrieval is appropriate. The only usage hint ('obtained from search results') lives in the schema's id description, not the tool description, so the agent gets no explicit routing help between 9 siblings.

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

• execute_toolA
  3.5/5.0
  Behavior4/5

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

  Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description does not repeat that. It adds the important constraint that the tool must come from discover_tools, which is behavioral context beyond the annotations. No contradiction with annotations exists.

  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, brief sentence that front-loads the purpose and parameter essentials without any fluff. It is appropriately short for a simple proxy concept, though it could benefit from slightly more elaboration without losing conciseness.

  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 complexity of a proxy tool that can execute any tool, the description is minimal and omits key guidance. It does not explicitly state the prerequisite of calling discover_tools first, nor does it explain error handling or what happens with invalid tool names. The schema provides some context, but the tool description itself is insufficient for a complete understanding.

  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%, and the description merely restates the parameter names (tool_name + params) without adding further meaning. Since the schema already documents both parameters fully, the description adds no extra value, matching the baseline score for high coverage.

  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 that this is a proxy execution tool for tools discovered via discover_tools, taking a tool_name and params. It effectively identifies the function as a meta-tool that runs other tools, which distinguishes it from the specific sibling tools. However, it does not explicitly mention the return value, though that is implied to be the result of the underlying tool.

  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 the tool is to be used after discover_tools by referencing 'discover_tools 결과 도구' (tools from discover_tools results), but it does not explicitly state when to use it versus directly calling a specific tool. It lacks clear guidance on prerequisites or exclusions, leaving usage conditions to inference.

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

• discover_toolsA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: it is a meta/category-search tool for 80+ specialized domains. Nothing in the description contradicts the annotations — '카테고리 검색' (category search) is consistent with a read-only, idempotent lookup.

  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 compact — a single sentence with the meta/fallback context front-loaded before the category list. While the parenthetical enumeration is dense, there is no waste and the key routing instruction comes first.

  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 simple one-parameter discovery tool with rich annotations and 100% schema coverage, the description is mostly sufficient: it states when to use it and what it searches. However, it does not describe the output/return format (there is no output schema), and the Korean-only text plus ambiguous '위 도구' reference leaves some agent-facing details unresolved.

  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%: the 'intent' parameter is described with meaning and examples ('공정위', '조약', '용어', '헌재'). The description's listing of categories (조세심판, 관세, 헌재, etc.) reinforces what 'intent' accepts but adds little beyond the schema. Baseline 3 applies since the schema already carries the heavy lifting for the single parameter.

  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 states a clear purpose: a meta-tool for category-based search across 80+ specialized legal tools (tax appeal, customs, constitutional court, etc.). It distinguishes itself from the sibling tools by branding itself as '[메타]' (meta) and a fallback when standard tools fail. The purpose is specific and recognizable, though it never names actual sibling tools and is written in Korean.

  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?

  It gives an explicit condition — '위 도구로 안 되는 경우' (when the above tools don't work) — framing it as a fallback/discovery gateway. However, '위 도구' is vague and does not identify which siblings it applies to, nor does it state when NOT to use it or what 'not working' means. The guidance is present but underspecified.

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

• get_law_textA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the jo conversion rule, which is useful behavioral detail. However, it states mst/lawId are 필수 (required) while the schema lists no required parameters, a contradiction with the schema. It also doesn't clarify what happens when jo is omitted. These inconsistencies reduce transparency.

  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 dense sentence that front-loads the purpose and includes key usage details. It is concise and avoids fluff, though the parentheticals make it slightly dense. It earns a 4.

  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 a simple lookup, but the description leaves ambiguity about behavior when jo is omitted and the return format. It also has the requiredness inconsistency with the schema. Given the tool's simplicity and the annotations covering safety, it's mostly complete but has notable gaps.

  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%, so all four parameters are already documented in detail. The description repeats the jo conversion rule but adds no new semantic beyond the schema. It mentions mst/lawId necessity, which is more of a usage note than parameter semantics. Baseline 3 is appropriate.

  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 retrieves full text of a specific article ('조문 전문 조회'), which is a specific verb+resource. It distinguishes from siblings like search_law (which finds laws) and get_decision_text (which gets decisions) by focusing on article-level 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly indicates that mst/lawId are obtained from search_law, establishing a workflow. However, it does not mention when to prefer this over other tools like get_annexes or legal_research, nor does it state when not to use it. The context is clear but lacks exclusions.

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

• ordinance_radarA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, which cover the safety profile. The description adds the specific behavioral logic (extracting cited statutes, comparing effective dates, flagging maintenance targets), which goes beyond the annotations. However, it does not disclose potential limitations (e.g., how the analysis handles missing data, or whether it only works on Korean ordinances), so it provides partial value but not rich 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.

  Conciseness4/5

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

  The description is concise (about three sentences) and front-loaded with a clear purpose. It avoids repeating schema details and each sentence contributes (purpose, target user, input requirement). It is slightly longer than necessary but not wasteful. The structure effectively communicates the essential information without padding.

  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 has no output schema, so the description should at least hint at the return value. It says results are 'automatically flagged' but does not describe the result format (e.g., a list of flagged statutes, a report, or a structured object). It also does not clarify what happens if both ordinSeq and ordinanceName are provided, or if neither is given, which are common edge cases. Given the complexity of the analysis, the description is incomplete in these respects.

  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% — each parameter (id, query, ordinSeq, ordinanceName) has its own description. The description adds a rule beyond the schema: 'ordinSeq(또는 id)나 ordinanceName 중 하나 지정', clarifying that the agent must supply at least one of these two groups, which is not evident from the empty required array. This is a meaningful semantic addition that helps the agent understand how to combine the 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 states a specific verb ('extracts', 'compares', 'flags') applied to a specific resource (ordinances' cited superior statutes), making it clear this is an analysis tool, not a search or retrieval tool. It uniquely combines extraction with date comparison and flagging, which clearly distinguishes it from siblings like search_law or get_law_text. No ambiguity remains about the tool's function.

  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 for ordinance officers tracking superior law amendments and maintenance decisions. It also dictates the input requirement (one of ordinSeq/id or ordinanceName). However, it does not explicitly state when NOT to use this tool or point to specific alternative tools for other scenarios, so it lacks explicit exclusions. The context is clear but alternatives are not named.

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

• legal_researchA
  4.1/5.0
  Behavior3/5

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

  Annotations already carry the full safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), lowering the burden. The description does add genuinely useful orchestration context — parallel API chaining, automatic scenario/domain detection when unspecified, and the document_review text requirement. But it doesn't disclose richer runtime behavior such as latency, number of sub-calls, or rate-limit implications of the parallel execution. Moderate value over a rich annotation set.

  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 every section earns its place: purpose is front-loaded in the first clause, followed by a compact task table and scenario routing. For a 12-parameter, 8-task, 9-scenario tool this density is justified, not padding. Minor deduction for the encyclopedic listing style, which sacrifices scannability slightly.

  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 high complexity (12 params, 3 enums, 8 tasks, 9 scenarios) and the absence of an output schema, the description covers a lot: task semantics, scenario compatibility, auto-detection behavior, and fallback routing. It does not describe the response/return shape, but with no output schema and a research-category tool this is a tolerable gap. Comprehensive for its complexity tier.

  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%, with every one of the 12 parameters already described in the schema including enums with examples, patterns (YYYYMMDD), and conditional requirements (document_review requires text). The description complements this by cross-referencing task-to-scenario compatibility and default values, but most semantic weight is already in the schema. Baseline 3 is appropriate since the description adds only marginal contextual value over the structured fields.

  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?

  States a specific verb+resource: it is a Korean-law MCP multi-stage research tool that chains multiple APIs in parallel for complex questions. It enumerates 8 distinct task types with concrete examples, and explicitly differentiates from siblings by telling agents to use search_law/get_law_text for single-query answers. An agent can clearly tell this apart from the sibling list.

  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?

  Provides explicit routing guidance: use this only for composite/complex questions ('복합 질문 전용'), and states the exclusion condition — if a single search suffices, use search_law/get_law_text instead. Each task type carries a usage example, and the incompatible/when-to-avoid signals are explicit rather than implied.

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

• search_lawA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description correctly does not repeat the safety profile. It adds valuable behavioral nuance beyond annotations: automatic fallback to autonomous laws/administrative rules on zero results, automatic conversion of abbreviated names, appending of renamed and pending-effective amendments, and guidance on repealed laws. These details help the agent anticipate behavior 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.

  Conciseness4/5

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

  The description is front-loaded with the core purpose ('[법령검색] 법령명·조례명·행정규칙명 키워드검색 → lawId, mst 획득') and then provides relevant behavioral details in a structured, readable manner. It is relatively compact given the amount of behavioral nuance conveyed. Some sentences could be tightened, but it remains efficient and well-organized.

  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 covers key aspects: what it returns (lawId, mst), the types of legal texts covered, fallback behavior, abbreviation handling, and handling of repealed laws. It does not explicitly describe the output format (e.g., list vs. single result) or error conditions, but the display parameter hints at a list of results. Given the tool's complexity and the presence of rich annotations, the description is sufficiently complete for an agent to invoke it correctly.

  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% (both 'query' and 'display' are documented in the schema). The description itself does not add much beyond the schema: it mentions the query searches law names, but the schema already says that. The display parameter is not mentioned in the description. Since the schema fully covers parameter meaning, a baseline score of 3 is appropriate; the description adds no extra semantic 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 states that this tool performs keyword searches for law names, ordinance names, and administrative rule names to obtain the identifiers lawId and mst. It explicitly frames itself as a precursor step ('before querying laws/ordinances/administrative rules to obtain identifiers'), which distinguishes it from siblings like get_law_text or legal_analysis. The verb 'search' and resource are specific and the purpose is unambiguous.

  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 contextual guidance: it is meant to be used before querying laws, ordinances, or administrative rules to obtain identifiers. It also mentions automatic fallback behavior when zero results occur, which helps agents understand what to expect. However, it does not explicitly name alternative tools or state when NOT to use this tool, so it falls slightly short of a perfect 5.

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

• search_decisionsA
  4.2/5.0
  Behavior4/5

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

  Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already carry the safety profile, so the bar is low. The description adds genuinely useful behavioral context beyond those: the default search does NOT include decision full text unless options.includeText=true and options.detailLimit=N are supplied — a non-obvious behavioral trait. No contradiction with annotations; a read-only search matches the declared 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 but information-efficient: the core purpose (18-domain integrated search) is front-loaded, and the two usage rules (precedent full-text, nts routing) follow compactly. It crams a long domain list, but every element earns its place since it encodes the domain enum, which is otherwise only implicit in the schema.

  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 6-parameter tool with nested options objects and no output schema, the description handles domain selection and the one critical behavior (includeText/detailLimit) well. However, it never describes return values or result shape, and with no output schema present the description carries that burden entirely. It also omits pagination/default-result semantics beyond what the schema already states.

  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 rises above baseline by demonstrating real usage patterns for the options object — tying the undocumented option keys includeText and detailLimit to a concrete scenario (full-text precedent retrieval). Since the options schema is a generic propertyNames object with no per-key documentation, the description's example closes a real documentation gap.

  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 '[통합검색] 18개 도메인 ... 통합 검색' — a specific verb (통합 검색, integrated search) bound to an explicit resource (18 named legal domains across precedents, rulings, constitutional decisions, tax, treaties, etc.). The explicit enumeration of all 18 domains with 'domain으로 선택' distinguishes it from siblings like search_law and get_decision_text, which handle narrower scopes.

  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 strong internal routing guidance: '판례 본문까지 필요하면 domain='precedent', options.includeText=true, options.detailLimit=N' tells the agent how to request full precedent text, and '세무 관련 국세청 직접 회신 해석은 domain='nts'' disambiguates a tricky domain mapping. It does not, however, state when to prefer this integrated search over sibling tools (e.g., search_law), so cross-tool routing is left to inference.

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

• legal_analysisA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable behavior beyond that: DB cross-verification against the Ministry of Legislation, distinction between impossible and unconfirmed cases, change/repeal detection for case citations, temporal statute versioning, and mermaid graph output.

  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 dense but well-organized: it front-loads the tool's general purpose, then uses separators to define each mode with its required inputs. Every segment carries load-bearing information; there is no filler.

  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 no output schema, the description explains what each mode produces: verified/existence classification, subsequent-case tracing with change/repeal detection, applicable law version with transitional provisions, and reverse citation graph with mermaid code. Together with the fully described 11-parameter schema, this gives an agent enough context to call 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 100%, so the baseline is 3. The description adds meaningful conditional mapping that the schema does not: which parameters are mandatory per mode, how the jo parameter accepts both natural-language phrases and 6-digit codes, and what each mode requires. This is real added value over the schema alone.

  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 is explicit and specific: it identifies legal_analysis as an integrated verification/analysis tool with four concrete modes (verify_citations, cite_check, applicable_law, impact_map), each naming its target resource and output. It is clearly distinguishable from sibling search/get/retrieval 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?

  Each mode gives a scenario and the required parameters — e.g., verify_citations for existing legal citations in text, cite_check for case-viability, applicable_law for version-at-the-time analysis, and impact_map for reverse citation graphs. What prevents a 5 is that it never explicitly names the sibling alternatives or states when not to use them.

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