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

No annotations are provided, so the description carries the full burden. It does not disclose that the tool is read-only, non-destructive, or any other behavioral traits such as rate limits or required permissions. The description only describes functionality, not 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 a single sentence with an example, front-loading the key feature '복합 필터 검색'. Every word is informative, and no unnecessary content exists.

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 (9 parameters, many sibling tools), the description is somewhat minimal. It does not explain how filters combine (AND/OR), default behavior, or output format. The tool has no output schema, so more detail on return values would be helpful.

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

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

The input schema covers 100% of parameters with descriptions. The tool description summarizes the filter categories but does not add new meaning beyond the schema. The example query provides context but does not elaborate on parameter formats or constraints beyond what the schema already states.

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

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

The description clearly states it is a complex filter search combining category, institution type, ministry, date range, and title keyword. It gives a specific example query ('과기부 산하 K1100 분류 중 최근 1년 개정'), which distinguishes it from other search tools that may not support such multi-filter combinations.

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 this tool is for precise queries with multiple filters, but does not explicitly state when to use it versus sibling tools like 'search_alio_regulation_text' or 'advanced_search'. No exclusions or alternatives are mentioned, leaving the agent to infer usage.

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

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

No annotations provided. Description only mentions 'filter search' and 'complex conditions' but does not disclose behavior such as authentication requirements (apiKey is described in schema but not in description), rate limits, or result format. The burden falls entirely on the description, which is insufficient.

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 very short (one line), which is concise but risks being under-informative. It lacks structure and front-loads only a brief purpose. Could benefit from more detail without being verbose.

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 8 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, pagination, error handling, or how to use the apiKey. The tool is complex, so more detail is necessary.

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 100% with descriptions for each parameter. The tool description mentions filters (law type, department, date) which map to parameters, but adds little extra meaning. With full schema coverage, baseline is 3, and description does not significantly add beyond the schema.

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

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

Description states it's for advanced search with filters on law type, department, and enforcement date, matching the name and distinguishing it from simpler search tools among siblings. However, it does not explicitly differentiate from sibling tools, and the phrasing '복합 조건 시' is vague.

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 guidance on when to use this tool versus other search tools (e.g., search_law, search_ordinance). It does not provide explicit when-to-use or alternatives, leaving the agent to infer based on the name.

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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states what the tool does without mentioning side effects, idempotency, authentication needs, or output format, leaving significant gaps.

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 two sentences, front-loaded with the core functionality, and wastes no words. Every sentence contributes purpose and usage 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?

Given the tool's complexity (5 parameters, many siblings), the description is somewhat lacking. It covers core purpose and one alternative but omits output details, prerequisites, and broader usage context, making it minimally adequate.

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 high (80%), so baseline is 3. The description adds context for 'showTOC' and 'maxTocItems' by tying them to the TOC analysis, but does not clarify 'regId' (undocumented in schema) or add meaning beyond the schema for other 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 analyzes regulation metadata, structure, and table of contents for ALIO regulations. It distinguishes itself from 'analyze_document' for deep risk analysis, making the purpose specific and unambiguous.

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

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

The description explicitly directs deep risk analysis to 'analyze_document', providing a clear when-not-to-use scenario. However, it does not elaborate on when to prefer this tool over other siblings like 'get_alio_regulation' or 'analyze_regulation_delegation'.

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?

No annotations are provided, so the description must carry the full burden. It mentions outputs (classification, risk identification, hints) but does not disclose behavioral traits such as whether the tool is read-only, any side effects, rate limits, or behavior with large texts.

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?

A single sentence front-loads the purpose and lists key features. No redundant words; every phrase adds value.

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

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

The description mentions three output types (classification, risk clauses, law hints), which is helpful given no output schema. However, it lacks details on output structure, error handling, or any prerequisites. Still, it provides a reasonable overview.

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 100%, so baseline is 3. The description adds minimal context beyond the schema (e.g., 'text' is the full text, 'maxClauses' defaults to 15). No further elaboration on format or constraints.

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 performs clause-by-clause legal risk analysis on contract/terms/agreement text, which distinguishes it from sibling tools that analyze regulations or other documents. However, it does not explicitly differentiate from siblings like analyze_alio_regulation.

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 analyzing contracts or agreements, but does not explicitly state when to use this tool vs alternatives (e.g., for regulations use analyze_alio_regulation). No when-not-to-use or exclusion criteria are 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?

No annotations are provided, so the description carries full burden. It discloses that includeLawLookup=true slows down the tool (up to 5 slow calls), which is important behavioral information. However, it does not explicitly state if the tool is read-only or if it modifies data.

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

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

The description is a single, concise sentence covering the core function and key parameter behavior. It is front-loaded with the main purpose and includes essential details 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?

The tool has 5 parameters and no output schema. The description covers purpose and key behavioral aspects but does not describe the return format or what the extraction results look like. For a tool that analyzes and extracts, the output is not explained.

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 100%, but the description adds value by explaining the includeLawLookup parameter's role as a bridge to searchLaw and noting the performance impact. The lawLookupLimit parameter is also contextualized. This goes beyond the 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 extracts references to higher laws/regulations from a specific regulation text and optionally links to law lookup. It distinguishes itself from sibling tools by focusing on delegation analysis and bridging to search_law.

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 mentions the law lookup linkage but does not provide explicit guidance on when to use this tool versus alternatives like 'search_law' or other analysis tools. The context suggests it's for analyzing delegation in regulations, but no when-to-use or when-not-to-use 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?

Without annotations, the description adds some behavioral context by outlining the multi-step process (3-step comparison followed by parallel searches of interpretation cases, precedents, and administrative appeal). However, it does not explain side effects, authentication needs, or rate limits, leaving gaps.

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 very concise, fitting the core purpose and workflow into a single short sentence. It is front-loaded with the keyword 'chain' and 'disposition basis,' making it scannable. No unnecessary words.

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 as a chain that combines multiple legal sources, the description provides adequate context about the workflow and intended use. However, it lacks details about output format, return structure, or whether the result is a composite summary, which an agent might need for reliable invocation.

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

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

The input schema already describes the 'query' parameter with examples. The tool description reinforces the expected input pattern but does not further clarify parameters or the undocumented 'apiKey'. Schema coverage is 50%, and the description adds marginal value.

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 provides a 'disposition basis' for administrative actions, listing a specific workflow (3-step comparison, interpretation cases, precedents, administrative appeal in parallel). This differentiates it from sibling tools that focus on single types of legal documents.

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 mentions 'for questions on permission/disposition,' which implies a usage context, but it does not provide explicit guidance on when to use this tool versus sibling chain tools or when not to use it. No alternatives are named.

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?

No annotations provided, so description carries burden. It mentions the tool is a chain combining profile, topic matching, and gap analysis, but discloses no behavioral traits (e.g., read-only, destructive, rate limits). It gives high-level functionality only.

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 a single sentence that efficiently conveys the tool's purpose, with the essential elements front-loaded. Could be slightly more structured, but no wasted words.

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

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

Despite clear inputs, the description lacks details about the output format or structure. As a chain tool with no output schema, it leaves a significant gap in understanding what the agent will receive.

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?

Input schema descriptions already cover 100% of parameters. The tool description does not add meaning beyond what schema provides; it only restates the parameters' roles. Baseline 3 is appropriate.

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

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

The description clearly states it is a comprehensive benchmarking tool for an institution, combining profile, topic matching regulations, and peer gap analysis. It distinguishes from siblings like 'suggest_alio_benchmark' by being a 'chain' that does all three at once.

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 it is a starting point for benchmarking, but does not explicitly state when to use versus alternatives like 'suggest_alio_benchmark' or other chain tools. No guidance on when not to 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions 'automatic chaining' but does not explain side effects, data sources, permissions, rate limits, or return format. This leaves significant behavioral gaps.

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 a single short sentence with a usage hint, no repetition, and front-loads the core function. It is concise but could be slightly more structured to improve clarity.

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

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

Given the lack of output schema and many sibling tools, the description does not explain what the tool returns (e.g., format, structure). It mentions chaining old-new comparison and history but omits output details, making it incomplete for an agent to fully understand.

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 75% (3 of 4 parameters have descriptions). The description adds no extra meaning beyond the parameter descriptions; it only reiterates the overall purpose. With moderate schema coverage, a score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: tracking legal amendments with old-new comparison and article history. However, it does not differentiate from sibling 'chain_' tools like chain_law_system or chain_full_research, which also deal with legal analysis.

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 suggests usage 'when asking about amendment/change' but provides no explicit guidance on when not to use it or how it compares to other chain tools. The context is implied rather than explicit.

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?

No annotations are provided, so the description carries the full burden. It mentions performing parallel retrieval of multiple legal sources but lacks details on side effects, permissions, or limitations. It does not state that it is read-only or any behavioral traits beyond the parallel search.

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 a single concise sentence with an emoji, effectively communicating the core purpose and usage context. It is front-loaded with key information, though it could include more detail without losing 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?

The description fails to explain what the tool returns or how the parallel retrieval results are structured. No output schema is provided, leaving the agent without sufficient context to handle the response. For a meta-tool that chains multiple sources, more completeness is needed.

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 67%, meaning two parameters (query, domain) have descriptions, but the tool description adds no additional meaning beyond the schema. The apiKey parameter lacks any description in both schema and description.

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

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

The description clearly states it is for dispute preparation, combining precedents, administrative appeals, and domain decision cases in parallel. It specifies use for objection or lawsuit inquiries, distinguishing it from general search tools, but not clearly from other chain tools like chain_action_basis.

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?

Only implies usage when a user asks about objection/lawsuit, but provides no explicit guidance on when not to use or alternatives. No context for when to prefer this over other chain 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 description discloses the chained behavior (risk analysis → law search → precedent search) and the output (risk, relevant laws, precedents). However, no annotations exist, and the description lacks details on safety (read-only?), authentication needs (apiKey is a param but not mentioned), rate limits, or side effects. The disclosure is adequate but not comprehensive.

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 extremely concise, using two sentences with clear structure and front-loaded key terms (emoji, chain description). Every part adds value without redundancy.

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

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

The description explains the tool's purpose and chained process, which is useful for a complex tool. However, without an output schema, it lacks details on the return format or limitations (e.g., text length, timeout). The description is adequate for basic use but incomplete for advanced agent reasoning.

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 67% with text and maxClauses described; apiKey lacks description. The tool description adds overall context but does not enhance parameter understanding beyond the schema. Given moderate coverage, the description does not sufficiently compensate, resulting in a baseline score.

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

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

The description clearly states the tool performs a comprehensive document review with an automatic chain of risk analysis, law search, and precedent search. It specifies the use case for contract/terms review, distinguishing it from sibling chain tools like chain_action_basis or chain_law_system.

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

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

The description explicitly indicates usage for reviewing contracts/terms ('계약서/약관 검토 시'), providing clear context. However, it does not include explicit exclusions or when-not-to-use scenarios, though the specificity implies proper usage.

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

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

No annotations exist, so the description is the sole source. It discloses a parallel collection workflow but omits behavioral traits like error handling, rate limits, authentication details beyond the API key parameter, and whether it modifies data.

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

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

The description is two sentences, front-loaded with an emoji and key concept. Every phrase adds value with no redundancy or 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 (parallel multi-source collection) and lack of output schema or annotations, the description is too brief. It does not explain output format, error behavior, or success criteria, leaving the agent with incomplete information.

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

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

Schema coverage is 50% (query described, apiKey not). The description adds natural language examples for 'query' but does not clarify 'apiKey'. The description partially compensates for the coverage gap but not fully.

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: comprehensive research (종합 리서치) that performs parallel collection of AI search, statutes, precedents, and interpretations. It explicitly mentions handling complex questions in one go, distinguishing it from sibling tools that focus on individual sources.

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

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

The description provides clear context: use for complex questions needing multiple source types. It implies when to use but does not explicitly exclude simple queries or mention alternatives, leaving some ambiguity.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the automatic chaining process (법령검색→3단비교→조문→별표), which is a key behavioral trait. However, it does not disclose potential side effects (none expected, but not stated), authentication needs, or error handling, leaving some gaps.

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 brief (two lines) and front-loaded with the core purpose. It uses a compact structure with emojis and bullet points, making it scannable. However, it could be more concise in English and avoid the initial bracket emoji for broader accessibility.

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

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

Given the tool has 3 parameters, 1 required, and no output schema, the description should clarify what the tool returns. It only vaguely says '법체계 파악' without specifying the output format or content. For a chaining tool, the lack of detail on the final output or the steps' results reduces completeness.

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

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

The input schema has 67% description coverage (2 of 3 parameters described). The description adds context about the chaining process but does not explain parameters beyond what the schema already provides. The 'apiKey' parameter lacks description both in schema and description, so no added value.

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: to grasp the legal system by chaining law search, three-tier comparison, articles, and appendix. This clearly identifies the verb-phrase and resource (법체계 파악) and differentiates it from sibling chain tools like chain_action_basis and chain_alio_benchmark, which focus on different aspects.

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 notes '법 구조 질문 시' (for law structure questions), implying the tool is suitable for structural queries. However, it does not explicitly state when not to use it or mention alternative tools, leaving some ambiguity compared to sibling tools like get_law_system_tree or get_law_tree.

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?

No annotations are present, so the description carries full burden. It hints at a processing pipeline (upper law → delegation → nationwide search) but does not disclose key behaviors: whether the tool is read-only, requires an API key, what side effects exist, or the structure of the output. This is insufficient for safe invocation.

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 extremely concise, using a single line plus a tag. It front-loads the purpose with an emoji and Korean text. While brevity is appreciated, some behavioral details could be added without sacrificing structure.

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 of a comparative ordinance chain tool and the absence of an output schema, the description is too sparse. It fails to explain what the comparison result looks like, how delegation hierarchy is used, or how to interpret the output. This leaves the agent poorly equipped to use the tool 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?

The schema covers 67% of parameters with descriptions; the description adds minor value by noting 'parentLaw' auto-searches when unspecified. However, the core parameter 'query' is described only as 'keyword' without explaining how it influences the comparison. The apiKey parameter lacks any description.

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 indicates a tool for comparing ordinances, with a structured approach starting from upper legislation. It specifies the domain (autonomous law) and the function (nationwide search and comparison). However, it could more precisely define what 'comparison' entails (e.g., side-by-side or difference highlighting).

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 mentions 'for autonomous law questions,' providing context, but lacks explicit guidance on when to use this tool over siblings like search_ordinance or compare_articles. No when-not-to-use or alternatives are given, leaving the agent to infer selection from the name and 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?

No annotations are provided, so the description bears full responsibility. It discloses the automatic chaining behavior ('자동 연쇄') and steps (law->comparison->forms), but does not mention limitations, side effects, or failure modes. Adequate but not thorough.

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 a single concise sentence in Korean, front-loaded with a bracket identifier. It avoids unnecessary words, but the lack of structure (e.g., bullet points) is acceptable for brevity.

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 no output schema and two parameters, the description is incomplete. It does not explain what the tool returns, how many steps the chain involves, or any prerequisites. The user would need to infer the output format from the name and description, which is insufficient.

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

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

The schema description for 'query' is detailed with examples, but 'apiKey' has no description. Overall schema coverage is 50%, and the description adds context for the query parameter but does not compensate for the missing apiKey documentation. The examples help but cover only half the 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 it is a chain tool for procedure/cost, linking law to comparison to forms. The Korean text specifies the domain and chaining behavior, distinguishing it from other chain tools by focusing on procedures and costs.

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 there are application/procedure questions, but does not explicitly state when not to use or mention alternatives among the many sibling chain tools. The guidance is present but not comprehensive.

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?

No annotations are provided, so the description carries full burden. It mentions two modes but omits important details: what the comparison table contains, authentication needs (apiKey), side effects, or output format.

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 very short and front-loaded with the tool's purpose. However, it could be more structured (e.g., separate lines for modes) for clarity.

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?

Missing output schema and annotation details. The description does not explain what the comparison table looks like or the role of apiKey, leaving significant gaps for an agent.

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 100% with descriptions for all parameters. The description adds that id comes from search_admin_rule, which is helpful but not substantial beyond 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 compares old and new administrative rules, with two modes (search by query, lookup by id). However, it does not differentiate from sibling compare tools like compare_old_new, which may cause confusion.

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 when to use query vs. id (id from search_admin_rule), but lacks explicit guidance on when to prefer this tool over other comparison tools or exclusions.

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

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

No annotations are provided, so the description must bear the entire burden. It only mentions '1:1 precise comparison' and 'side-by-side output' but does not disclose whether it's read-only, required permissions, or any side effects. This is insufficient for a tool without 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?

Two sentences, front-loaded with key purpose, immediately followed by differentiation from sibling. No wasted words.

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

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

The tool is simple (2 params, no output schema). The description mentions side-by-side output but lacks details on format, error handling, or prerequisites. Minimally adequate for simple use, but leaves 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 coverage is 100% with descriptions for both parameters. The description adds little beyond the schema, only reinforcing the concept of same-article comparison. Baseline of 3 is appropriate.

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

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

The description explicitly states it compares the same article (e.g., Article 15) of two regulations precisely (1:1), and distinguishes it from the sibling tool compare_alio_regulations which does N:N topic comparison.

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

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

It clearly contrasts with compare_alio_regulations, indicating when to use this tool (for specific article comparison) versus the sibling (for topic-based comparison), giving explicit contextual guidance.

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

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

With no annotations, the description carries the full burden. It explains that the tool compares regulations based on topic and handles parameter defaults, but does not disclose whether the operation is read-only, any potential side effects, or what happens if no matches are found.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and usage. No unnecessary words or repetition.

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 no output schema and no annotations, the description is fairly complete, covering parameters and behavior. However, it does not describe the output format or how comparisons are presented, leaving some 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?

The input schema covers all parameters with descriptions. The description adds value by explaining the behavior of the 'institutions' parameter when omitted and how users can specify institutions, going beyond the schema.

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

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

The description clearly states the tool compares regulations between institutions based on a topic. The verb 'compare' and resource 'regulations' are specific, and it distinguishes from other sibling compare tools like 'compare_alio_articles' by focusing on regulations/provisions.

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 explains when to omit the 'institutions' parameter (automatic use of all collected institutions) and how to specify particular institutions. It provides clear usage context, though it does not explicitly mention when not to use this tool or 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?

No annotations are provided, so the description must supply behavioral context. It merely states 'compare' without disclosing side effects, permissions, or whether it is read-only. The minimal description does not compensate for missing 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 a single concise sentence. However, it is in Korean, which may hinder an English-oriented AI agent. Still, it is front-loaded and 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 (nested objects, three parameters, no output schema), the description is too sparse. It does not explain what the comparison returns or how the results are structured, leaving the agent without critical context.

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

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

Schema description coverage is 100% with descriptions for all parameters. The tool description adds no additional parameter information beyond what the schema already provides, so the baseline score is appropriate.

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

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

Description clearly indicates the tool compares two legislative articles ('법령 조문 비교') with a tag '[비교]' to suggest its function. However, it does not specify what aspect of the articles is compared (e.g., text, structure), leaving some ambiguity.

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 guidance is provided on when to use this tool versus the many sibling comparison tools (e.g., compare_admin_rule_old_new, compare_alio_articles). The description lacks context for distinguishing 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?

No annotations are present, so the description fully bears the burden. It only states '조회' (retrieve), implying a read operation, but does not disclose any behavioral traits such as input requirements (no required params), output format, potential side effects, or rate limits.

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

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

The description is a single sentence that efficiently conveys the core purpose. It is front-loaded with the action and resource. However, it is in Korean, which may reduce clarity for some agents; still acceptably concise.

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

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

Given the tool has 5 parameters with no required fields, no output schema, and no annotations, the description is too minimal. It does not explain how to use the parameters, what the comparison table contains, or what happens with an empty input. This leaves significant ambiguity for an agent.

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?

All 5 parameters have descriptions in the input schema (100% coverage). The tool description does not add any additional meaning beyond what the schema already provides, so it meets the baseline for high schema coverage.

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 indicates retrieving a comparison table of old and new laws. The tool name 'compare_old_new' reinforces this. However, the description does not specify the exact scope (e.g., full law text or specific provisions) or differentiate from sibling tools like 'compare_articles' or 'compare_regulation_timeline'.

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 guidance is provided on when to use this tool versus alternatives. Among many sibling comparison tools (e.g., compare_articles, compare_regulation_timeline), there is no context to help an agent choose correctly.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It describes that the tool compares timelines and identifies establishment timing, revision frequency, and recent revision institutions, indicating a read-only operation. However, it does not explicitly state it is idempotent or free of side effects.

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

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

The description is brief and front-loaded with the core purpose. Two sentences efficiently convey the tool's function without unnecessary words.

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

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

Despite the lack of an output schema, the description adequately outlines what the tool produces (comparison of timelines, establishment timing, revision frequency, recent institution). It provides enough context for an agent to understand the output, though finer details of the result format are not specified.

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

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

The input schema provides 100% description coverage for all three parameters. The tool description adds context by explaining the overall purpose but does not add significant parameter-level details beyond what the schema already provides.

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

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

The description clearly specifies the verb 'compare' and the resource: timelines of regulations on the same topic across institutions. It distinguishes itself from sibling comparison tools like compare_alio_articles and compare_old_new by focusing on timeline comparison rather than article text or version differences.

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

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

The description implies the tool should be used when comparing timelines of regulation revisions across institutions on the same topic, but does not explicitly state when to use it over alternatives or provide exclusions. No alternative tools are mentioned.

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?

With no annotations, the description carries full burden for behavioral traits. It does not disclose side effects (e.g., API calls), permission requirements, error behavior, or output format. Only the schema covers parameters; the description adds no behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. However, it is overly terse and could be expanded slightly to include usage context without losing 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?

Given the tool's complexity (3 params, no output schema, no annotations), the description is incomplete. It does not clarify what the tool returns (e.g., list of keywords) or how it relates to similar sibling tools like summarize_precedent. An agent may be uncertain without trial.

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 100%, providing clear explanations for all three parameters (id, maxKeywords, apiKey). The tool description adds no additional parameter information. Per guidelines, baseline is 3 with high schema coverage.

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 '판례 키워드 추출' (extract precedent keywords) clearly states the action (extract) and resource (precedent keywords). It distinguishes from siblings like 'summarize_precedent' or 'get_precedent_text' which provide different operations.

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 guidance is provided about when to use this tool vs alternatives. There is no mention of prerequisites, when-not to use, or preferred context. The description simply states the action without 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?

No annotations provided, so description carries full burden. Merely states 'reverse search' without explicitly confirming read-only nature or disclosing potential side effects, rate limits, or authentication 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?

Two sentences, no fluff. Front-loaded with [ALIO] tag and core purpose. Every word adds value.

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?

Tool has 5 parameters all described. No output schema, but as a search tool, return format is somewhat implied. Combined with schema, description is adequate for basic usage, though lacks detail on output structure.

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 100% with clear Korean descriptions for each parameter (e.g., lawName, article, institutions, matchMode, maxResults). Description adds minimal extra meaning beyond schema, meeting baseline for high coverage.

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 it performs reverse search for ALIO public institution regulations based on a higher law name, with optional article filter. It distinguishes from siblings like search_alio_regulation_text by focusing on reverse lookup.

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?

Implied usage for reverse searching regulations by upper law, but no explicit guidance on when to use this tool versus alternatives (e.g., search_alio_regulation_text, list_alio_regulations). No when-not-to-use or exclusions.

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

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

No annotations are provided, so the description must cover behavioral traits. It does not mention whether the tool is read-only, requires authentication beyond the apiKey parameter, or has any rate limits. The effects of the apiKey parameter are unclear.

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 extremely concise (one short phrase), but at the cost of sufficient information. While brevity is valued, here it leaves gaps that reduce overall effectiveness.

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 no output schema, no annotations, and a complex domain (legal precedents), the description is critically incomplete. It does not explain what 'similar' means, how results are returned, or any constraints, leaving an agent with insufficient context.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters adequately. The description adds no additional meaning beyond what the schema provides, resulting in a baseline score of 3.

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 action ('검색' meaning search) and the resource ('유사 판례' meaning similar precedents). It is specific enough to convey the tool's core function, but does not differentiate from sibling tools like 'search_precedents' or 'extract_precedent_keywords'.

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 guidance is provided on when to use this tool versus alternatives like 'search_precedents' or 'summarize_precedent'. There is no mention of prerequisites, limitations, or 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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions the matching is 1:N, excludes base institution by default, and uses a similarity threshold. However, it omits details such as what happens when no similar regulations are found, potential rate limits, authentication requirements, or the exact nature of the return values. This is adequate but not comprehensive.

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

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

The description is concise: two sentences that front-load the core action and use case. It is efficient and avoids fluff, but could be slightly more structured with bullet points or separated sections to improve scanability.

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

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

The description lacks detail about the output format (e.g., does it return regulation IDs, titles, similarity scores?) and does not mention pagination, sorting, or error handling. Given the absence of an output schema and the tool's moderate complexity (6 parameters, 4 required), the description is insufficient for an agent to fully understand the tool's capabilities and expected results.

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

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

The input schema has 100% description coverage, so the schema alone documents all parameters. The description provides a high-level framing (benchmarking, 1:N matching) but does not add significant detail beyond the schema's parameter descriptions. It repeats that 'threshold' is a similarity lower bound and 'excludeBase' excludes the same institution, which is already in the schema. Thus, baseline 3 is appropriate.

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

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

The description clearly states the action: searching for N regulations from other institutions with high title similarity to a given base regulation, explicitly for benchmarking. It uses a specific verb ('검색') and resource ('유사도가 높은 다른 기관 규정'), and the 1:N matching concept distinguishes it from siblings like 'find_similar_precedents' or 'suggest_alio_benchmark'.

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 hints at the use case ('직접 벤치마킹용') but does not explicitly specify when to use this tool over alternatives like 'suggest_alio_benchmark' or 'chain_alio_benchmark'. It provides implied context but lacks clear guidance on when-not-to-use or explicit 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?

With no annotations, the description carries full burden for behavioral disclosure. It omits whether the operation is read-only, any required permissions, or side effects. The description only states the output, not behavioral traits.

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 a single sentence, which is concise but too brief. It conveys the essential purpose but omits important details that could be included without verbosity. The structure lacks front-loading of 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 simplicity (no output schema, few parameters), the description is minimally adequate. It explains the source and type of document but lacks context on when or how to use, and does not discuss return format or limitations.

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 100%, so baseline is 3. The schema descriptions for 'id' and 'apiKey' are clear, and the tool description adds no extra meaning beyond what the schema provides.

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

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

The description clearly states the tool retrieves the full text of decisions from the Anti-Corruption and Civil Rights Commission (ACRC). Although it does not explicitly differentiate from siblings like get_acr_special_appeal_text, the name and context make the purpose clear.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_acr_special_appeal_text or other decision retrieval tools. The description does not indicate prerequisites or typical 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?

No annotations are provided, and the description does not disclose any behavioral traits such as whether the tool is read-only, error handling, or rate limits. The agent lacks critical context.

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

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

The description is very short but fails to include essential information. It is not appropriately front-loaded for an agent to understand quickly; it sacrifices completeness for brevity.

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

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

Given the lack of annotations and output schema, the description should provide more context about return values, error cases, and usage. It is incomplete and insufficient for agent decision-making.

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 100%, so the schema already describes the parameters. The description adds no additional meaning beyond what is in the schema (e.g., explaining the id parameter format).

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

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

The description mentions '재결례 전문' (full text of decision), which indicates the tool retrieves a specific document. However, it is in Korean and lacks clarity for English-speaking agents. It does not explicitly state that it retrieves the full text of a special administrative appeal 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?

No guidance is provided on when to use this tool versus the many sibling tools (e.g., get_acr_decision_text, search_acr_special_appeals). No alternatives or exclusions are mentioned.

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 only mentions it returns 'full text', but lacks details on authorization, rate limits, error handling, or behavior for invalid inputs. Without annotations, more transparency is needed.

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 a single concise line. It could be more informative without losing 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?

The description is minimally adequate for a simple get-text tool, but given the large number of similar siblings and no output schema, it lacks context about prerequisites and output format.

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 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter 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 it retrieves the full text of an administrative appeal case. The verb is implied and the resource is specific, but it does not differentiate from sibling tools like get_appeal_review_decision_text.

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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites or context for invocation.

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?

There are no annotations, and the description only says 'retrieve full text'. It does not disclose whether this is a read operation (implied), any authentication requirements beyond the API key, or error behavior for invalid IDs.

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 a single sentence with no waste, but it is under-specified. Conciseness is good but at the expense of necessary detail.

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 no output schema and a simple retrieval tool, the description could mention the return format or any limitations. It fails to provide enough context for an agent to understand what the full text contains.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description states the tool retrieves the full text of an administrative rule, which is clear but essentially restates the tool name. It does not differentiate from sibling tools like 'get_ordinance' or 'get_law_text', which also retrieve full texts of specific document types.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing an ID from search_admin_rule) or when not to use it.

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

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

No annotations provided, and the description only states the action and filtering options. Does not disclose whether the tool is read-only, requires permissions, or any side effects. Minimal behavioral context.

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

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

Single, front-loaded sentence that immediately conveys the tool's purpose without extraneous words.

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?

No output schema, so the return format is unspecified. The description does not explain the roles of required parameters 'institution' and 'listOnly' (listOnly is required but has a default false). The relationship between 'regId' and 'title' is ambiguous. Insufficient for full 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?

Schema description coverage is 100%, so the schema already documents parameters. The description reiterates 'annexNumber' and 'listOnly' functionality but adds no new semantic meaning beyond the schema.

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

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

The description clearly states the tool extracts [별표] (annex) sections from ALIO regulation text, using specific verbs and resource. The 'ALIO' prefix distinguishes it from sibling 'get_annexes' and other related 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?

No guidance on when to use this tool versus alternatives like 'get_alio_regulation' or 'get_annexes'. Does not mention prerequisites or exclusion 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?

No annotations provided, so the description carries the burden. It implies a read operation returning URLs and download links, with no side effects or destructive behavior mentioned. For a simple retrieval tool, this is adequate but not detailed.

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?

A single, front-loaded sentence that efficiently conveys purpose and usage. No redundant 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?

For a simple tool with no output schema, the description sufficiently explains the output (URL + download links) and use case. It could mention that it returns only links, but it's complete enough for its 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?

Input schema covers 100% of parameters with descriptions. The description adds no additional parameter meaning beyond what the schema provides. Baseline 3 applies.

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

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

The description clearly states it provides the ALIO original page URL and download links for current and past revisions, specifying the use case of verification and direct download. It distinguishes from siblings like get_alio_regulation which likely returns the regulation text.

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

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

It explicitly states when to use: 'when user wants to verify original/direct download.' It does not state when not to use or name alternatives, but the context is clear among 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?

With no annotations provided, the description carries the full burden. It lists the output components (number of regulations, distribution, revision frequency, recent revisions) but does not disclose any side effects, authentication needs, or data freshness. This is adequate but not comprehensive.

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 a single sentence that effectively communicates the tool's purpose. It is front-loaded with the tool's function. However, it could be slightly more structured (e.g., bullet points) without adding length.

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

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

The tool is simple with three parameters and no output schema. The description mentions the output components but does not specify format or structure. For a quick-overview tool, this is acceptable but leaves some ambiguity about the exact output representation.

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?

All three parameters have descriptions in the input schema covering 100% of parameters. The description adds context like '기관코드(apbaId)' for institution, but this does not significantly extend beyond the schema. Baseline 3 applies as schema already documents 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 explicitly states the tool provides a summary of a public institution's regulatory framework including counts, distribution, revision frequency, and recent revisions. It uses specific verbs and resources, distinguishing it from siblings like get_alio_statistics that offer different analytics.

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

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

The description clearly states the tool is for pre-investigation before comparison or quick grasp of unfamiliar institutions, implying the context for use. However, it does not explicitly state when not to use it or mention alternatives, which would improve guidance.

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

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

Annotations are absent, so the description must carry behavioral info. It states the output is markdown and supports partial matching and article extraction, which is useful. However, it does not disclose edge cases (e.g., when both regId and title are provided), error handling, or performance implications.

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 a single concise sentence that front-loads the core purpose and key features (markdown, partial match, article extraction). No unnecessary words.

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 no output schema, the description lacks details on return format, error responses, or handling of multiple matches. The schema is well-described but the overall completeness is adequate for a simple retrieval tool, though more context on usage with sibling tools would help.

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 100%, but the description adds value by explaining 'partial match' behavior for regId and title, and the ability to extract specific articles. This enhances the semantic understanding beyond the schema's parameter 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 retrieves regulation text in markdown with partial match on regId or title. It also mentions article filtering. However, it does not explicitly differentiate from sibling tools like 'list_alio_regulations' or 'search_alio_regulation_text', which have overlapping purposes.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage for looking up regulation text but does not provide criteria for choosing between partial match parameters or mention when not to use (e.g., for lists or 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool returns revision history but omits critical details such as read-only nature, authentication requirements, rate limits, or whether it modifies data. The description is insufficient for safe agent invocation.

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 extremely concise at a single sentence fragment, with no wasted words. However, it could be structured more clearly with separate sentences or bullet points. The brevity is acceptable but could improve readability.

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?

As a history retrieval tool, the description lacks essential context such as ordering of results, date range filtering, pagination, or typical use cases. With no output schema, the return format is only vaguely described. The description is incomplete 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?

Input schema has 100% coverage with descriptions for all three parameters. The tool's description adds no additional meaning beyond the schema; it does not explain how the parameters interact to retrieve revision history. Baseline score of 3 is appropriate given full schema coverage.

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 regulation revision history from ALIO disclosure attachments, specifying what it returns (previous file name and current version). This sufficiently conveys the verb+resource but does not explicitly differentiate from sibling tools like get_alio_regulation or list_alio_regulations.

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 guidance on when to use this tool versus alternatives. Given siblings that also deal with regulations, the description fails to provide context for selection, such as prerequisites or typical 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?

No annotations provided, so description must disclose behavioral traits. The description describes the output but does not explicitly state that the operation is read-only, non-destructive, or any related side effects. The name implies read-only, but explicit statement would improve transparency. No contradictions.

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

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

The description is concise, using a single sentence to convey the tool's purpose and usage context. It is front-loaded with the tool's function. However, it could be slightly more structured with separate sentences for purpose and usage.

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 with 4 parameters and no output schema, the description provides a good overview of the statistics offered (distributions, revision frequency) and the use case. It does not detail the output format but is sufficient for most agents. Could mention that it returns aggregate numbers.

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?

Input schema has 100% description coverage for all 4 parameters. The description adds no further parameter-level information beyond what is in the schema. Thus, the description is adequate but does not enhance parameter understanding beyond the schema.

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

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

Description clearly states the tool provides an overview of collected ALIO data including total counts, distributions, and average revision frequency. It distinguishes from specific regulation/institution tools by offering aggregated statistics. The verb 'get' and resource 'alio_statistics' with the context of data scope gauging makes it specific and distinct from sibling tools.

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

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

Explicit guidance is provided: use when LLM needs to gauge data scope before answering or when user judges reliability. This gives clear context. However, it does not mention when not to use or suggest alternatives, which would strengthen the guideline.

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?

With no annotations provided, the description carries the full burden. It states the tool extracts content from attachments but does not disclose any behavioral details such as whether it downloads, parses text, or any side effects. Minimal transparency for a read operation.

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

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

The description is concise with two sentences. It front-loads the purpose ('[별표] 별표/서식 조회') and then provides a usage hint. While brief, every sentence adds value; minor improvement could include clearer separation of usage 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?

Given no output schema and no annotations, the description is incomplete. It does not describe the output format (e.g., text, URL) or how to handle multiple attachments, pagination, or errors. A more complete description would clarify what the user receives.

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 100%, so parameters are already well-documented. The description adds value by explaining the usage pattern of combining lawName with '별표N', and notes that amounts/standards are in attachments, which relates to parameters like annexNo. However, it does not significantly enhance understanding of individual parameters beyond the schema.

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

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

The description clearly states it is for searching and extracting contents of attachments/forms ('별표/서식') using lawName and a pattern like '별표N'. It also notes that amounts/standards are often in attachments, which adds context. However, it does not differentiate from the sibling tool 'get_alio_annexes', which likely serves a similar purpose.

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

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

The description provides a specific usage hint: use lawName+'별표N' to extract content. This implies when to use the tool. However, it does not mention when not to use it or compare with alternative tools like 'get_alio_annexes', leaving room for ambiguity.

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?

No annotations are provided, so the description carries full burden. It merely states 'full text' without disclosing any behavioral traits such as authentication requirements, rate limits, or whether the operation is safe/read-only. This is insufficient for an agent to understand side effects or constraints.

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

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

Very concise single sentence that directly states the tool's purpose. It is front-loaded with the relevant prefix. However, it may be overly minimal given the lack of other 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?

The description is too sparse for a tool with 2 parameters, no output schema, and many sibling tools. It does not explain the return format, how to use the id parameter, or any prerequisites. Completeness is insufficient.

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 100% (both parameters have descriptions). The description adds no additional meaning beyond what the schema already provides. Baseline score of 3 applies.

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 it retrieves the full text of an appeal review decision (소청심사위원회 재결례 전문). The prefix '[소청심사]' helps distinguish it from similar sibling tools like get_acr_decision_text or get_admin_appeal_text, but no explicit differentiation is provided.

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 guidance on when to use this tool versus other get_*_decision_text tools or when to use it after search_appeal_review_decisions. The description lacks usage context and 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?

No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention any side effects, authorization requirements, rate limits, or return format, leaving significant gaps in 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?

The description is concise (one sentence) but contains a factual inaccuracy about required parameters. Conciseness without accuracy reduces overall effectiveness.

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 7 parameters, 100% schema coverage, and no output schema, the description does not add sufficient context about the return value or edge cases. The contradictory information about required fields further detracts from completeness.

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

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

The description contradicts the input schema by claiming mst/lawId are required ('필수'), while the schema lists only 'jo' as required. This is a critical error that could cause the agent to incorrectly invoke the tool without necessary 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 retrieves precise article details at the clause level (조항호목 단위 정밀 조회) and gives a concrete example (제38조 제2항 제3호). This distinguishes it among many sibling tools focused on other types of legal documents or broader searches.

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 specifies required vs optional parameters and implies usage for detailed clause lookups. However, it does not explicitly state when to avoid this tool or suggest alternatives, which would be helpful given the large sibling set.

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?

No annotations are provided, and the description only states the tool's function. It does not disclose read-only nature, potential rate limits, or any behavioral constraints. The description fails to compensate for missing 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 extremely concise (single sentence) and front-loaded. However, it is perhaps too minimal; a second sentence on usage or output would improve without losing 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?

Given 9 parameters, no output schema, and many sibling tools, the description is inadequate. It does not explain output format, pagination behavior, or differentiate from similar history tools.

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 100%, so the schema already explains all parameters. The description adds no additional meaning beyond the tool's overall purpose. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves revision history by article (조문별 개정 이력). It uses a specific verb-resource combination, distinguishing it from law-level history (get_law_history). However, it does not elaborate on what kind of history is included.

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 guidance on when to use this tool vs. alternatives like get_article_detail or compare_articles. The schema parameters are documented, but the description lacks context for selection.

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

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

No annotations are present, so the description carries full burden. It only states the tool performs a simultaneous search, but fails to disclose whether it is read-only, destructive, or any behavioral traits such as authentication requirements or pagination 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 a single short sentence in Korean, conveying the core function without waste. It could be slightly more descriptive in English context, but it remains efficient and front-loaded.

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

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

No output schema exists, and the description does not explain the return structure or how article and precedents are combined. Given the lack of output schema, the description should provide more context on the response format, but it does not.

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 100%, so baseline is 3. The description adds no extra meaning beyond what the schema already provides for the parameters. It does not elaborate on how parameters interact or format constraints not already 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 specifies '통합' (integrated) and '조문 + 관련 판례 동시 조회' (simultaneous query of article and related precedents), clearly stating the verb (조회/query) and resource (article + precedents). This distinguishes it from siblings like get_article_detail and get_precedent_text, which handle only one aspect.

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 both article and related precedents are needed, but it does not explicitly state when to use versus alternatives like get_article_detail or search_precedents. No when-not guidance or alternative names are 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?

No annotations are provided, so the description must carry the full burden. It mentions a limit of 20 items and bodyChars default/min/max, but does not indicate whether the operation is read-only, destructive, or requires special permissions. Safety and side effects are not disclosed.

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 two sentences, front-loading the purpose in the first sentence and efficiency in the second. Every sentence provides value without redundancy.

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

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

Given the complexity of a batch tool with nested items, the description covers the operation's scope and limits (max 20) but does not explain the return format, error handling, or how the response structures multiple results. Without an output schema, more detail would be helpful.

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 100%, so the description's added value is baseline. It states 'institution+regId+article 지정' but the schema shows only institution as required and article as optional, creating slight ambiguity. It does not clarify the relationship between regId and title or the format of institution.

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

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

The description clearly states it is for batch retrieval of regulations/articles (일괄 조회) with a max of 20 items. It specifies required components per item (institution+regId+article) and highlights efficiency over repeated single calls, distinguishing it from single-regulation 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 says to use when querying multiple regulations and implies efficiency, but it does not explicitly state when not to use this tool nor compare it to alternatives like get_batch_articles or sequential single calls. It provides some context but lacks exclusion 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?

No annotations are provided, so the description must disclose behavior. It mentions the two input modes but lacks details on authentication, rate limits, error handling, or response structure, leaving significant gaps for a batch tool.

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 very short and front-loaded with key information. It is efficient, though it could include a bit more structure to improve clarity.

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 of batch retrieval with multiple parameters and no output schema, the description is incomplete. It does not explain response format, error handling, or how to choose between modes, leaving the agent underinformed.

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 100%, so baseline is 3. The description adds minimal value by restating the two modes, but does not provide additional meaning beyond the schema's parameter 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 it is for batch retrieval of multiple articles, using either mst+articles or laws array. This distinguishes it from single-article tools like get_article_detail and batch regulation tools like get_batch_alio_regulations.

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 batch scenarios via '[배치]' and '일괄 조회', but does not explicitly state when to use this tool versus alternatives or provide exclusion 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?

No annotations are present, so the description must disclose behavioral traits. It fails to mention authentication needs, rate limits, error handling, or response format, leaving significant gaps.

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 very short and front-loaded, but it is too terse and lacks structure. It could be improved by expanding without being verbose.

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?

Without an output schema, the description should clarify what 'full text' entails. It does not specify the response structure, language, or any metadata, leaving the agent underinformed.

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 100% with clear descriptions for all parameters. The description adds no extra meaning beyond the schema, earning the baseline score.

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

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

The description states 'Full text of constitutional court decisions' which clearly identifies the tool's function and differentiates it from siblings like get_acr_decision_text. However, it lacks a verb in English and could be more direct.

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 guidance is provided on when to use this tool versus alternatives like search_constitutional_decisions or other get_*_text tools. The description does not indicate prerequisites or 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?

No annotations are present, and the description does not disclose behavioral traits such as read-only nature, error handling, or required permissions. The description only lists output components.

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 a single concise Korean sentence that front-loads the purpose. It could be more structured but avoids unnecessary words.

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?

Without an output schema, the description usefully specifies the response contents (query points, answers, reasons, related laws). However, it does not mention that the ID comes from a search result, which is important context.

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

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

Schema coverage is 100%, so the schema fully documents parameters. The description adds no extra meaning beyond the schema, achieving baseline for high coverage.

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

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

The description clearly states the tool retrieves the full text of customs interpretation cases, listing components (query points, answers, reasons, related laws). It is distinct from sibling tools like search_customs_interpretations and get_interpretation_text, though not explicitly differentiated.

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 guidance is provided on when to use this tool versus alternatives (e.g., after searching). The agent must infer that this is for full text retrieval given an ID from search results.

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?

No annotations provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or rate limits. It only states the basic search purpose.

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?

Single sentence is concise and front-loaded with the knowledge base context. Could be slightly more structured but effectively communicates the core 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?

No output schema exists, and the description does not clarify the return format. Given many sibling search tools, additional output details would improve completeness.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the parameter names and descriptions already in the schema.

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

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

Describes the tool as searching everyday terms to find legal terms (specific verb+resource). However, it does not differentiate from the sibling tool 'get_daily_to_legal', which likely has a similar purpose.

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 guidance on when to use this tool versus alternatives. No mention of when not to use or which sibling tools are better suited for specific 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?

No annotations exist, and the description does not disclose behavioral traits such as external API dependency (implied by apiKey parameter), rate limits, or output format. The tool's behavior is opaque beyond its basic function.

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 one short sentence, but it includes the prefix '[지식베이스]' which adds marginal context. Overall, it is concise and front-loaded, though it could be more streamlined.

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

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

Given the lack of an output schema and annotations, the description does not explain return values or the tool's place in a larger workflow. The apiKey parameter hints at an external API call, but this is not clarified. The tool's simplicity limits the need for extensive context, but key missing information reduces completeness.

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

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

The input schema covers both parameters with descriptions, and the description adds a concrete example (e.g., '월세' → '임대차'), which enhances understanding of the dailyTerm parameter. With 100% schema coverage, this is above the baseline.

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 maps everyday terms to legal terms, using a specific verb and resource. However, it does not differentiate itself from the sibling tool 'get_legal_to_daily', which performs the reverse mapping.

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

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

No guidance is provided on when to use this tool versus alternatives like 'get_legal_to_daily' or other search tools. The agent is left to infer usage from the name alone.

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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention pagination behavior, authentication requirements beyond the schema, rate limits, or what happens if no results are found. The description is too minimal.

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 a single concise sentence in Korean, front-loading the purpose. It is efficient but could include slightly more context without becoming verbose.

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

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

Given the lack of output schema and annotations, the description is insufficient. It does not explain the return format, how to interpret results, or provide usage examples. More context is needed for an external API tool.

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

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

Schema description coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states it lists delegated laws by ministry, using the verb '조회' (search/list) and resource '위임법령 목록'. It is specific and distinct from sibling tools that focus on general laws or regulations, but does not explicitly differentiate itself.

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 guidance is provided on when to use this tool versus alternatives like search_law or get_law_text. The description lacks context for appropriate usage, prerequisites, or exclusions.

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

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

No annotations are provided, and the description fails to disclose any behavioral traits such as authentication requirements, rate limits, or output format. For a tool with no behavioral metadata, the description carries full burden but adds no value.

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 extremely concise, but at the expense of completeness. It could benefit from a sentence structure that front-loads essential details, but currently it is a fragment.

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

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

With no output schema and 4 parameters, the description should explain what the tool returns and how to use it. It only says 'full text' without any additional context on behavior or prerequisites, making it inadequate.

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 100% with adequate parameter descriptions (e.g., '법령ID', 'MST', 'lawName', 'apiKey'). The description adds no extra meaning, but the schema itself is informative. Baseline 3 is appropriate.

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

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

The description '[영문] 영문 법령 전문' clearly indicates the tool retrieves the full text of English statutes. The verb 'get' and resource 'English law text' are specific, and it is distinguishable from siblings like 'get_law_text' by the explicit mention of English.

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 guidance on when to use this tool over alternatives such as 'search_english_law' or 'get_law_text'. The agent is left to infer usage without any contextual cues or exclusionary statements.

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?

No annotations provided. Description lacks any behavioral traits such as read-only nature, side effects, or required permissions. Agent cannot infer what happens when the tool is called.

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?

While very short, the single sentence is not informative and fails to earn its place. It provides no meaningful 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?

Given 9 parameters, no output schema, and no annotations, the description is severely incomplete. Agent lacks understanding of return format, parameter combinations, or when to use specific params.

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 descriptions are provided for all parameters (100% coverage), so baseline is 3. The tool description adds no extra meaning beyond the schema.

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

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

Description '법령 외부 참조 링크' (Legal external reference link) is vague and essentially restates the tool name 'get_external_links'. It does not specify whether the tool retrieves, generates, or lists links, nor does it differentiate from the sibling 'get_alio_external_links'.

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 guidance on when to use this tool versus alternatives like 'get_alio_external_links' or other search tools. No context on prerequisites or 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?

No annotations are provided, and the description is minimal—it only states that it gets full text. It does not disclose potential errors, authentication needs (apiKey described in schema but not elaborated), rate limits, or response format, leaving the agent uninformed about behavioral nuances.

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 a single sentence with no extraneous information. It is efficient, though it could be slightly more informative without losing 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?

Given no output schema and no annotations, the description is adequate for a simple retrieval tool but leaves gaps: it does not state the output format, error behavior, or that the ID comes from a search result (schema does). It is minimally 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?

Both parameters have schema descriptions (100% coverage). The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves the full text (전문) of FTC decisions. The verb 'get' and resource 'decision text' are specific. Among siblings, search_ftc_decisions is for searching, so this tool is distinct for retrieval 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?

No explicit when-to-use or when-not-to-use guidance. The context of sibling tools (search_ftc_decisions) implies this tool is for after searching, but no direct exclusions or alternatives are mentioned.

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?

No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states the tool performs an inquiry but does not reveal whether it is read-only, requires authentication (API key hinted in schema), or what the response format is.

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 a single sentence, which is concise but lacks important context. It is front-loaded with a tag, but overall it could be more informative without becoming verbose.

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

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

Given the lack of annotations and output schema, the description should explain more about what the tool returns and how to use it effectively. It only describes the action without clarifying outputs or usage steps, making it incomplete for an agent.

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 100%, with each parameter having a description in the schema. The tool description adds no additional meaning beyond the schema, such as how '특정 시점' relates to the 'mst' parameter. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool is for querying historical laws at a specific time, using a specific verb ('조회') and resource ('연혁법령'). However, it does not explicitly differentiate from sibling 'search_historical_law', which likely searches for historical laws before retrieving details.

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 prerequisites (e.g., using search_historical_law first) or the appropriate context for invocation.

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?

No annotations are present, so the description bears full responsibility for behavioral disclosure. It does not mention read-only nature, authentication needs, rate limits, or any side effects.

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

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

The description is extremely short—a single phrase. While concise, it lacks substantive information, making it minimally adequate.

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 absence of an output schema and the presence of many similar sibling tools, the description provides insufficient context. It does not describe return value format, pagination, or prerequisites.

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 100% with descriptions for all three parameters. The description adds no extra meaning beyond what the schema already provides, meeting the baseline.

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

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

The description states it retrieves the full text of an interpretation case. It clearly identifies the verb (조회=search/retrieve) and resource (해석례=interpretation case), but it essentially paraphrases the tool name without adding detail to distinguish it from many similar 'get_*_text' sibling tools.

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

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

No guidance is provided on when to use this tool versus alternatives like search_interpretations or other get_text tools. The description lacks context for proper selection.

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

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

No annotations are present, and the description only states the function and date filtering. It does not disclose behavioral traits such as read-only nature, authentication requirements (though apiKey parameter hints at auth), pagination, or rate limits, which are necessary given the absence of 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 two short sentences that front-load the core purpose and filter capability. Every word adds value, with no unnecessary 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?

For a simple list retrieval tool with optional date filtering and authentication, the description covers the essential aspects. It does not mention pagination or error handling, but these are not critical given the tool's simplicity. Minor improvement possible.

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?

All three parameters are described in the schema with 100% coverage. The description reinforces the filtering purpose of stdDt/endDt but adds no new meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states it retrieves a full list of law abbreviations, which is a specific resource. The [유틸] prefix and '전체 목록 조회' make the purpose unambiguous, though it does not explicitly differentiate from sibling tools.

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

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

No guidance is provided on when to use this tool versus alternatives. It mentions date filtering but does not specify scenarios or prerequisites, leaving the agent without context for selection.

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

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

No annotations are provided, and the description does not disclose any behavioral traits beyond listing results. It fails to mention whether the operation is read-only, has rate limits, requires authentication (apiKey parameter hints at this but description doesn't clarify), or any other side effects. The minimal description does not compensate for the lack of 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 extremely short—a single phrase. While concise, it omits essential details about the tool's behavior and usage. It is not efficiently front-loaded because it lacks the key decision-making information for an AI agent. A 3 reflects that it is not verbose but also not optimally informative.

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

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

Given the tool has 5 parameters, no output schema, and moderate complexity (pagination, required date), the description is far from complete. It does not explain the structure of the returned list, any ordering (e.g., chronological), or how pagination parameters interact. The agent cannot fully understand the tool's behavior from this description alone.

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

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

The input schema has 100% description coverage, with each parameter including a clear description (e.g., 'regDt' explained as date format). The tool description adds no additional semantics beyond what the schema already provides. The baseline score of 3 is appropriate since the schema does the heavy lifting.

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 '[Law] List of law change history' clearly states the tool's purpose as listing law amendment history. The name 'get_law_history' and short description effectively identify the resource, though it doesn't explicitly differentiate from sibling tools like 'get_alio_regulation_history' or 'get_article_history'. However, the context implies a higher-level law history, making it sufficiently clear.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, contexts, or exclusions. The agent is left to infer usage solely from the name and parameter schema, which is inadequate for distinguishing between similar history-related tools.

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

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

No annotations exist; the description fails to disclose behavioral traits like ordering of 'TOP N' (e.g., recency or number of amendments), read-only nature, rate limits, or output format. This is inadequate for a tool with no annotation support.

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 a single, efficient sentence that is front-loaded with a category prefix. It is concise but could be slightly more informative about ordering without becoming verbose.

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

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

With no output schema and a simple description, important details are missing: what defines 'TOP N' (e.g., recency vs. number of amendments), output structure, and differentiation from overlapping sibling tools. The description is incomplete 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?

Schema coverage is 100% with clear parameter descriptions. The description adds minimal extra meaning, merely confirming '지정 기간(일)' for days. Baseline 3 is appropriate.

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

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

The description clearly states the verb (조회 - view), resource (법령 - laws), and scope (최근 개정 TOP N - recent amendments top N), distinguishing this tool from siblings like get_recent_alio_revisions by focusing on statistics and top N results.

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 guidance is provided on when to use this tool versus alternatives such as get_alio_statistics or get_recent_alio_revisions. The description lacks context on prerequisites or exclusions.

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

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

No annotations provided; description only hints at purpose. Does not disclose what happens with no required parameters, whether it modifies data, rate limits, or output structure. Carries full burden but fails to add behavioral context beyond a vague purpose.

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