Server Quality Checklist

Tool Scores

• get_admruleA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the purpose (body text retrieval) and the id source, but does not mention return format, error handling, authorization requirements, or side effects. This is a significant gap for a tool expected to be invoked independently.

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

  Conciseness5/5

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

  The description consists of two short sentences, front-loaded with the tool's purpose and followed by essential parameter context. Every word is informative, with no filler or redundancy.

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

  Completeness4/5

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

  For a simple get-by-id tool with one parameter and no output schema, the description covers the essential aspects: what the tool does (returns the body of an administrative rule) and where to obtain the required parameter. It lacks information about error conditions or response structure, but is adequate for straightforward use.

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

  Parameters4/5

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

  The input schema provides only the parameter 'id' (string) with no description. The tool description adds meaning by specifying that 'id' is the administrative rule ID from search_admrule results, directly compensating for the 0% schema description coverage. It does not provide format specifics, but the semantic is clear.

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

  Purpose4/5

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

  The description clearly states the tool's function: retrieving the full text (본문) of administrative rules (고시·훈령·예규). It uses a specific verb (조회) and resource, and implicitly distinguishes itself from search tools by focusing on retrieval by ID. However, it does not explicitly contrast with sibling 'get' tools like get_law or get_interpretation.

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

  Usage Guidelines4/5

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

  The description explains that the 'id' parameter is the administrative rule ID from search_admrule results, providing clear contextual guidance that this tool is meant to be used after a search. It does not explicitly mention when not to use it or list alternatives, but the search-to-get workflow is well implied.

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

• search_admruleA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden for behavioral disclosure. It only hints at a mapping use case but fails to describe return format, pagination, required permissions, or side effects. This is minimal guidance for a search tool.

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

  Conciseness5/5

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

  The description is exactly two sentences, front-loaded with the primary function and followed by a specific use case. Every sentence carries useful information, with no redundancy or filler.

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

  Completeness3/5

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

  For a single-parameter search tool with no annotations and no output schema, the description provides the core purpose and a usage context. However, it lacks parameter details and return value expectations, leaving the agent to infer how to construct the query and interpret results. This is adequate but has clear gaps.

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

  Parameters3/5

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

  With schema description coverage at 0%, the description must compensate. It partially does by indicating the query relates to administrative rules and indirectly suggesting it may be a notice name. However, it does not explicitly specify the query format or acceptable values, so it only marginally adds meaning beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: searching for administrative rules (고시·훈령·예규). It also provides a specific use case—mapping notice names from smart search results to Ministry of Government Legislation IDs—which distinguishes it from sibling tools like search_law or search_interpretation.

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

  Usage Guidelines4/5

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

  The description explicitly states a concrete trigger scenario ('when mapping the notice name from smart search results to the ID'), giving clear context for when to use it. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.

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

• search_interpretationA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the tool is read-only (a search) and the nature of the content (ministry Q&A responses), but does not describe output format, pagination, authentication, or any limitations. It adds some behavioral context beyond the name but falls short of a comprehensive disclosure.

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

  Conciseness5/5

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

  The description is extremely concise, two short sentences. It front-loads the action (법령해석례 검색) and then provides useful context (equivalent to ministry Q&A, purpose for identifying disputes). No filler or redundant information.

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

  Completeness3/5

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

  For a simple search tool with one parameter and no output schema, the description provides the core purpose and use case, but lacks details on expected results (e.g., list of cases, metadata) and any constraints. Given the lack of annotations and output schema, the description is adequate but incomplete for a fully informed invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain what the 'query' parameter should contain (e.g., keywords, statutory provision numbers, etc.). The description only says 'search interpretation cases' without guiding the agent on how to construct the query, leaving the sole parameter under-specified.

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

  Purpose5/5

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

  The description clearly states the tool searches for legal interpretation cases (법령해석례 검색) and specifies the use case (identifying disputed interpretation issues). It distinguishes from siblings like search_law and search_admrule by focusing on interpretation cases, with the added context of ministry Q&A responses.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: when checking issues where interpretation of provisions is divided (조문 해석이 갈리는 쟁점 확인용). It implies this is for searching interpretation precedents, but it does not explicitly name alternatives or state when not to use it.

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

• search_kosha_guideA
  3.8/5.0
  Behavior3/5

  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 does state the return fields, which is useful, but it does not disclose whether the operation is read-only, whether there are any side effects, authentication requirements, or pagination behavior. The mention of '캐시 보유 여부 반환' (returns cache availability) adds a minor behavioral detail, but overall the description is sparse.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and output. It contains no redundant words and is easy to scan, making it highly concise and well-structured.

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

  Completeness4/5

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

  Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is mostly complete. It covers the core function and return fields, and the schema covers parameter optionality. However, it lacks explicit context about when to use this tool versus sibling tools like `get_kosha_guide`, and could benefit from a note on intended use cases.

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

  Parameters3/5

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

  The input schema fully describes the single `keyword` parameter, including its meaning (규정명/번호 키워드) and optionality (생략 시 전체), providing 100% coverage. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb ('검색' = search) and resource ('KOSHA GUIDE 기술지침 목록' = KOSHA GUIDE technical guideline list), and specifies the return fields (regulation number, name, publication date, PDF link, cache availability). This clearly distinguishes it from the sibling tool `get_kosha_guide`, which likely retrieves a single guide rather than searching a list.

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

  Usage Guidelines3/5

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

  The description does not provide explicit when-to-use or when-not-to-use guidance. The use case is implied by the resource name 'KOSHA GUIDE', but alternatives or exclusions are not mentioned. An agent must infer that this tool is for KOSHA guide searches versus other search tools like `search_law` or `search_admrule`.

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

• get_kosha_guideA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description takes on full responsibility for disclosing behavior. It transparently explains the cache-first strategy (로컬 캐시 우선), the download-and-extract flow on cache miss/revision, and the fallback to returning a PDF link when extraction fails (e.g., scanned documents). This covers key behavioral nuances beyond mere 'lookup', though it omits details like error responses or permission requirements.

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

  Conciseness5/5

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

  The description is exceptionally concise: two sentences that front-load the core purpose, then add valuable caching and failure-mode details. Every clause contributes meaningful information with no redundancy or filler.

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

  Completeness4/5

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

  Given the tool's simple interface (1 required parameter, no output schema, no annotations), the description covers the essential behavior: what it does, how it handles cache misses, and what happens on extraction failure. It could optionally mention the exact response shape, but the mention of 'md' body and PDF link fallback provides sufficient context for an agent to understand the tool's operation.

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

  Parameters3/5

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

  The input schema fully describes the only parameter 'guideNo' with an example, achieving 100% schema description coverage. The description does not add additional parameter-level meaning beyond what the schema already states, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool retrieves the markdown body of a KOSHA guide via '본문(md) 조회', which distinguishes it from sibling search tools like search_kosha_guide and other retrieval tools like get_law. The verb '조회' (lookup) combined with the specific resource 'KOSHA GUIDE' and format '(md)' provides a specific and unambiguous purpose.

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

  Usage Guidelines3/5

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

  The description implies usage for fetching a specific guide's content by guide number, but it does not explicitly state when to use this tool versus alternatives like search_kosha_guide for finding guides. No exclusions or alternative conditions are given, so the usage context is only implied rather than clearly delineated.

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

• get_msdsA
  4/5.0
  Behavior3/5

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

  The description discloses a key behavioral trait: if no section is specified, it defaults to only sections 2, 8, and 15. It also provides semantic meaning for those sections. However, with no annotations provided, it does not mention output format, potential errors, or other side effects, so transparency is partial.

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

  Conciseness5/5

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

  The description is compact—two sentences—and front-loaded with the primary purpose. It efficiently packs in the section range, key section meanings, and the default behavior without unnecessary verbosity.

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

  Completeness4/5

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

  For a tool with only two parameters and no output schema, the description covers the essential invocation logic: what sections are available, what the default is, and how to reference the chemical (via chemId from search_msds). A small gap is that it doesn't describe the return format, but that is not critical for correct invocation.

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

  Parameters4/5

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

  Schema coverage is only 50% (chemId is described, section is not). The description adds significant meaning to the 'section' parameter by listing the section numbers and their meanings, and specifying the default behavior. This compensates for the schema gap and provides actionable context.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'MSDS 항목 본문 조회' (MSDS item body inquiry) with explicit scope (sections 1-16). It distinguishes itself from sibling tools like search_msds by focusing on retrieving specific sections rather than searching for substances.

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

  Usage Guidelines3/5

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

  The description implies usage after a search (via chemId parameter being 'search_msds 결과의 chemId' in the schema), and the default behavior is described. However, it does not explicitly state when to use this tool compared to alternatives or provide exclusionary guidance, 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.

• search_lawA
  4/5.0
  Behavior3/5

  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 discloses the auto-expansion of abbreviations (약칭 자동 확장) and its coverage of upcoming amendments, which are useful behavioral traits. However, it does not describe the return format or any other side effects. Given the absence of annotations, this is adequate but not exhaustive.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose, followed by usage context and a special feature. Every clause serves a purpose with no redundancy or filler.

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

  Completeness4/5

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

  For a search tool with three parameters and no output schema, the description is quite complete. It explains the tool's scope, key use cases, and a behavioral quirk (auto-expansion). The schema covers parameter details. It does not explicitly state the return shape, but that is implied by the search function and not required given the absence of an output schema.

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

  Parameters3/5

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

  Schema description coverage is 67%, with scope and upcoming well-documented in the schema. The description adds context about abbreviation expansion, which relates to query behavior, but does not directly explain query syntax. The schema handles most parameter semantics, and the description adds marginal value beyond it.

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

  Purpose5/5

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

  The description clearly identifies the tool as a statute search (법제처 법령 검색) and distinguishes it from siblings by specifying it covers chemical statutes outside smart search coverage and upcoming amendments. The verb+resource is 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.

  Usage Guidelines4/5

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

  The description explicitly states when to use: for laws outside smart search coverage and for detecting upcoming amendments. It implies smart_search is the alternative for other searches, but does not explicitly list exclusions. This is clear context with no stated 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.

• search_msdsA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must fully convey behavior. It discloses that the result contains a chemId and that get_msds should be called with it, providing useful workflow context. However, it does not mention that the operation is read-only, whether multiple results are returned, or any other behavioral specifics.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently conveys the purpose and the follow-up action without any wasted words.

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

  Completeness4/5

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

  For a simple search tool with only two parameters, the description covers the search types and the workflow via chemId. However, since there is no output schema and no annotations, it falls short of fully specifying the return shape or result multiplicity, though it is adequate for basic navigation.

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

  Parameters3/5

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

  The input schema already provides complete descriptions for both 'query' (substance name or CAS number) and 'byCas' (whether to search by CAS). The description adds no new parameter information, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states 'MSDS chemical search' with a specific verb (search) and resource (MSDS), and it distinguishes itself from sibling tools by focusing on chemical substances. It also specifies search by name or CAS number, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description does not explicitly name alternative tools, but it provides clear usage context by indicating this is the search step for MSDS data and instructing to call get_msds with the returned chemId. This implies a structured workflow, though it lacks explicit exclusions compared to sibling search tools.

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

• get_interpretationA
  4.2/5.0
  Behavior3/5

  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 clarifies that the id must be from search_interpretation, which is useful, but it does not describe the output format, error handling for invalid ids, or explicitly state that this is a read-only operation (though '조회' implies reading). The description is minimal and lacks richer 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.

  Conciseness5/5

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

  The description is exceptionally concise, comprising two clauses that state the tool's purpose and the id's origin. Every word earns its place, with no redundancy or vague filler. It is appropriately sized for a simple get-by-id tool.

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

  Completeness4/5

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

  Despite the lack of annotations and output schema, the description provides sufficient context for selecting and invoking the tool: it names the resource, confirms the id comes from a specific search tool, and implies the return of the full text via '본문 조회'. It would benefit from a note about the expected response type, but the essential information for a get-by-id operation is present.

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

  Parameters4/5

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

  The schema provides only the parameter name 'id' with type string and no description. The tool description compensates by explaining that the id is the '법령해석례일련번호' (serial number) from search_interpretation results, which adds essential meaning beyond the raw schema and helps the agent understand exactly what value to provide.

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

  Purpose5/5

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

  The description explicitly states the tool's function: '법령해석례 본문 조회' (retrieve the full text of statutory interpretation precedents). It names a specific verb ('조회') and resource ('법령해석례 본문'), and distinguishes itself from sibling tools like search_interpretation by indicating this is a direct lookup by id rather than a search.

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

  Usage Guidelines4/5

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

  The description notes that 'id는 search_interpretation 결과의 법령해석례일련번호' (the id is the serial number from search_interpretation results), which clearly implies this tool should be used after obtaining an id from a search. This gives practical context for when to use it, though it does not explicitly mention alternative tools for different scenarios.

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

• get_annexA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It transparently notes that on extraction failure, a file link is returned, which is valuable context. Normal return is implied as text content, which is sufficient for a read-only lookup tool.

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

  Conciseness5/5

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

  The description is extremely concise, split into three short segments: main purpose, key examples, and failure behavior. Each sentence earns its place and the most important information is front-loaded.

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

  Completeness5/5

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

  For a simple 2-parameter lookup tool with full schema coverage, the description covers purpose, usage examples, and failure behavior. No output schema exists, but the return value is clearly implied by '본문 조회' (text lookup), making this complete.

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

  Parameters3/5

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

  Schema description coverage is 100% with both parameters well-described, including examples. The description adds domain-specific context (which annex numbers matter) but does not add new syntax or format details 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.

  Purpose5/5

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

  The description clearly states the tool's function: lookup of annex/form text of statutes ('법령 별표·서식 본문 조회'). It gives concrete examples of key annexes (training hours, special health exam cycle) which distinguish it from siblings like get_law or search_admrule.

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

  Usage Guidelines4/5

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

  The description provides practical usage examples (e.g., training hours = Enforcement Rules Annex 4·5, special health exam = Annex 23), implicitly guiding when to use this tool. However, it does not explicitly mention when not to use it or name alternative tools.

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

• get_lawA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description discloses key behavioral traits: omitting article returns the full text, but large laws may be truncated. It also clarifies that mst is a law serial number from search_law. However, it does not mention error handling or response format, which could be expected for a retrieval tool.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the primary purpose. Every clause adds value: the mst relationship, article filtering, and truncation warning. No fluff or redundancy.

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

  Completeness4/5

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

  For a two-parameter retrieval tool, the description covers the main aspects: what it fetches, how to get the mst, how to specify an article, and the truncation caveat. It does not describe the exact return structure, but no output schema exists, so the description is reasonably complete for typical use.

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

  Parameters4/5

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

  Schema has 0% description coverage, so the description must compensate. It explains that mst is a law serial number from search_law and provides article format examples (e.g., 제36조, 제10조의2). This adds essential meaning beyond the bare parameter names.

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

  Purpose5/5

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

  The description explicitly states the tool retrieves the text of law articles ('법령 조문 본문 조회') and ties it to the MST from search_law results. This clearly differentiates it from sibling tools like get_admrule, get_interpretation, and get_annex.

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

  Usage Guidelines4/5

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

  The description explains the prerequisite that mst comes from search_law results and describes how to use the article parameter for specific provisions. It lacks explicit 'when not to use' guidance, but the resource-specific context makes when-to-use clear.

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

• smart_searchA
  4.6/5.0
  Behavior4/5

  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 adds valuable context: AI synonym matching (with an example '스카이'→고소작업대), cross-cutting search across multiple regulation types, and a specific exclusion. However, it does not disclose behavior around pagination, result format, or any rate/auth requirements, which are common for search tools. Given the zero annotation baseline, the description provides meaningful but incomplete behavioral transparency.

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

  Conciseness5/5

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

  The description is three focused sentences: the first states purpose and scope, the second highlights a key feature (synonym matching), and the third gives an exclusion with an alternative. Every sentence contributes new information, and the most important usage context is front-loaded. No redundancy or fluff.

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

  Completeness4/5

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

  Given the tool's moderate complexity (cross-legal search, 2 parameters, no output schema), the description covers essential context: corpus scope, exclusions, synonym feature, and an alternative tool. It does not explain the 'page' parameter or result structure, which would be expected for a paginated search. Still, the description is largely sufficient for an agent to select and invoke the tool correctly for most queries.

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

  Parameters4/5

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

  The schema describes 'query' as '검색어 (자연어 가능)' but provides no description for 'page'. The tool description adds value by explaining that queries support AI synonym matching and are natural-language friendly, which enriches the query parameter semantics. However, 'page' remains undocumented in both schema and description. With 50% schema coverage and some compensations, a 4 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool is the '1차 진입점' (primary entry point) for safety and health queries and enumerates the specific legal sources it searches: 산업안전보건법·령·규칙, 안전보건기준에 관한 규칙, 고시·훈령·예규, 중대재해처벌법, KOSHA GUIDE. This specific verb+resource combination distinguishes it from sibling tools that target individual corpora such as search_law or search_kosha_guide.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use the tool: '안전보건 질의의 1차 진입점' (first entry point for safety/health queries). It also provides a clear exclusion: chemical laws (화관법·화평법·위험물법) are not covered, and directs users to 'search_law' instead. This explicit when/when-not and named alternative fully satisfies the guidelines dimension.

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