LexLink

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

The description adds valuable behavioral context beyond annotations: it explains response format limitations ('JSON not supported by API'), provides practical display size recommendations, clarifies date format requirements (YYYYMMDD), and explains what the search modes mean (rule name vs full text). While annotations cover read-only/idempotent safety, the description adds API-specific constraints and usage guidance.

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?

Well-structured with purpose statement, parameter explanations, return statement, and examples. The information is front-loaded with the core purpose first. Some parameter explanations could be slightly more concise, but overall the description efficiently conveys necessary information without wasted 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?

For a complex 13-parameter search tool with no output schema, the description provides comprehensive parameter explanations, practical usage guidance, and examples. It covers format limitations, search modes, date formats, and recommendations. The main gap is lack of output structure details, but given the annotations indicate a safe read operation and the parameter coverage is excellent, this is reasonably complete.

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 providing detailed explanations for all 13 parameters. Each parameter gets clear semantic meaning: query is 'Search keyword', display has 'max 100' constraint with recommendation, type explains format options with API limitation, nw distinguishes current vs historical, search explains rule name vs full text, etc. The description does the heavy lifting the schema doesn't.

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 administrative rules (행정규칙 목록 조회)' with specific examples of rule types (훈령, 예규, 고시, etc.) and explains what administrative rules are. It distinguishes from siblings by focusing specifically on administrative rules rather than other legal documents like laws or precedents.

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 this tool (searching Korean administrative rules) and includes practical recommendations like 'Recommend 50-100 for law searches to ensure exact matches are found.' However, it doesn't explicitly state when NOT to use this tool or mention specific alternatives among the many 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 indicate read-only, idempotent, and non-destructive operations. The description adds valuable context beyond annotations: it specifies the API doesn't support JSON format, mentions automatic context injection, and describes what's included in the return (content, addenda, annexes). 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?

Well-structured with purpose statement, parameter explanations, return description, and examples. Every sentence adds value - no redundancy. The information is front-loaded with the core purpose first.

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 retrieval tool with good annotations and comprehensive parameter coverage in the description, this is quite complete. The main gap is no output schema, but the description explains what's returned. Could benefit from more explicit sibling tool differentiation.

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 all 5 parameters: id (rule sequence number), lid (rule ID alternative), lm (rule name exact match), oc (OC override), type (response format with defaults and constraints). It clarifies relationships between id/lid/lm and provides format details not in 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: 'Retrieve administrative rule full text' and specifies it's for Korean administrative rules. It distinguishes from sibling tools like admrul_search by focusing on retrieving complete text 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 provides clear context about when to use this tool (retrieving complete text with content and annexes) and includes parameter guidance (id required if lid/lm not provided). However, it doesn't explicitly contrast when to use this vs. admrul_search or other search 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?

The annotations indicate read-only, idempotent, and non-destructive behavior, which the description doesn't contradict. The description adds valuable context beyond annotations: it specifies that the tool is 'AI-powered,' returns a 'list of semantically related law articles,' and notes that JSON is not supported (only XML). This provides practical usage details that annotations alone don't cover, though it could mention rate limits or auth needs.

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 (purpose, usage, args, returns, example) and uses bullet points for readability. It's appropriately sized, with every sentence adding value, such as the example that illustrates input and output. Minor improvements could include streamlining the bilingual text, but overall it's efficient and front-loaded with key 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?

Given the tool's complexity (4 parameters, 0% schema coverage, no output schema) and rich annotations, the description is largely complete. It covers purpose, usage, parameters, and output format, though it lacks details on error handling or pagination. The example helps clarify usage, but without an output schema, more on return structure could be beneficial. Still, it provides sufficient context for effective 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?

With 0% schema description coverage, the description fully compensates by explaining all parameters in detail. It defines 'query' as a 'law name or keyword,' 'search' with scope options (0 for law articles, 1 for administrative rules), 'oc' as an optional override, and 'type' as response format (XML only). This adds essential meaning beyond the bare schema, ensuring parameters are well-understood.

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 the tool's purpose as 'discovering related laws from vague topics' and 'finds laws semantically related to a given law name or keyword,' using specific verbs ('discovering,' 'finds') and resources ('laws,' 'law articles'). It clearly distinguishes this from sibling tools by labeling it as the '⭐ PREFERRED TOOL' for this specific use case, differentiating it from other search tools in the list.

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

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

The description provides explicit guidance on when to use this tool ('when user wants to explore laws around a general subject') and includes a 'Best for' section with examples (e.g., '민법' → 상법, 의료법, 소송촉진법). It also implicitly suggests alternatives by noting it's the 'PREFERRED TOOL' for this task, implying other tools might exist for different scenarios, though it doesn't name specific 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=true, idempotentHint=true, and destructiveHint=false, indicating a safe, repeatable read operation. The description adds valuable context beyond annotations: it specifies that it 'Returns FULL ARTICLE TEXT (조문내용)' and notes 'Response format - XML only (JSON not supported),' which are important behavioral traits not covered by 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 key information: it starts with usage priority, states the purpose, details parameters with examples, and ends with a return value summary and example. Every sentence adds value, with no redundant or wasted content.

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 (6 parameters, 0% schema coverage, no output schema), the description is highly complete. It covers purpose, usage guidelines, parameter semantics, return values ('Returns FULL ARTICLE TEXT'), and format constraints ('XML only'). The example further clarifies usage. With annotations providing safety context, this description leaves minimal gaps.

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 full burden of parameter documentation. It provides clear semantics for all 6 parameters: query is described as 'Search query (natural language supported),' search has enumerated scope options with defaults, display as 'Results per page,' page as 'Page number,' oc as 'Optional OC override,' and type as 'Response format - XML only.' This compensates well for the lack of 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 the tool's purpose: '지능형 법령검색 시스템 검색 API (AI-powered semantic law search)' and 'Uses intelligent/semantic search to find relevant law articles.' It distinguishes itself from siblings by explicitly mentioning 'more comprehensive than eflaw_search' and being the 'PREFERRED TOOL for vague or natural language queries.'

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

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

The description provides explicit usage guidelines: 'Use this FIRST when user's intent is unclear or conversational' and 'Best for: Natural language queries like "뺑소니 처벌", "음주운전 벌금".' It also distinguishes from alternatives by noting it's 'more comprehensive than eflaw_search,' helping the agent choose between 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 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=true, idempotentHint=true, and destructiveHint=false, covering safety aspects. The description adds valuable behavioral context: it specifies that JSON is not supported by the API (only HTML or XML), mentions pagination behavior with page numbers, and indicates maximum result limits (max 100 per page). This goes 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 well-structured with clear sections: purpose explanation, parameter documentation, returns statement, and examples. While comprehensive, it's appropriately sized for a tool with 13 parameters. Some redundancy exists (e.g., repeating 'type="XML"' in examples), but overall it's efficiently organized.

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 search tool with 13 parameters, 0% schema coverage, and no output schema, the description does an excellent job explaining parameters and providing examples. It covers the search domain, parameter semantics, and response format limitations. The main gap is lack of output structure details, but given the annotations cover safety and the description explains format constraints, it's mostly complete.

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 carries full burden for parameter documentation. It provides detailed explanations for all 13 parameters, including defaults, constraints (max 100 for display), format specifications (YYYYMMDD for dates), and meaning of enum-like values (search=1 vs 2, sort options). The 'Args' section comprehensively documents what each parameter does.

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 administrative appeal decisions, specifying both the verb ('searches') and resource ('administrative appeal decisions'). It distinguishes from siblings by focusing specifically on administrative appeal decisions rather than other legal documents, and provides context about what administrative appeals are.

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 through the explanation of what administrative appeals are, but doesn't explicitly state when to use this tool versus alternatives like 'decc_service' or other search tools in the sibling list. There's no guidance on prerequisites, limitations, or comparison with similar 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 valuable context beyond annotations: it specifies that JSON format is not supported by the API (only HTML/XML), mentions automatic injection of context parameter, and describes what content is included in the return (case details, disposition, summary, reasoning).

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 purpose statement, content details, parameter explanations, return description, and examples. Every sentence adds value with zero waste. The bilingual approach (Korean/English) is efficient for clarity 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 read-only tool with good annotations and comprehensive parameter documentation, the description is nearly complete. It explains what the tool returns (full text with details) though without an output schema. The main gap is lack of explicit sibling tool differentiation, but otherwise covers purpose, usage, parameters, and constraints adequately.

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 all 4 parameters: 'id' as required decision sequence number, 'lm' as optional decision name, 'oc' as optional override with default behavior, and 'type' as format selection with default and constraints. The examples demonstrate practical usage with both required and optional 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 the tool's purpose with specific verb ('retrieve') and resource ('administrative appeal decisions'), including Korean terminology. It distinguishes from sibling tools like 'decc_search' by focusing on full text retrieval 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 provides clear context for when to use this tool (retrieving complete decision text) and includes examples. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like 'decc_search' for finding decisions versus retrieving them.

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, establishing this as a safe, repeatable read operation. The description adds valuable context about pagination (max 100 results per page), response format options (HTML/XML), and search types (decision name vs full text), which goes 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 well-structured with clear sections (description, args, returns, examples) and front-loaded purpose. While comprehensive, some parameter explanations could be more concise. Every sentence adds value, but the parameter section is lengthy due to the high parameter count.

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 12 parameters, 0% schema coverage, and no output schema, the description provides excellent parameter documentation and behavioral context. The main gap is lack of output format details beyond 'search results with Constitutional Court decision list or error' - more specifics about the response structure would be helpful given no output schema exists.

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

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

With 0% schema description coverage for 12 parameters, the description carries the full burden. It provides detailed explanations for all parameters including defaults, constraints (max 100 for display), format specifications (YYYYMMDD for dates), and enumerated values (sort options, search types). 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 searches Constitutional Court decisions with the specific resource identified. It distinguishes from some siblings by specifying 'Constitutional Court decisions' rather than other legal documents, though it doesn't explicitly differentiate from all search tools in the sibling list.

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

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

The description implies usage through examples showing different search scenarios (keyword search, date search), but doesn't provide explicit guidance on when to use this tool versus alternatives like 'detc_service' or other search tools in the sibling list. No when-not-to-use guidance is provided.

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, establishing this as a safe, repeatable read operation. The description adds valuable context about what gets returned ('Full Constitutional Court decision text or error') and includes an example showing minimal required parameters, which helps the agent understand the tool's behavior 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 clear sections (purpose, args, returns, examples) and efficiently conveys necessary information. While slightly longer than minimal, every sentence adds value. The bilingual terminology could be slightly condensed but doesn't significantly impact conciseness.

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 tool with good annotations and no output schema, the description provides sufficient context: clear purpose, parameter explanations, return information, and an example. The main gap is lack of explicit guidance on when to use versus sibling tools, but otherwise it's complete enough for an agent to use effectively.

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 carries the full burden of explaining parameters. It provides clear explanations for all 4 parameters: 'id' as the decision sequence number, 'lm' as optional decision name, 'oc' as optional override, and 'type' specifying response format with default value. 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 with a specific verb ('Retrieve') and resource ('Constitutional Court decision full text'), including both English and Korean terminology. It distinguishes itself from sibling tools like 'detc_search' (which likely searches for decisions) by focusing on retrieving full text of a specific decision identified by ID.

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 through the example (retrieving a specific decision by ID) and parameter descriptions, but doesn't explicitly state when to use this tool versus alternatives like 'detc_search' or other *_service tools. No explicit when-not-to-use guidance or prerequisite information is provided.

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?

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate readOnly, idempotent, and non-destructive operations, the description reveals important API constraints: 'JSON not supported by API' and that the tool returns 'Specific law section content' rather than full documents. It also explains the tool's precision focus ('returns only the requested article/paragraph'). However, it doesn't mention rate limits, authentication needs, or error conditions.

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 exceptionally well-structured and concise. It starts with the core purpose, immediately provides usage guidance, then systematically documents parameters with clear formatting, and ends with practical examples. Every sentence adds value - there's no redundancy or fluff. The use of bold, code formatting, and clear sections makes it 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?

For a complex tool with 9 parameters, 0% schema coverage, no output schema, and no behavioral annotations beyond basic hints, the description provides comprehensive coverage. It explains the tool's purpose, when to use it, all parameter semantics, format requirements, dependencies between parameters, API limitations (no JSON support), and provides working examples. The only minor gap is lack of explicit return format details, but 'Specific law section content' is reasonably descriptive.

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 carries the full burden of parameter documentation and excels at it. It provides detailed explanations for all 9 parameters: clarifies that 'id or mst is required', explains ef_yd is 'required when using mst', provides format specifications for jo/hang/ho/mok with examples, explains oc defaults, and clarifies type options and defaults. The examples demonstrate practical parameter usage with real values.

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: 'Query specific article/paragraph by effective date' and explicitly distinguishes it from alternatives by stating 'BEST TOOL for querying specific articles like "제174조", "제3조" etc. This returns only the requested article/paragraph, avoiding large full-law responses.' It provides specific verb (query) and resource (article/paragraph) with clear differentiation from sibling tools that appear to be search or 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 excellent usage guidance with explicit when-to-use statements: 'BEST TOOL for querying specific articles' and 'avoiding large full-law responses.' It also provides concrete examples showing how to use the tool for specific scenarios (자본시장법 제174조, 건축법 제3조 제1항). The guidance helps the agent understand this is for precise retrieval rather than broad searches.

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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds valuable context: it notes JSON is not supported by the API (only HTML/XML), provides a recommendation for display values (50-100 for law searches), and explains the effective date range format. 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?

Well-structured with purpose statement, usage guidance, parameter details, returns, and examples. Every sentence adds value, but it's moderately long due to parameter explanations. The front-loaded purpose and usage are clear, though some redundancy exists (e.g., repeating 'JSON not supported' in type description and examples).

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 9 parameters, 0% schema coverage, no output schema, and annotations covering safety, the description is highly complete. It explains all parameters, provides usage context, examples, and API limitations. Minor gap: no details on error handling or result structure beyond 'Search results with law list or error'.

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 burden. It provides detailed explanations for all 9 parameters: query (search keyword), display (results per page with max and recommendation), page, oc, type (format options and JSON limitation), sort (order options), ef_yd (date range format), org, and knd. This compensates fully 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's purpose: 'Search current laws by effective date' with Korean clarification. It specifies the resource (Korean laws) and scope (organized by effective date, currently in effect). The title is null, so the description fully defines the purpose without redundancy.

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 guidance is provided: 'Use this when you need to find laws that are currently in effect.' This directly tells the agent when to select this tool versus alternatives. With many sibling tools (e.g., law_search, elaw_search, drlaw_search), this clear context helps differentiate based on effective date filtering.

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, covering safety aspects. The description adds valuable behavioral context: it warns about potential large responses (exceeding 1MB), performance implications ('much faster and cleaner' with jo parameter), and API limitations (JSON not supported). This goes 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 well-structured with clear sections (purpose, important note, args, returns, examples), uses bold for critical information, and every sentence adds value. It's appropriately sized for a complex tool with many parameters and important usage considerations.

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 (7 parameters, 0% schema coverage, no output schema), the description provides comprehensive context: it explains all parameters, includes critical warnings about response size, provides format examples, clarifies API limitations, and gives practical usage examples. This is complete enough for effective tool 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 0% schema description coverage, the description carries the full burden of explaining parameters. It provides detailed explanations for all 7 parameters: clarifies requirements (id or mst required, ef_yd required with mst), format specifics (jo parameter format with examples), defaults (chr_cls_cd, type), and purpose of each parameter. This fully compensates 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 specific action ('retrieve full law content by effective date') and resource ('law content'), with the Korean title providing additional context. It distinguishes this tool from siblings like 'eflaw_search' (which likely searches) and 'eflaw_josub' (which may handle article subdivisions).

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

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

The description provides explicit guidance on when to use this tool vs. alternatives: it strongly recommends using the 'jo' parameter for specific article queries to avoid large responses, and warns against full retrievals for laws with many articles. This directly addresses when to use specific features of this tool.

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, covering safety aspects. The description adds valuable behavioral context beyond annotations: it notes JSON is not supported by the API (only HTML/XML), provides a display count recommendation for better results, and mentions the context parameter is injected automatically. This goes 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?

Well-structured with purpose statement, usage context, detailed args section, returns statement, and examples. The args section is comprehensive but could be more concise. Every sentence adds value, though the display recommendation could be integrated more smoothly. Good front-loading of core functionality.

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 9 parameters with 0% schema coverage, no output schema, and annotations covering only safety aspects, the description provides excellent completeness. It explains all parameters meaningfully, includes API limitations (JSON not supported), provides usage recommendations, shows examples, and clarifies the automatic context injection. This fully addresses 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?

With 0% schema description coverage (titles only, no descriptions), the description carries the full burden. It provides excellent parameter semantics: explains query accepts Korean or English, display has max 100 with recommendation, page is 1-based, type format options with JSON limitation, sort order codes, effective date range format, and that org/knd are filters. This fully compensates 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 searches Korean laws translated to English, specifying the resource (Korean laws) and action (search). It distinguishes from siblings by focusing on English translations, unlike tools like 'law_search' or 'eflaw_search' which likely search different language versions. However, it doesn't explicitly contrast with all siblings like 'elaw_service'.

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 this tool ('useful for international users or bilingual legal research'), indicating its target audience. It includes a specific recommendation for display count (50-100) for law searches. However, it doesn't explicitly state when NOT to use it or mention alternatives among the many 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 valuable behavioral context beyond annotations: it specifies that JSON format is 'not supported by API' (important implementation detail), mentions automatic injection of 'ctx' parameter, and indicates the tool returns either 'Full English law text with articles or error' (outcome transparency).

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?

Well-structured with purpose statement, usage context, parameter explanations, return specification, and examples. Every sentence earns its place - no wasted words. The information is front-loaded with core purpose first, then details.

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 7-parameter retrieval tool with good annotations but no output schema, this description is complete: it covers purpose, usage context, all parameter semantics, behavioral constraints (format limitations), and provides examples. The combination with annotations provides full context for agent 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 0% schema description coverage, the description fully compensates by explaining all 7 parameters' semantics: it clarifies required/alternative relationships ('id required if mst not provided'), provides format details ('YYYYMMDD'), explains defaults ('defaults to env var'), specifies format options with constraints ('JSON not supported by API'), and notes automatic injection. 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 clearly states the tool's purpose: 'retrieve the complete text of Korean laws translated to English' with specific verb ('retrieve') and resource ('English law full text'). It distinguishes from sibling tools like 'elaw_search' (likely searches metadata) by specifying it retrieves full text content.

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: 'Useful for international legal research and cross-border understanding.' It doesn't explicitly state when NOT to use it or name specific alternatives among siblings, but the purpose differentiation implies usage scenarios.

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, covering safety aspects. The description adds valuable context beyond annotations: it specifies that JSON is not supported by the API (only HTML or XML), mentions rate limits implicitly via 'max 100' for display parameter, and provides practical recommendations like 'Recommend 50-100 for searches to ensure exact matches are found.' This adds meaningful behavioral 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 clear sections (purpose, args, returns, examples). While comprehensive, every sentence earns its place by providing essential information. The front-loaded purpose statement is clear, though the parameter documentation is lengthy but necessary given the schema coverage gap.

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 complexity (14 parameters, 0% schema coverage, no output schema), the description does an excellent job of providing necessary context. It explains parameters thoroughly, mentions API limitations (JSON not supported), provides practical usage examples, and clarifies return values. The main gap is lack of output format details, but overall it's quite complete for this 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?

With 0% schema description coverage, the description carries the full burden of parameter documentation. It provides detailed explanations for all 14 parameters, including defaults, constraints (max 100), format specifications (YYYYMMDD~YYYYMMDD), enum values (1=법령해석례명, 2=본문검색), and practical recommendations. This adds substantial value 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: 'Search legal interpretations (법령해석례 목록 조회)' and elaborates with 'This tool searches Korean legal interpretation precedents issued by government agencies in response to inquiries about how to interpret specific laws.' It specifies the exact resource (Korean legal interpretation precedents) and distinguishes from siblings by focusing on this specific type of legal material.

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 (searching Korean legal interpretation precedents) but doesn't explicitly state when to use this tool versus alternatives like 'expc_service' or other search tools in the sibling list. It provides examples but no explicit guidance on tool selection criteria.

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, covering safety and idempotency. The description adds useful behavioral context beyond annotations: it specifies the content returned (question summary, answer, reasoning), format constraints (JSON not supported), and that 'ctx' is injected automatically, which helps the agent understand the tool's behavior.

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, followed by clear sections for Args, Returns, and Examples. Every sentence earns its place by providing essential information without redundancy, making it efficient and 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?

Given the tool's moderate complexity (4 parameters, no output schema), the description is largely complete: it explains the purpose, parameters, return content, and provides examples. However, it lacks explicit error handling details or performance considerations, leaving minor gaps in full contextual understanding.

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 providing detailed semantics for all parameters: 'id' as required sequence number, 'lm' as optional name, 'oc' as optional override with default, 'type' as format with default and constraints, and 'ctx' as automatically injected. This 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 with specific verbs ('retrieve', 'retrieves') and resources ('legal interpretation full text', 'complete text of a legal interpretation precedent'). It distinguishes itself from sibling tools like 'expc_search' by focusing on retrieving full text 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 (retrieving by ID or with name) but lacks explicit guidance on when to use this tool versus alternatives like 'expc_search' or other service tools. It provides basic context but no explicit when/when-not statements or named 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=true, idempotentHint=true, and destructiveHint=false, covering safety aspects. The description adds valuable context: it specifies the tool returns 'only the requested article/paragraph' (scoping behavior), notes 'JSON not supported by API' (limitation), and provides format defaults ('default "XML"'). This goes beyond 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 clear sections (purpose, args, returns, examples) and uses bold for emphasis. It's slightly verbose but every sentence adds value: the purpose statement, parameter explanations, and examples are all necessary given the complex parameter formatting. Minor redundancy in examples keeps it practical.

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 8 parameters, 0% schema coverage, no output schema, and complex formatting requirements, the description is highly complete. It covers purpose, usage context, all parameter semantics, behavioral notes (e.g., format limitations), and provides concrete examples. Given the annotations handle safety, this description fills all remaining gaps effectively.

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 all 8 parameters. It clarifies required conditions ('either id or mst is required'), provides detailed formatting rules for jo, hang, ho, and mok with examples, explains defaults for oc and type, and notes constraints like 'JSON not supported.' This 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: 'Query specific article/paragraph by announcement date' and explicitly positions it as 'BEST TOOL for querying specific articles like "제174조", "제3조" etc.' It distinguishes from siblings by noting it 'returns only the requested article/paragraph, avoiding large full-law responses,' which differentiates it from broader search tools in the sibling list.

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

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

The description provides explicit usage guidance: it states this is the 'BEST TOOL for querying specific articles' and contrasts it with 'avoiding large full-law responses,' implying alternatives like law_search or law_service for broader queries. It also includes practical examples showing when to use specific parameters.

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 indicate read-only, idempotent, and non-destructive behavior, which the description doesn't contradict. The description adds valuable context: it specifies the API doesn't support JSON (only HTML/XML), recommends display settings for optimal results, and clarifies the date format (YYYYMMDD). This goes beyond what annotations provide about safety and idempotency.

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 purpose statement, parameter explanations in a bullet-like format, and a returns section. It's appropriately sized for a 9-parameter tool. Minor improvements could include bolding key constraints like 'JSON not supported' for faster scanning.

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 9 parameters, 0% schema coverage, no output schema, and read-only/idempotent annotations, the description provides strong coverage. It explains all parameters, notes API format limitations, gives usage recommendations, and clarifies the date format. The main gap is lack of output format details, but given the annotations indicate safe operation, 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?

With 0% schema description coverage, the description carries full burden for parameter documentation. It successfully explains all 9 parameters: query (search keyword), display (results per page with recommendation), page (page number), oc (OC override), type (response format with constraints), sort (sort order), date (announcement date with format), org (ministry filter), and knd (law type filter). The only gap is lack of enum values for sort, org, and knd.

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 by announcement date, specifying the resource (Korean laws) and scope (by announcement date). It distinguishes itself from siblings by focusing on current laws rather than administrative rules or other legal documents, though it doesn't explicitly compare to each sibling 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?

The description implies usage for searching current Korean laws by announcement date, with a recommendation to use higher display values (50-100) for law searches. However, it doesn't explicitly state when to use this tool versus alternatives like 'law_service' or 'eflaw_search', nor does it provide exclusion criteria or prerequisites for use.

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, covering basic safety. The description adds valuable behavioral context: performance warnings ('full response can exceed 1MB'), parameter-specific behavior ('Using `jo` returns only the requested article'), and API constraints ('JSON not supported by API'). It doesn't contradict 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 clear sections (purpose, important notes, args, returns, examples) and uses bold text for critical information. While comprehensive, it's appropriately sized for a complex tool with many parameters. Some redundancy exists (e.g., repeating 'Retrieve' in purpose), but overall it's efficient.

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, 0% schema coverage, no output schema), the description is nearly complete. It explains parameters thoroughly, provides usage examples, and covers behavioral aspects. The main gap is lack of detail on return values beyond 'Full law content or specific article content', but this is mitigated by the examples showing actual usage.

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 all 9 parameters. It clarifies requirements ('either id or mst is required'), provides detailed formatting rules for 'jo' with examples, explains defaults ('defaults to env var' for 'oc'), and specifies allowed values for 'lang' and 'type'. This 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: 'Retrieve full law content by announcement date' and 'Retrieves the complete text of a law organized by announcement (publication) date.' It specifies both the verb ('retrieve') and resource ('law content'), and distinguishes itself from sibling tools like 'law_search' by focusing on full content retrieval 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 provides explicit guidance on when to use specific parameters: 'IMPORTANT: For specific article queries (e.g., "제174조"), ALWAYS use the `jo` parameter.' It also warns against full retrieval for large laws and recommends article-specific queries for speed and cleaner responses, offering clear alternatives within the same tool.

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, covering safety aspects. The description adds valuable behavioral context beyond annotations: it specifies response format limitations ('JSON not supported by API'), provides practical recommendations ('Recommend 50-100 for law searches to ensure exact matches are found'), and notes automatic parameter injection ('ctx: MCP context (injected automatically)').

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, followed by organized sections for Args, Returns, and Examples. Every sentence earns its place by providing essential information without redundancy. The bullet-point style in the Args section enhances readability while maintaining efficiency.

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 (6 parameters, 0% schema coverage, no output schema) and the absence of output schema, the description provides complete context. It covers purpose, all parameters with semantics, behavioral constraints, format limitations, practical recommendations, and includes a concrete example. The annotations provide safety context, and the description fills all remaining gaps effectively.

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 carries the full burden of parameter documentation and excels at it. It provides detailed semantics for all parameters: explains 'org' is a ministry/department code with example, specifies 'display' range and recommendation, clarifies 'page' is 1-based, explains 'oc' defaults to env var, details 'type' options and limitations, mentions 'sort' exists, and notes 'ctx' is automatic. This comprehensively compensates 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's purpose with specific verb ('searches') and resource ('local ordinances linked to laws managed by a specific government ministry or department'). It distinguishes from siblings by focusing on ministry-specific ordinance links, unlike other tools like 'law_search' or 'eflaw_search' that appear to search different legal domains.

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 this tool ('searches local ordinances linked to laws managed by a specific government ministry or department'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. The example shows a typical usage scenario, which helps guide implementation.

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 valuable context beyond annotations: it reveals that JSON format is not supported by the API (only HTML/XML), provides specific display recommendations (50-100 for law searches), and explains the tool's specialized purpose. No contradictions with annotations exist.

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 (purpose, args, returns, examples). Every sentence adds value: the opening explains the tool's unique purpose, parameter documentation is comprehensive, and examples show practical usage. It could be slightly more concise in the parameter explanations but remains efficient overall.

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 9 parameters, 0% schema coverage, no output schema, and annotations covering safety aspects, the description provides excellent context. It explains the tool's specialized linkage purpose, documents all parameters thoroughly, provides format limitations, and includes practical examples. The main gap is lack of output format details, but this is partially mitigated by the type parameter 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?

With 0% schema description coverage, the description carries the full burden of parameter documentation. It provides detailed explanations for all 9 parameters: query purpose, display recommendations with rationale, page numbering, type format limitations with JSON clarification, knd filtering purpose, jo formatting requirements with examples, jobr formatting with examples, sort functionality, and ctx automation. This fully compensates 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's purpose with specific verbs ('searches local ordinance articles that are linked to specific national law articles') and resources ('ordinance articles', 'law articles'). It distinguishes this tool from siblings by explaining it focuses on linkages between ordinances and laws, unlike generic search tools like 'law_search' or 'ord_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 this tool ('to see which local ordinances implement or relate to specific law provisions'). It includes practical examples showing usage patterns. However, it doesn't explicitly state when NOT to use it or name specific alternative tools from the sibling list for different 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it notes that JSON is not supported by the API (only HTML/XML), provides a recommendation for display count (50-100 for law searches), and mentions that 'ctx' is injected automatically. No contradiction with annotations exists.

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

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

The description is well-structured and front-loaded: purpose statement first, usage context second, followed by detailed parameter explanations and an example. Every sentence earns its place by providing essential information without redundancy. The example is concise and illustrative.

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 (6 parameters, 0% schema coverage, no output schema), the description is largely complete. It covers purpose, usage, all parameters with semantics, and includes an example. However, it doesn't detail the return structure beyond 'Search results with linked laws list or error', which could be more specific (e.g., format of results). With no output schema, this leaves some ambiguity.

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 all parameters in the 'Args' section. It adds meaning beyond the schema: default values, constraints (max 100 for display), recommendations (50-100 for law searches), format options (HTML/XML, JSON not supported), sort order details, and automatic injection of 'ctx'. The only minor gap is that 'oc' is described only as 'Optional OC override (defaults to env var)', which is somewhat vague.

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: 'searches Korean laws that have linkages to local ordinances.' It specifies both the verb ('searches') and the resource ('laws linked to local ordinances'), and distinguishes it from siblings by focusing on law-ordinance linkages rather than general law searches (e.g., 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: 'Useful for understanding how national laws relate to local regulations.' This indicates when to use it (for law-ordinance linkage analysis). However, it doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools, which would be needed for a score of 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 context beyond annotations: it explicitly warns that 'This API does NOT support HTML format (only XML/JSON)' and clarifies that JSON is actually not supported by the API despite the mention. While annotations cover read-only/idempotent/non-destructive aspects, the description adds important API format constraints that aren't captured in structured fields.

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 purpose statement, important warning, parameter explanations, return description, and example. While efficient, the parameter explanations could be slightly more concise, and the format warning appears in two places (main description and type parameter).

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, 0% schema coverage, no output schema, and read-only annotations, the description provides comprehensive parameter semantics and behavioral constraints. The main gap is the lack of output format details beyond 'Delegation hierarchy with delegated laws/rules/ordinances or error' - more specifics about the structure would be helpful given no output schema exists.

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 all parameters: 'id' and 'mst' as mutually required identifiers, 'oc' as an optional override with default behavior, and 'type' with format constraints and default value. It clarifies the relationship between id and mst ('required if mst not provided'/'required if id not provided') and notes that 'ctx' is injected automatically.

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: 'Retrieve delegated laws/rules/ordinances' with specific details about what information is returned ('delegation hierarchy and which specific articles delegate authority'). It distinguishes this from siblings by focusing specifically on delegated laws rather than general law search or other legal functions.

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 about when to use this tool (for retrieving delegation hierarchies) and includes a specific example. However, it doesn't explicitly state when NOT to use it or name specific alternative tools from the sibling list for different use cases.

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 agent knows this is a safe, repeatable read operation. The description adds some behavioral context by mentioning pagination ('display: Number of results per page'), search types, and format options, but doesn't cover rate limits, authentication needs, or error handling beyond 'Returns: Search results with precedent list or error.'

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 (description, Args, Returns, Examples). Each sentence adds value: the opening defines purpose, Args section explains parameters thoroughly, Returns states outcome, and Examples provide practical usage. Some parameter explanations could be more concise, but overall it's efficiently organized with minimal waste.

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 (16 parameters, no output schema, no annotations beyond basic hints), the description does a reasonable job but has gaps. It explains parameters well and provides examples, but lacks information about response format details, error types, pagination behavior beyond basics, and how results are structured. The absence of an output schema means the description should ideally provide more about return values.

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 (titles only provide parameter names), the description carries the full burden of explaining parameters. It provides detailed explanations for all 16 parameters including defaults, constraints ('max 100'), formats ('YYYYMMDD'), and enumerations ('lasc|ldes|dasc|ddes|nasc|ndes', 'Y or N'). This significantly compensates for the lack of 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 the tool's purpose: 'Search court precedents (판례 목록 조회)' followed by 'Search Korean court precedents from Supreme Court and lower courts.' It specifies the verb ('search'), resource ('court precedents'), and jurisdiction ('Korean court precedents from Supreme Court and lower courts'), distinguishing it from siblings like admrul_search or law_search which search different legal resources.

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 alternatives. It does not mention sibling tools like prec_service (which likely provides detailed precedent information) or differentiate from other search tools on the server. The examples show basic usage but lack context about when this search is preferred over other legal search 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 indicate read-only, idempotent, and non-destructive behavior. The description adds useful context about the optional parameters and default response format ('XML'), which helps the agent understand how to invoke the tool effectively 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 efficiently structured with a clear purpose statement, organized parameter explanations, return statement, and a practical example. Every sentence serves a distinct purpose without redundancy, making it 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?

For a read-only tool with good annotations and no output schema, the description provides sufficient context: purpose, parameters, return expectation, and an example. It could improve by detailing error conditions or output structure, but it's largely 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?

With 0% schema description coverage, the description compensates well by explaining all four parameters: 'id' as the required precedent sequence number, 'lm' as optional precedent name, 'oc' as optional override, and 'type' as response format with default 'XML'. This 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 verb 'Retrieve' and the resource 'court precedent full text' with the Korean translation in parentheses. It distinguishes itself from sibling tools like 'prec_search' by specifying it retrieves the full text rather than searching for precedents.

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 when full text of a precedent is needed, but provides no explicit guidance on when to use this tool versus alternatives like 'prec_search' or other service tools. The example shows basic usage but lacks context about prerequisites or comparisons.

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