LexLink-ko-mcp

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral context: pagination defaults, response format options (JSON/XML/HTML), date range filters, current/historical law selection, and a recommendation to use display=50-100 for law searches. This goes beyond the annotations without contradicting them.

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: a clear purpose sentence, an Args list that documents all parameters, a Returns summary, and two concrete examples. Although longer than minimal, every sentence earns its place given the tool's 13-parameter complexity, and the most important information 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?

For a search tool with no output schema, the description covers all necessary operational context: parameter meanings, defaults, response formats, pagination, and example invocations. The return value is summarized as 'Search results with administrative rules list or error,' which is sufficient for selection and invocation.

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?

The schema has 13 parameters with zero descriptions, but the Args section compensates completely by documenting every parameter: its meaning, default, allowed values, and format. For example, it explains knd categories, search modes (rule name vs. full text), date formats, and the OC override. This is exemplary parameter documentation.

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 opens with 'Search administrative rules (행정규칙 목록 조회)' and specifies the resource types (훈령, 예규, 고시, 공고, 지침, etc.), making the tool's exact function and scope clear. This distinguishes it from sibling law search tools like law_search or elaw_search, which target statutes rather than administrative rules.

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 clearly establishes that this tool is for searching Korean administrative rules and provides usage examples for different query patterns. However, it does not explicitly state when to prefer this tool over sibling alternatives or when not to use it, so it stops short of full alternatives guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description consistently describes a retrieval operation. It adds useful behavioral context by specifying that the response includes content, addenda, and annexes, and that errors may occur, which goes beyond the annotation-only information.

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 a concise summary, an explicit Args list, Returns note, and examples. Every sentence adds value, and the bilingual heading is efficient. No redundancy or filler.

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?

For a read-only retrieval tool with no output schema, the description covers purpose, all parameter semantics, return content (full text with annexes), error behavior, and usage examples. This is complete enough for an agent to invoke the tool correctly without additional information.

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 coverage, the description fully compensates by explaining each parameter: id (required if lid/lm not provided), lid (alternative), lm (exact match), oc (override), and type (format with default). This gives the agent complete understanding of all five parameters.

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 'Retrieve administrative rule full text' with a specific verb and resource, and further specifies that it includes rule content, addenda, and annexes. This distinguishes it from sibling search tools like admrul_search.

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 clear context for when to use the tool (to retrieve full administrative rule text) and explains the alternative parameter selection via id, lid, or lm. It includes concrete examples but does not explicitly contrast with search tools or state when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context about return format ('List of semantically related law articles'), search scopes, and response types (JSON/XML/HTML). It does not claim anything contradictory, and the added detail is meaningful beyond 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.

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

The description is well-structured with Args, Returns, and an Example, and key guidance is front-loaded. The ⭐ marketing text and the redundant Korean API name add slight noise, but every functional sentence earns its place.

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?

For a moderate-complexity read-only search tool with no output schema, the description covers purpose, parameters, return values, and an example. It does not explain potential error cases or pagination, but it is sufficiently complete 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.

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

Schema description coverage is 0%, so the description must compensate, and it does well. It explains query, search (with values 0 and 1), oc, and type, including defaults. 'Optional OC override' remains vague, but the overall parameter documentation is strong.

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 'Finds laws semantically related to a given law name or keyword' and is positioned as 'PREFERRED TOOL for discovering related laws from vague topics.' This distinguishes it from exact-match legal searches and among the many sibling search tools.

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?

Explicit usage guidance is provided: 'Use this when user wants to explore laws around a general subject' and 'Best for: Finding related laws like 민법 → 상법.' However, it does not mention when not to use it or explicitly name alternative tools, so it misses the full 5.

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

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

The description discloses that it uses semantic search and returns full article text, and explains the search scope options that change behavior. It includes an example return value. However, it contains an inconsistency regarding default display value (description says 20, schema says 7), which slightly undermines transparency. Annotations already declare it read-only and idempotent, so no conflict.

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-organized with sections for usage, arguments, returns, and an example. It is front-loaded with a strong recommendation and includes useful details without excessive fluff. The minor default value discrepancy is a small deduct.

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?

For a 6-parameter tool with no output schema, the description covers usage guidance, parameter meanings, return summary, and an annotated example. It lacks detailed response structure but provides sufficient context for a typical AI agent. The sibling comparison and scoping options add completeness.

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, the description provides essential meaning for all 6 parameters: query (natural language), search (four scope enums), display, page, oc, and type. It gives a concrete query example and explains search scope values, though the default for display is incorrect compared to the schema.

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 it is an AI-powered semantic law search tool that returns full article text, and explicitly distinguishes itself from eflaw_search by being more comprehensive. It also positions itself as the preferred tool for vague queries, making its purpose unambiguous.

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?

It explicitly instructs to use this tool first when intent is unclear or conversational, and provides example natural language queries like '뺑소니 처벌'. It also references eflaw_search as an alternative for comparison, though it lacks explicit 'when not to use' exclusions.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context by specifying what is compared (article text across revisions) and the output format (side-by-side line-level diff), which goes beyond annotation information. No contradictions 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.

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

The description is concise and well-structured: a one-sentence purpose, a usage tip, a clear Args list, a Returns section, and an example. Every line adds value; there is no redundancy or fluff.

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?

For a 6-parameter tool with no output schema, the description is complete: it documents all parameters, return format, provides a concrete example, and explains the prerequisite relationship with law_amendment_summary. This is sufficient for an agent to invoke the tool correctly without additional information.

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?

Schema description coverage is 0%, so the description must fully document parameters. It explains all 6 parameters: mst_old (older version, from law_amendment_summary), mst_new (newer version), article (number with example), article_branch (branch number with example and default), oc (optional override), and type (format with default and options). The example call further clarifies usage.

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 a specific action ('Compare how a specific article changed between two law versions') with a resource (specific article, two MST versions). It distinguishes from siblings by referencing MST values from law_amendment_summary, making its role in the workflow explicit.

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 gives clear context: 'Use MST values from law_amendment_summary to compare article text across revisions.' This implies a prerequisite workflow and tells users where to obtain the required MST parameters. It does not explicitly list alternative tools or when not to use, but the context is strong enough for correct usage.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds that it parses HTML pages from law.go.kr, implying a web-scraping mechanism that could be fragile. It also claims '100% accurate citation data with zero API cost,' which is useful operational context. However, it does not disclose potential rate limits or failure modes of scraping, so it doesn't fully cover behavioral risks.

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 (Args, Returns, Examples, Workflow) and is appropriately sized for the tool's complexity. It front-loads the purpose and uses concise bullet-like formatting. Each sentence adds value, including practical examples and workflow guidance.

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?

With no output schema, the description fully explains return values including success, law_id, law_name, article, citation_count, citations, internal_count, and external_count. It also provides two complete usage examples and a workflow that integrates with sibling tools. For a tool of this complexity, the description is comprehensive.

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?

Schema has no parameter descriptions (0% coverage), so the description must explain all parameters. It does so thoroughly: mst is defined as Law MST code with guidance to get from search results, law_name with a Korean example, article with example '3 for 제3조', article_branch with default 0 and example '2 for 제37조의2', and oc as an optional override defaulting to env var. This exceeds basic schema information.

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 function: 'Extract citations from a law article' and specifies it extracts all legal citations referenced by a specific law article. It distinguishes from siblings by detailing the scraping of official hyperlinked citations from law.go.kr HTML pages and listing internal/external citation types, making it unique among the many search/service tools.

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 an explicit workflow: 'First use eflaw_search... Then use article_citation... Optionally use eflaw_service to get the full article text.' It also tells users where to get the mst parameter ('get this from eflaw_search or law_search results'), clearly situating this tool relative to alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds value by enumerating the returned data: 'cache hit rate, entry count, and law name resolver stats.' No contradiction with annotations; it supplements them with behavioral detail.

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 short and front-loaded, but the final 'Returns:' block redundantly restates what was already mentioned in the first paragraph. Minor waste, but overall efficient and well-structured.

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?

This is a simple, zero-parameter, read-only statistics tool. The description adequately explains what it returns and its purpose, and annotations cover the safety profile. Nothing significant is missing given the tool's low complexity.

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?

The tool has zero parameters, and the schema coverage is trivially 100%. According to the rubric, 0 parameters earns a baseline of 4, and the description does not need to add parameter semantics.

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 'Show cache and resolver statistics' with a specific verb and resource, and it uniquely distinguishes this tool from all sibling tools that are search/service related. The Korean translation adds clarity for localized users.

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 clear context with 'Useful for monitoring server performance,' indicating an appropriate use case. However, it does not explicitly state when not to use it or mention alternatives, though no siblings serve a similar purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds useful behavioral details like response format options (JSON/XML/HTML), search modes, and pagination defaults, but omits deeper behaviors such as return structure, rate limits, or the meaning of 'oc' and 'gana' parameters.

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 a title, summary, explicit args list, return note, and a concrete example. The long list of ministry names is necessary for usability. Every section serves a purpose, and there is no filler or redundancy.

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?

The description covers all parameter semantics and gives an example, which is essential for invocation. However, it lacks details about the structure of the returned data (fields like case number, title, date) and error handling, which is significant given the absence of an output schema. The return statement 'Ministry interpretation list or error' is too generic.

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 schema description coverage at 0%, the description takes on the full burden of explaining parameters. It provides meaningful descriptions for ministry, query, display, page, type, and search, with defaults and valid values. However, a few parameters like sort and gana are only minimally described, and oc is vague ('defaults to env var'), leaving some gaps.

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 function with a specific verb + resource: 'Search law interpretation opinions from Korean central government ministries.' It differentiates itself from sibling tools like expc_search and cgm_expc_service by explicitly scoping to 중앙부처 (central ministries), making its purpose unambiguous.

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 clear context for when to use the tool: when searching for ministry law interpretations. It lists valid ministry values and parameter mechanics (pagination, response formats), but does not explicitly mention alternatives or exclusion conditions, leaving some room for ambiguity among similar search tools in the sibling list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about response formats (JSON/XML/HTML), the OC override, and the return value ('full interpretation text or error'), but does not explain behaviors like error conditions, rate limits, or the meaning of OC. This is modest value beyond annotations 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.

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

The description is front-loaded with the main purpose and uses a clean Arg/Returns structure. It is compact with no redundant sentences; every line serves a purpose, including the helpful reference to cgm_expc_search for ministry values.

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?

For a simple fetch tool with 4 params and no output schema, the description covers the core contract: what it does, what the inputs mean, and what it returns. It does not explain OC or detailed error conditions, but those are minor gaps given the tool's simplicity and the presence of read-only annotations.

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?

Despite 0% schema description coverage, the description adds meaningful context for each parameter: ministry references sibling search values, id is the serial number, type specifies response format with default, and ctx is injected automatically. The oc parameter remains vague ('Optional OC override'), but overall the description compensates well for the schema gap.

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 retrieves full text of ministry interpretations, using a specific verb and resource ('Retrieve ministry interpretation full text'). It distinguishes from sibling search tools (e.g., cgm_expc_search) by emphasizing 'full text' and requiring an id, making the fetch operation unambiguous.

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?

Usage context is implied through the parameters (ministry + id) and the phrase 'full text', suggesting this is used to fetch details after a search. However, there is no explicit guidance on when to use this versus alternatives, no exclusions, and no mention of typical workflow steps (e.g., 'first search with cgm_expc_search').

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds behavioral context by explaining the chaining behavior, the two distinct modes, and the date range defaults, which goes beyond what annotations alone provide.

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 a clear opening sentence, an Args section, a Returns section, and examples. Every line earns its place and the examples concretely demonstrate invocation.

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?

Since no output schema exists, the Returns line plus mode descriptions provide necessary context. It could be clearer on how date range interacts with 'latest two versions' and what 'Response format' means, but overall it is complete enough for a 6-parameter tool.

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 coverage, the description documents all six parameters with meanings and defaults. The law_name example and article explanation (0=summary, 52=제52조) are especially helpful. oc and type remain terse, but they are at least identified as an override and response format.

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 opens with a specific verb ('Track') and resource ('law amendment history') and adds optional article-level diff. It distinguishes itself from sibling tools by framing this as a chained operation that combines amendment summary and article diff.

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 clear conditional usage: article=0 returns only the revision list, while a specified article triggers a diff between the two most recent revisions. However, it does not explicitly compare this tool to alternatives like law_amendment_summary or article_amendment_diff.

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

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

Annotations already declare read-only/idempotent behavior. The description adds valuable context by revealing that the tool chains multiple sub-searches and aggregates results per category, which goes beyond the annotations. It does not discuss rate limits or detailed response structure, but the added behavioral detail is meaningful.

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-organized and concise, including a purpose summary, chain breakdown, parameter list, return summary, and examples. Every section contributes value without redundancy.

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?

For a chained tool with no output schema, the description provides essential information: return categories and invocation examples. It does not specify the exact response structure (e.g., how results are grouped), but the mention of 'results per category' offers some hint. Overall, it is sufficient for selecting and invoking the tool.

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 coverage, the description compensates by explaining all four parameters: query with examples, display as per-category count, oc as an optional override, and type as response format. The explanations for oc and type are slightly vague, preventing a higher score.

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: to prepare for a legal dispute by gathering all decision-type case law. It explicitly enumerates the chained sources (precedent search, admin appeals, constitutional decisions, special tribunal), which distinguishes it from single-source sibling tools.

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 a clear context for use: when preparing for a legal dispute and needing all decision-type legal sources in one call. It does not explicitly name alternative tools for single-source needs, but the composite nature is evident.

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

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

Annotations already declare readOnlyHint/idempotentHint, so safety is covered. The description adds value by disclosing the internal chain pipeline and the combined return structure (statutes, precedent statistics, interpretations, citations), which is behavioral context beyond annotations. No contradictions.

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 front-loaded with a one-line summary, then uses clear sections (Chains, Args, Returns, Examples). Every sentence adds useful information, and the structure is easy to scan.

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 (chaining multiple research steps) and lack of an output schema, the description adequately explains the input parameters, return value, and provides usage examples. It is sufficient for an agent to select and invoke it correctly.

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?

Schema description coverage is 0%, so the description's Args section must compensate. It does: it explains query (with examples), display (results per sub-query), oc (optional override), and type (response format). While 'OC' is cryptic, overall it adds meaningful semantics beyond the bare schema.

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 opens with 'Complete legal research in one call' and enumerates a specific chain (AI search → statutes → precedents with outcome analysis → interpretations → citations), clearly stating it is the most comprehensive single-call research tool. This distinguishes it from sibling search and chain tools.

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 phrase 'most comprehensive single-call research tool' provides clear context for when to use it (comprehensive research), and examples show intended queries. However, it does not explicitly name alternative tools for simpler needs, so it lacks explicit exclusions.

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

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 doesn't need to repeat that. The description adds valuable behavioral context beyond annotations by revealing that the tool performs a multi-step chain (law search → delegation tree → related admin rules → linked ordinances) and returns a structured hierarchy. This informs the agent about potential complexity and the nature of the result, which is beyond what annotations provide.

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 excellently structured: it opens with a one-line purpose, then a chain breakdown, followed by Args, Returns, and Examples. Every sentence earns its place, with no redundancy or filler. It is concise yet comprehensive, using bullet-like formatting that is easy to parse.

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?

The tool has a moderate complexity (chaining multiple lookups) and no output schema. The description covers the purpose, the chain process, each parameter, the return structure, and provides multiple examples. This is nearly complete. However, it lacks details on edge cases (e.g., what if a law has no subordinate regulations) and does not clarify how this tool relates to sibling chain tools like chain_full_research, which would enhance completeness.

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?

Schema description coverage is 0%, so the description must compensate. It does provide an Args block that explains each parameter: law_name with examples, oc as 'Optional OC override', and type as 'Response format'. This adds some meaning beyond the bare schema, but 'OC override' is cryptic and 'Response format' is vague without enumerating allowed values. The examples help for law_name, but the overall parameter semantics are only partially clarified.

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 with a specific verb 'Map' and a concrete resource: the full law system hierarchy. It further breaks down the chain steps (law search → delegation tree → related admin rules → linked ordinances), which distinguishes it from sibling chain tools like chain_amendment_track or chain_dispute_prep. This is a specific, non-tautological statement that tells the agent exactly what the tool does.

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 implies a clear use case: 'Shows how a law connects to its subordinate regulations.' This provides clear context for when to use the tool. However, it does not explicitly exclude alternative tools or name them as alternatives, which would have pushed the score to 5. It is more than just implied usage because the chain description signals its unique role among related tools.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context about the tool's behavior: it searches precedents, analyzes outcomes (인용/기각/파기), and extracts key factors. The Returns section also clarifies what the agent can expect. No contradictions 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.

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

The description is well-structured with sections for purpose, arguments, returns, and examples. It is front-loaded with a concise overview and each sentence in the Args section adds necessary detail. No redundant content, and the format is easy to scan.

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?

The description covers the tool's purpose, parameter details, return summary, and examples. It lacks deeper details like error handling, jurisdiction, or analysis methodology, but given the tool's moderate complexity and strong annotations, this is sufficient for an agent to select and invoke it correctly.

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?

Schema description coverage is 0%, and the description effectively compensates by explaining each parameter in the Args section: query, display, top_n, oc, and type. It provides meanings, defaults, and examples (e.g., display max 100, default 20; type options JSON/XML/HTML). This far exceeds what the schema offers.

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 function: 'Find precedent statistics and key outcome factors for a legal question' and distinguishes it from sibling search tools by emphasizing outcome analysis and 'legal odds'. The verb 'Find' is specific, and the scope is well-defined, setting it apart from general precedent search tools.

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 clear context: 'Useful for assessing legal odds' indicates when to use it. However, it does not explicitly mention alternatives or when not to use it, missing a bit of exclusions. This is still sufficient for an agent to identify the appropriate use case.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is covered. The description adds behavioral details beyond annotations: response formats ('JSON', 'XML', 'HTML'), search modes (search=1 for case name, 2 for full text), OC override behavior ('defaults to env var'), and automatic injection of ctx. It also explains pagination defaults (display max 100, page 1-based). This adds meaningful context beyond the structured annotations.

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 sections for purpose, Args, Returns, and Examples. It is appropriately sized for a tool with 9 parameters and includes only relevant information. The only mild redundancy is the Korean phrase duplicating the English statement, but all content earns its place.

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 (9 parameters, no output schema), the description is remarkably complete. It covers parameter meanings, valid values, defaults, response format options, and an example. It states the return type ('Committee decision list or error') which suffices in absence of an output schema. No significant gaps remain.

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?

Schema description coverage is 0%, so the description carries full responsibility for explaining all 9 parameters. It does so thoroughly: committee lists valid Korean names, query has default '*', display has max/default, page is 1-based, oc overrides env var, type lists accepted formats, search defines numeric meanings, sort and gana are briefly described. This fully compensates for the schema's lack of descriptions.

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: 'Search committee decisions (위원회 결정문 목록 조회)' from Korean government committees. The verb 'Search' plus the specific resource 'committee decisions' distinguishes it from sibling tools like law_search and prec_search, which target different legal document types.

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 clear context: it searches decisions from Korean government committees, and lists the valid committee names. It includes an example. However, it does not explicitly state when not to use this tool versus alternatives (e.g., 'use for committee decisions only'), but the context is unambiguous enough for an agent to select it appropriately.

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

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 does not need to repeat safety traits. It adds minor context: 'ctx: MCP context (injected automatically)' and 'Returns: Full decision text or error'. This provides a bit of behavioral detail (auto-injection, error possibility) but does not go beyond what annotations already cover in terms of side effects.

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 a purpose line, an args list, and a returns line. It is concise and easy to scan, with no unnecessary words. The inclusion of a Korean translation adds clarity for the target domain, and the list format aids quick parsing.

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 simplicity of the tool (read-only retrieval with four simple parameters and no output schema), the description is largely complete: it specifies the return type and error possibility. It does not detail potential error scenarios or page limitations, but for a straightforward read action, this level of detail is sufficient. The lack of an output schema is partially mitigated by the explicit 'Returns' line.

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, the description compensates by explaining all four parameters: committee (same as committee_search), id (decision serial number), oc (optional override), and type (JSON/XML/HTML). This goes beyond the schema's bare types. However, 'oc' remains vague ('OC override' without elaboration), which prevents a full score.

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 function: 'Retrieve committee decision full text' with a Korean equivalent. It specifies the resource (committee decisions) and the action (retrieve full text), and distinguishes it from sibling tools like committee_search which likely handles searching. The phrase 'full text' clarifies the output granularity.

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 implies usage context by noting 'committee: Committee name (same values as committee_search)', linking it to its search sibling. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'use after committee_search to retrieve details') or any exclusions. The guidance is more inferred than directly stated.

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

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

Annotations already declare read-only and idempotent behavior. The description adds substantial behavioral detail: pagination defaults, max results, sort orders, response formats (JSON/XML/HTML), search modes, and auto-injected context. It doesn't cover rate limits or auth, but this is strong for a read-only search API.

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-organized with Args, Returns, and Examples sections. Every sentence contributes information; parameter descriptions are concise one-liners and examples illustrate real use cases without fluff.

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?

Covers the full parameter space, defaults, examples, and a returns line describing the output as a list or error. It lacks a detailed breakdown of result item fields, but for a search API returning a list this is acceptable; no output schema exists, so a bit more detail on the result structure would push it to a 5.

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?

Schema description coverage is 0%, and the description compensates by documenting all 13 parameters with defaults, formats, valid values, and date range syntax. This goes far beyond the schema and is essential for correct invocation.

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 it searches administrative appeal decisions, with a specific Korean title and a definition of administrative appeals. This uniquely distinguishes it from sibling tools that search laws, precedents, or other legal materials.

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 strong contextual usage guidance including examples for keyword, date range, and broad searches, plus parameter explanations. However, it does not explicitly mention when not to use this tool or name alternative tools for other legal search needs.

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

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

Annotations already declare read-only and idempotent, and the description adds valuable behavioral context: the 'sections' parameter controls whether reasoning is excluded, the summary mode returns specific fields (사건명, 청구취지, 재결요지, 주문), and the 'type' parameter selects response format. It also mentions error returns. This goes beyond annotation basics.

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 an intro, args list, returns, and examples. It is moderately sized but every part adds value, including the Korean title and two usage examples that demonstrate both minimal and more complex calls.

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 lack of an output schema and five parameters, the description is quite complete: it explains what is returned, the effect of sections, response formats, and optional overrides. The only minor gap is not explaining how to obtain an ID if it is unknown, but for a service tool this is sufficient.

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?

Schema description coverage is 0%, but the description fully explains every parameter (id, lm, sections, oc, type, ctx) with values, defaults, and behavior. The sections parameter is especially well documented, listing both modes and the fields returned in summary mode.

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 retrieves the full text of Korean administrative appeal decisions, with a specific verb ('Retrieve') and resource. It distinguishes from sibling search tools like decc_search by focusing on full-text service rather than searching.

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 implies usage through examples: retrieve by ID or with an optional case name. It hints at when to use this tool (when you have a decision sequence number) but doesn't explicitly contrast with alternatives like decc_search or admrul_service. Could be improved by stating 'use decc_search to find IDs first.'

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavior context by defining response format options (JSON/XML/HTML), sort/date/dictionary search parameters, and noting that the result is a decision list or error. 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.

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

The description is well-structured with Args, Returns, and Examples sections. Each parameter line is terse and informative, and the examples are compact. There is minor repetition of the tool's purpose in Korean and English, but this aids bilingual clarity rather than bloating the text.

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?

All 12 parameters are covered, examples demonstrate common use cases, and the return type is stated generically as 'Search results with Constitutional Court decision list or error.' Given the tool's complexity and lack of output schema, slightly more detail on the result structure would be beneficial, but the description is sufficient for correct selection and invocation.

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 schema description coverage at 0%, the description compensates fully by listing and explaining all 12 parameters, including defaults, constraints (display max 100, page 1-based), allowed values (sort order, search type), and examples. This goes well beyond what the bare input schema provides.

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 opens with 'Search Constitutional Court decisions (헌재결정례 목록 조회)' and repeats 'Search Korean Constitutional Court decisions.' This clearly specifies the action (search) and resource (Constitutional Court decisions), and the resource name distinguishes it from sibling law/ordinance/precedent search tools.

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 concrete usage examples, such as keyword search and date-based search, and explains parameter behaviors. However, it does not explicitly contrast this tool with alternatives like detc_service or other decision-list search tools, so it stops short of full when-to-use/when-not-to-use guidance.

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

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

Annotations already indicate readOnly and idempotent behavior. The description adds meaningful context beyond that, such as how the 'sections' parameter alters the payload ('summary' excludes 전문), the effect of 'type' on response format, and the 20KB constraint for PlayMCP.

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-organized with Args, Returns, and Examples. It is reasonably concise, though the examples and some parameter details could be trimmed without losing essential meaning.

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?

There is no output schema, so the description compensates by stating that the tool returns full decision text or an error. It also gives concrete examples and behavior around response size. It could still mention prerequisites or limitations, but it is complete enough for a read-only retrieval tool.

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?

Schema description coverage is 0%, so the description carries the burden. It explains id as a Constitutional Court sequence number, lm as an optional decision name, sections as summary/full mode, and type as JSON/XML/HTML. Only 'oc' remains vague as 'Optional OC override'.

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 states a specific action and resource: 'Retrieve Constitutional Court decision full text' (헌재결정례 본문 조회). This clearly distinguishes detc_service from sibling search tools such as detc_search, and the service pattern is apparent.

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?

Usage guidance is implied rather than explicit. It recommends sections='summary' for PlayMCP to stay under 20KB, but it does not explicitly say when to choose this tool over detc_search or other sibling retrieval tools.

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

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 safe read-only behavior is established. The description adds minimal extra context (e.g., 'Returns: Search results or error') but no details on pagination behavior, rate limits, or authentication. This meets the baseline without going beyond.

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-organized with a purpose statement, use case, and parameter list. It is concise overall, though the opening bilingual phrase and the paraphrase 'searches the linkage' slightly repeat the headline concept without adding much new information.

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?

With no output schema, the description gives only a vague 'Returns: Search results or error.' It thoroughly covers purpose and parameters, and the annotations plus sibling-tool context provide additional scoping. The main gap is the exact shape of search results, but for a simple search tool this is acceptable.

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?

Despite 0% schema description coverage, the Args section thoroughly explains every schema parameter: defaults for query, display, page, response format, and OC override behavior. It even adds constraints like max=100 and 1-based page numbering, fully compensating for the missing schema descriptions.

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 a specific verb ('searches the linkage') and resource (everyday terms to legal equivalents), making the direction unambiguously everyday-to-legal. It distinguishes itself from sibling search tools by highlighting this unique mapping.

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?

It provides a clear use case: 'finding the correct legal terminology when starting from common language.' It doesn't explicitly name alternative tools or exclusion conditions, but the contextual guidance is sufficient for basic tool selection.

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

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 only the bridging function and a generic 'Search results or error' return note, which provides minimal behavioral context beyond annotations.

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 front-loaded with the purpose, followed by a compact parameter list and a short returns line. Every sentence adds information about what the tool does or how to use its Arguments, with no filler.

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?

The tool is simple, but the absence of an output schema means the description's 'Search results or error' return statement is insufficiently descriptive. It also lacks usage differentiation from closely related sibling tools, leaving some gaps for an agent trying to understand the result format or when to prefer this tool.

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, the description compensates by listing each parameter, its default, and constraints (e.g., display max 100, page 1-based). The 'oc' parameter is vague ('Optional OC override') and 'ctx' is not in the schema, but overall the parameter explanations are useful and non-redundant.

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 identifies the tool as a search over everyday terms and their legal equivalents, using the specific verb 'Search' and a distinct resource scope. However, it does not explicitly contrast itself with sibling search tools such as law_search or dlytrm_rlt_search, so differentiation is implicit 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.

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

The description implies the tool is for translating common language into legal terminology but does not explicitly state when to use it over sibling search tools such as law_search or dlytrm_rlt_search. No alternatives or exclusions are provided, so the guidance is only implicit.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds valuable context by stating that the API only supports HTML output and that the response schema is undocumented. This goes beyond the annotations to set expectations about return format and potential errors.

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?

Description is well-organized with sections for Args, Returns, and Examples. It is concise, though the first two sentences repeat the same idea ('Retrieve law-ordinance linkage statistics' vs 'retrieves statistical information about how national laws are linked to local ordinances'). The example usage is helpful.

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?

With no output schema, the description appropriately discloses that the response is HTML and undocumented, which manages expectations. It also provides an example call. Given the simplicity of the tool (1 optional param, read-only), this is complete enough, though it could be slightly more detailed about what the dashboard displays.

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?

Schema coverage is 0%, but the description compensates by explaining the 'oc' parameter as an optional OC override defaulting to env var. This clarifies the parameter's purpose, though it doesn't elaborate on what 'OC' stands for. Given only 1 parameter, this is adequate.

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?

Description clearly states the tool retrieves law-ordinance linkage statistics, with a specific verb ('Retrieve') and resource ('law-ordinance linkage statistics'). It distinguishes from sibling search tools by focusing on the linkage between national laws and local ordinances, and mentions the HTML dashboard output.

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?

No explicit guidance on when to use this tool versus alternatives. The HTML-only note implies a constraint, but there is no mention of alternatives or scenarios where this tool is preferred. The sibling tools (law_search, eflaw_search, etc.) suggest related functions, but this description does not differentiate usage based on context.

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

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

Annotations already indicate readOnly and idempotent safety. The description adds behavioral context beyond annotations: it states that only the requested article/paragraph is returned, the jo format constraints, and that ef_yd is required when using mst. This gives useful operational expectations without contradicting annotations.

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 and front-loaded with the core purpose, then a clear 'BEST TOOL' statement, parameter explanations, and illustrative examples. Every sentence provides necessary operational detail; there is no fluff or redundancy.

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 has 9 parameters, no output schema, and no schema descriptions, the description is remarkably complete for selection and invocation. It covers parameter formats, practical examples, and response types. It lacks error-condition details or explicit return-value structure, but these are not essential for basic tool selection and invocation.

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?

Schema description coverage is 0%, so the description carries full responsibility for parameter semantics. It explains each parameter (id/mst, ef_yd, jo format with zero-padding and branch suffix, hang, ho, mok encoding, oc override, type) and provides concrete examples for each, making parameter usage clear and unambiguous.

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 'Queries specific article/paragraph by effective date' and identifies itself as the 'BEST TOOL for querying specific articles', which distinguishes it from full-law search siblings. It provides concrete article examples and emphasizes that it returns only the requested section, avoiding large full-law responses.

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 explicitly tells when to use this tool (for querying specific articles/paragraphs) and why it is preferable ('avoiding large full-law responses'). However, it does not name specific alternative tools or provide explicit when-not-to-use scenarios, so it falls short of the highest bar for usage guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description only needs to add context. It does add useful details: the effective date organization, the recommendation for display=50-100, and the OC override defaulting to env var. No contradictions 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.

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

The description is well-organized into intro, Args, Returns, and Examples. Every sentence and parameter line adds value, and the two examples are practical. It is detailed but not bloated.

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?

With 9 parameters and no output schema, the description covers all necessary information: parameter semantics, return format ('Search results with law list or error'), and usage examples. The agent can confidently invoke and understand the result.

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?

Schema description coverage is 0%, but the description documents all 9 parameters in the Args block with formats, defaults, and examples. It fully compensates for the missing schema info, even describing the ef_yd date range format and sort options.

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 'Search current laws by effective date' and 'This tool searches Korean laws organized by effective date.' This specific verb-resource-scope combination distinguishes it from sibling tools like law_search and elaw_search.

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 a clear 'when to use' statement: 'Use this when you need to find laws that are currently in effect.' However, it does not mention alternatives or exclusions, so it stops short of full 5-level guidance.

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

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

Annotations already declare readOnly and idempotent, but the description adds valuable behavioral context: it warns that some laws produce responses over 1MB, explains that `jo` returns only the requested article for speed and cleanliness, and describes the return types (full law content or specific article content). This goes well beyond annotation data.

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 an opening summary, an 'IMPORTANT' callout, numbered Args, Returns, and Examples. Each sentence serves a purpose—no fluff. The strong warning is front-loaded to prevent misuse, and the examples make the usage instantly understandable.

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?

Despite lacking an output schema, the description covers invocation requirements (id or mst required, ef_yd with mst), the crucial `jo` encoding, response formats (JSON/XML/HTML), and includes examples that demonstrate both recommended and cautionary usage. It is complete enough for an agent to call correctly.

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 schema description coverage at 0%, the description compensates thoroughly. It documents every parameter (id, mst, ef_yd, jo, chr_cls_cd, oc, type) with clear meaning, provides the exact `jo` format (zero-padded article number plus branch suffix), and gives concrete examples like '017400' for 제174조. This is far more informative than the raw schema.

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 'Retrieve full law content by effective date' and further explains it returns the complete text of a law. It distinguishes itself from search-oriented siblings by focusing on retrieval, and the mention of specific article retrieval via the `jo` parameter adds specificity.

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?

Provides explicit guidance: 'For specific article queries, ALWAYS use the `jo` parameter' and warns about large responses. It also clarifies the id/mst requirement and gives examples of recommended vs. warning-prone usage, effectively telling when to use full retrieval vs. article-specific retrieval.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context like the return format ('Search results with English law list or error') and a recommendation for display size, but does not disclose deeper behavioral traits such as error handling, rate limits, or API quirks. This is consistent with no contradictions.

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 sections for overview, args, returns, and examples. It is slightly verbose with two examples and a redundant 'Useful for' line, but every section serves a purpose given the parameter-heavy nature of the tool.

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 (9 parameters, no output schema), the description covers most essentials: what it does, all parameters, and a basic return description. The return formatting is vague ('English law list or error') but acceptable for a search tool. It does not explain the meaning of sort codes or org/knd filter values, but those are API-specific and not critical for initial selection.

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?

The schema has 0% description coverage, and the description fully compensates by documenting all 9 parameters, including defaults, allowed values (sort options, type formats), and practical guidance (e.g., recommending display=50-100). This adds substantial meaning beyond the bare schema.

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 begins with a specific verb and resource: 'Search English-translated Korean laws'. It clearly differentiates from generic law searches by focusing on English translations. However, it does not explicitly distinguish itself from sibling tools like eflaw_search or law_search, so it falls short of a perfect score.

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 a usage context ('Useful for international users or bilingual legal research') but does not mention alternatives or when not to use this tool. It lacks explicit exclusionary guidance that would clarify its relationship to sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral details beyond that, such as the 'oc' parameter defaulting to an environment variable, the 'type' response format options (JSON/XML/HTML), and the dependency rules for id/mst. It also describes the return value as 'Full English law text with articles or error.' These additions provide meaningful context 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.

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

The description is well-structured with an intro, argument list, return statement, and examples. It is moderately long but every section adds value, including the concrete examples. The organization makes it easy to scan, though it could be slightly more concise.

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?

With no output schema and zero parameter descriptions, the description must be self-contained. It covers all parameters, return behavior, parameter dependencies, and provides two realistic examples. This gives an agent sufficient context to invoke the tool correctly without additional documentation.

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?

The input schema has zero description coverage (0%), so the description carries the full burden. It thoroughly explains each parameter (id, mst, lm, ld, ln, oc, type) with meaningful descriptions and constraints, such as 'required if mst not provided' and 'alternative search method.' Examples further clarify usage. This fully compensates for the schema's lack of property descriptions.

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 function: 'Retrieve English law full text' and specifies it retrieves 'the complete text of Korean laws translated to English.' This provides a specific verb and resource. However, it does not explicitly differentiate from sibling tools like eflaw_service or law_service, so it does not achieve a 5.

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 gives clear usage context: 'Useful for international legal research and cross-border understanding.' It also explains input dependencies (id required if mst not provided, etc.) but does not explicitly state when not to use this tool or mention alternative tools, 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.

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

Annotations already declare readOnly and idempotent hints. The description adds substantial behavioral context, including parameter defaults, max display value, recommended display range, search modes, date-range formats, and OC override behavior. It does not mention rate limits or exact error handling, but what is covered is valuable.

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 a summary, parameter list, return info, and examples. It is lengthy but necessary given 14 parameters; no significant fluff, though the explanatory sentence about government agencies could be seen as slightly redundant.

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?

For a complex 14-parameter search tool with no output schema, the description is highly complete: it covers all parameters, return value, and includes usage examples. This is sufficient for an agent to invoke the tool correctly.

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?

Schema description coverage is 0%, and the description fully compensates by explaining every parameter's meaning, defaults, and constraints. It adds meaning well beyond the raw schema, making each parameter's purpose clear.

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 searches Korean legal interpretation precedents (법령해석례 목록 조회), with a specific verb 'Search' and a well-defined resource. It distinguishes from sibling tools by explicitly naming the domain and scope.

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?

No explicit guidance on when to use this tool versus alternatives like expc_service or cgm_expc_search. The purpose implies usage for searching legal interpretations, but there are no stated exclusions, alternatives, or context cues.

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

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

Annotations already declare this a read-only, idempotent operation. The description adds meaningful behavioral context beyond this: the 'sections' parameter controls whether detailed reasoning is included, with approximate payload sizes (2KB vs 5KB), and the 'type' parameter controls response format. No contradictions 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.

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

The description is well-structured with a clear one-line summary, a bulleted Args section, Returns, and Examples. It is somewhat long, but every section contributes value. The front-loading is good, with the core purpose stated immediately.

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?

For a read-only retrieval tool with 5 parameters and no output schema, the description covers the return content ('question, answer, and reasoning'), parameter semantics, and provides examples. It does not address error conditions or explicitly place the tool in a workflow with search siblings, but it is sufficiently complete for the tool's complexity.

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?

Schema description coverage is 0%, but the description fully documents every parameter: id (required sequence number), lm (optional name), sections (summary/full behavior), oc (override), and type (JSON/XML/HTML). It also explains the behavior of sections with return size implications, which adds significant meaning beyond the bare schema.

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: retrieving the full text of a legal interpretation precedent (법령해석례 본문 조회). It uses a specific verb ('Retrieve') and identifies the resource, but does not explicitly distinguish from sibling tools like expc_search or cgm_expc_service, so it misses the top score.

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?

Usage guidance is implied rather than explicit. The required 'id' parameter indicates the tool should be used when you already have a legal interpretation sequence number, and the examples show how to call it. However, there is no explicit instruction about when to use this tool versus alternatives (e.g., using expc_search to find IDs first).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds only 'Returns: Search results or error', which is generic. It doesn't disclose additional behavioral traits like rate limits, specific output structure, or how the search behaves with different query patterns. No contradictions found.

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 a title, a brief summary, an Args list, and a Returns line. Every sentence provides useful information, with no redundancy or fluff. It is concise yet comprehensive.

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?

For a read-only search tool with no output schema, the description covers the core functionality, parameters, and a basic return note. It is mostly complete, though the return value description ('Search results or error') is minimal and could benefit from specifying what a typical result contains.

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?

The input schema has 0% description coverage, but the description lists all 5 parameters with meaningful explanations: query, display, page, oc, and type. Although 'oc' is not fully expanded, the overall parameter documentation compensates well for the schema gaps.

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 function: searching linkage from law articles to legal terms, with a specific summary 'Article to legal term linkage'. It provides a concrete use case. However, it doesn't explicitly distinguish this tool from sibling tools like lstrm_rlt_jo_search, which may have similar purposes.

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 includes a clear usage context: 'Useful for finding all technical terms in a given article.' This implies when to use it. It does not mention alternatives or exclusions, so it stops short of full guidance.

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

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 useful behavioral context: the tool lists revisions across a date range, reveals the default date window (20100101 to 20261231), and indicates that results include MST identifiers for use with article_amendment_diff. No contradictions 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.

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

The description is well-structured with a concise one-sentence summary, an Args section, a Returns section, and two usage examples. Every sentence earns its place; no fluff or redundant repetition of the schema. It is front-loaded with the main purpose, making it easy for an agent to scan.

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?

For a tool with 5 parameters, no output schema, and moderate complexity, the description is highly complete. It explains the return value (list of revisions with dates, types, MST identifiers), provides default date ranges, and links to a sibling tool for deeper analysis. The examples illustrate typical usage. This is on par with the 'get_calls' calibration example and arguably richer.

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?

Schema coverage is 0%, so the description must carry the full burden. It provides clear formats and defaults for law_name, date_from, date_to, and type, with examples for law_name. The 'oc' parameter is only labeled 'Optional OC override,' which is vague, but the description still offers more than the schema (which has no descriptions). Given the near-complete compensation, a score of 4 is appropriate.

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 opens with a specific verb+resource+scope: 'List all revisions of a law within a date range.' It further clarifies what the tool shows ('when and how a law was amended over time') and distinguishes it from sibling tools like article_amendment_diff by referencing MST values for follow-up. This makes the purpose unmistakable and distinct.

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 clear context: use this tool to query amendment history within a date range. It explicitly points to article_amendment_diff as the next step for seeing specific article changes, which is an alternative/follow-up tool. However, it does not explicitly state exclusions or when not to use it, so it falls just short of a perfect score.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral context: it performs targeted lookup by announcement date and returns only the requested section to avoid large responses. It also documents the OC override behavior, though it does not cover error cases or response formatting details.

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-organized with a one-line summary, a bold usage cue, an Args block, a Returns line, and two concrete examples. Every section contributes necessary information without filler, making it easy for an agent to parse quickly.

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?

This tool has 8 parameters, no required fields, no output schema, and a complex Korean legal citation format. The description fully compensates by defining every parameter, explaining the targeted vs. full-law behavior, listing response format options, and providing multiple worked examples. It is complete enough 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.

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

The schema has 0% property descriptions, so the description carries the full burden for explaining parameters. It does this excellently: id/mst requirements, the jo XXXXXX format with examples, hang/ho/mok formats, oc defaulting to an env var, and type defaulting to JSON are all documented clearly. This is well beyond the baseline for schema-covered tools.

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 opens with a specific verb+resource: 'Query specific article/paragraph by announcement date' and clearly targets individual law provisions. It explicitly positions itself as 'BEST TOOL for querying specific articles' and notes that it returns only the requested article/paragraph, distinguishing it from full-law retrieval siblings.

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?

It clearly states when to use this tool: for querying specific articles like '제174조' or '제3조' and for avoiding large full-law responses. However, it does not explicitly name sibling alternatives or provide when-not-to-use guidance, so it falls just short of a perfect score.

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

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

Annotations already establish read-only and idempotent behavior. The description adds useful context: return format (law list or error), the recommendation for display 50-100 to ensure exact matches, and that 'oc' defaults to an environment variable. This goes beyond the annotations without contradicting them.

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 an intro, args list, and returns section. It is somewhat verbose with the Korean text repeated, but each parameter gets a useful brief description, and the organization makes it easy to scan.

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?

For a 9-parameter search tool with no output schema and basic annotations, the description covers purpose, all parameters, and return value. It lacks error scenarios, sort value examples, and explicit differentiation from siblings, but is generally complete for typical use.

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?

Schema description coverage is 0%, so the description fully compensates by explaining all 9 parameters with concrete details: display limits and defaults, page base, date format (YYYYMMDD), response type options, and filter purposes. This gives the agent meaningful information beyond the raw schema.

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 searches current Korean laws organized by announcement date, using a specific verb and resource. However, it does not explicitly differentiate from sibling search tools like eflaw_search or elaw_search, though the 'current laws by announcement date' scope suggests a distinction.

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?

No explicit guidance on when to use this tool versus alternatives. It implies searching current laws but doesn't mention exclusions or compare with sibling tools like eflaw_search, elaw_search, or admrul_search. The recommendation about display size is parameter-level, not tool selection.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds value by revealing that full-law responses can exceed 1MB and that jo is faster/cleaner for article-level queries. This is meaningful behavioral context beyond the annotations, though it doesn't address auth/rate limits.

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 structure is clear with opening statement, IMPORTANT warning, args list, returns, and examples. It is slightly redundant because the first two sentences restate the same purpose, but otherwise each section earns its place.

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?

For a 9-parameter tool with no output schema and no schema descriptions, this description is fairly complete: it covers all parameters, gives usage warnings, and provides recommended examples. It doesn't fully explain the exact semantics/relationships of lm/ld/ln, which is a minor gap.

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 schema description coverage at 0%, the description compensates by defining all 9 parameters, including a highly detailed format explanation for jo with examples and the KO/ORI values for lang. However, several parameters (lm, ld, ln, oc) remain cryptically described, preventing a higher score.

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 explicitly states it retrieves full law content by announcement date and 'complete text of a law.' This is a specific verb+resource and, given sibling names like law_search and eflaw_search, clearly positions law_service as the retrieval service rather than a search tool.

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?

It provides explicit usage guidance for specific article queries ('ALWAYS use the jo parameter') and warns about large responses when retrieving full laws. It does not compare against alternative sibling tools (e.g., when to use law_search instead), so it falls short of a 5, but the in-tool guidance is clear and actionable.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by noting that it runs multiple sub-queries (via 'display: Results per sub-query') and covers specific categories of legal sources, adding value beyond 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.

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

The description is well-structured with a summary, detailed explanation, parameter list, returns, and examples. It is somewhat longer than necessary but every section adds value, and the key purpose is front-loaded in the first sentence.

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?

For a tool with 4 parameters and no output schema, the description covers purpose, parameters, return type, and usage examples. It does not explain the 'oc' parameter or the exact structure of the returned analysis, leaving some gaps, but overall it is reasonably complete given the annotations.

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?

The schema has 0% description coverage, but the description's Args section explains each parameter: situation (plain language), display (results per sub-query), type (response format). The 'oc' parameter is only described as 'Optional OC override', which is vague and not fully clarified, preventing a 5.

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 function: 'Find all applicable laws, precedents, and interpretations for a situation' and explicitly mentions searching across multiple legal databases (law articles, court precedents, legal interpretations, citation networks). This differentiates it from sibling tools like law_search or prec_search, which likely target single databases.

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 clear usage context: it accepts a plain language situation and performs a comprehensive multi-database search in one call. However, it does not explicitly state when not to use this tool or name alternative tools, though the sibling list provides implicit context.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds some behavioral context (e.g., display recommendation, return type options, example), but it does not disclose details like pagination limits or error behavior beyond a generic mention.

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 a clear summary, args list, return statement, and example. It is concise and front-loaded with the core purpose. The Korean title is slightly redundant but harmless.

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?

For a read-only search tool with good annotations and no output schema, the description provides enough context: parameters, defaults, a usage tip, and an example. It is complete for practical invocation, though it does not detail the structure of results or all edge cases.

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, the description compensates well by explaining each parameter: org is required with an example, display has max/default and a recommendation, page is 1-based, type lists formats, and oc is an optional override. Specifics for 'sort' and 'oc' are minimal, but the overall parameter semantics are clearly enriched.

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 verb 'Search' and the resource 'law-ordinance links by ministry', and further explains it searches local ordinances linked to laws managed by a specific ministry. This distinguishes it from sibling tools like law_search or ordin_search.

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 implies usage by stating the tool's purpose, but it does not explicitly mention when to use it over alternatives or when not to use it. There are no exclusions or comparisons with sibling tools, so the guidance is only implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavior details beyond annotations: parameter formatting (zero-padded jo and jobr), recommended display size, response format options, and the return type ('Search results with linked ordinance articles or error'). This enriches understanding without contradicting annotations.

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 a concise summary, a labeled Args section, Returns, and Examples. Every sentence contributes useful information, and the format is front-loaded with the core purpose. It is detailed without being bloated.

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?

For a 9-parameter tool with no output schema, the description thoroughly covers all parameter semantics, return behavior, and usage examples. It explains the search scope, formatting rules, and even includes a note about display size for exact matches. The only missing detail is the internal structure of results, which is not required given the output schema absence is mitigated by the description's clarity.

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, the description fully compensates by explaining every parameter, including defaults, formatting constraints, and examples. For instance, it specifies 'jo: Article number (4 digits, zero-padded)' with examples and recommends display=50-100. This is exemplary parameter documentation.

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 'searches local ordinance articles that are linked to specific national law articles' using a specific verb and resource. This differentiates it from generic ordinance or law search tools by emphasizing the linkage aspect, as seen in sibling names like 'ordin_search' or 'law_search'.

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 clear context for when to use the tool (e.g., finding ordinances implementing specific law provisions) and includes concrete examples like searching by knd and jo. However, it does not explicitly name alternative tools or state when not to use it, which would push it to a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds the scope (linked laws list) and return format but lacks deeper behavioral details like pagination behavior, authorization needs, or rate limits. This is comparable to the mid-tier example where the description adds modest context beyond annotations.

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 sections for purpose, arguments, returns, and an example. It is somewhat lengthy, but each section earns its place given the need to document parameters manually. It is front-loaded with the purpose.

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?

With six parameters and no output schema, the description does a solid job covering purpose, parameter semantics, return values, and an example. It lacks a bit of detail on sort meanings and alternative use cases, but overall it is quite complete for a search tool.

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?

Despite 0% schema description coverage, the description explains every parameter in the Args section, including defaults, limits, and a recommendation for display. It adds meaning beyond the bare schema, though sort codes are merely listed without explanation, preventing a higher score.

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 searches Korean laws linked to local ordinances, using a specific verb and resource. It distinguishes itself from sibling search tools by emphasizing the linkage focus, making its unique purpose clear.

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 clear context for use: 'Useful for understanding how national laws relate to local regulations.' However, it does not explicitly mention when not to use the tool or name alternative tools, 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.

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

The description adds valuable behavioral details beyond the readOnly/idempotent annotations: it warns about the lack of HTML support, explains the id/mst dependency, and clarifies the response type default. This helps the agent anticipate API constraints.

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 a clear one-line summary, then args, returns, and an example. Every sentence carries informative weight and there is no redundant text.

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?

Even without an output schema, the description covers the return type, mutual exclusivity of id/mst, and format limitations. This is sufficient for an agent to invoke the tool correctly in 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 zero schema descriptions, the description fully compensates by explaining every parameter, including optionality, defaults, and the required id/mst interplay. The example demonstrates concrete usage.

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 retrieves delegated laws/rules/ordinances and shows the delegation hierarchy, distinguishing it from sibling search/service tools. The verb 'retrieve' plus the specific resource makes the purpose unambiguous.

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 gives clear context for when to use the tool: to inspect delegation relationships from a parent law. However, it does not explicitly name alternatives or state when not to use it, 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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the behavioral trait of identifying associations based on shared subject matter or cross-references, which is useful but does not go deeper (e.g., pagination behavior, OC override implications). This is acceptable given the annotation coverage.

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 efficiently structured with a clear purpose statement, a context sentence, and a parameter list. The Args block is somewhat repetitive of the schema but adds meaningful details like max display and OC override, so it earns its place. The Returns line is minimal but acceptable.

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?

The description is adequate for a simple read-only search but lacks details about result structure or error behavior, especially since there is no output schema. It also fails to distinguish this tool from the many similar sibling search tools, leaving some context gaps for an agent deciding between them.

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, the description fully compensates by explaining every parameter: query default '*', display max 100 and default 20, page 1-based, OC override defaults to env var, type formats, and ctx injected automatically. This adds significant meaning beyond the schema, making it highly useful for correct invocation.

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 it searches for laws related to a given query term and identifies associations based on shared subject matter or cross-references. However, it does not explicitly differentiate itself from the many sibling related-law search tools, so it misses the distinction needed for a 5.

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 no guidance on when to use this tool versus the numerous sibling tools like aiRltLs_search, lstrm_rlt_search, or dlytrm_rlt_search. It only notes it is part of the knowledge base, but lacks explicit when-to-use or alternative recommendations, leaving the agent to infer usage.

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