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 states the tool outputs basic info and a list of changed articles with `**변경**` highlights, which is transparent. It does not mention safety or side effects, but given it is a comparison tool, destructive actions are unlikely.

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: it states the core function, highlights key features, provides a concrete use case, and suggests next steps—all in a few sentences with no redundancy. The most important information is front-loaded.

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

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

Given the tool has no output schema, the description provides a reasonable overview of return content (basic info + changed articles list with highlights). It could be more specific about the structure but is sufficient for an agent to understand what to expect.

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% coverage, and the description adds significant meaning: it explains that the mst parameter accepts both new and old serial numbers and references how to obtain it from search_admin_rule results. This goes well beyond the schema's own 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 the tool compares old and new administrative rules, with parallel display and highlighted changes. It distinguishes from siblings like compare_articles and compare_old_new by specifying '행정규칙' (administrative rules) and provides a concrete use case for PIPC notice tracking.

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

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

The description gives clear context for use: tracking PIPC notice revisions. It names alternative tools (get_admin_rule_text for full text, search_admin_rule for other notices) and suggests next steps. It does not explicitly exclude other scenarios or differentiate from all siblings, but the guidance is solid.

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 compensates by detailing internal calls (dual lawService invocations), truncation behavior, and diff absence. Missing details on rate limits or error handling, but overall sufficient.

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 concise with purpose first, then details. Slightly wordy with technical Korean phrases but overall efficient for the complexity.

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 nested params and no output schema, description covers internal workflow, truncation, and usage guidance. Minor gap: no mention of return format, but sufficient for agent to 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; description adds context by explaining mst comes from search_law, jo supports both Korean and numeric formats, and efYd is time-specific. Adds value 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?

Description clearly states the tool compares two legal articles side-by-side, with specific examples (PIPA §15 vs §17). It distinguishes from sibling tools like compare_admin_rule_old_new by focusing on general legal articles.

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?

Explicitly explains when to use (comparing specific articles), limitations (no auto-diff, 6,000 character truncation per side), and next steps (get_law_text, search_law). Provides clear context for agent decision-making.

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 states the tool compares old and new versions and highlights changes, but does not mention auth requirements, side effects, data persistence, or error handling. For a read-like operation, this is adequate but lacks detail.

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

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

The description is two sentences with no extraneous content. The first sentence defines the tool's function, and the second provides usage guidance and links to related tools. 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 single parameter and straightforward comparison task, the description covers the main aspects: what it compares, how changes are highlighted, and a practical example. Though no output schema exists, the description outlines the output format (basic info + list of changed articles). Minimal gap remains.

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 single parameter 'mst' is fully documented in the schema. The description adds value by explaining that both old and new mst are accepted and how to obtain them (from search_law or get_law_history). This goes beyond the schema's own 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 compares old and new versions of a law, highlighting changes with `**변경**`. It specifies the target (법제처 lawService · target=oldAndNew) and gives a concrete use case (PIPA tracking). This differentiates it from siblings like get_historical_law and get_law_history.

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 says when to use this tool (tracking changes in frequently amended laws like PIPA) and what to do next (use get_historical_law for full text, get_law_history for other comparisons). It provides clear 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?

Discloses automatic abbreviation of long reasons, a key behavioral trait. No annotations are provided, so the description carries full burden. It specifies the source (lawService, target=decc) and extraction fields, but does not mention error handling or permissions, which is partially acceptable for a read-only 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?

Single sentence packed with purpose, extraction details, behavior, and usage guidance. Every part is useful; no redundancy. The structure front-loads the main function and ends with actionable next steps.

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 no output schema, the description adequately explains what is extracted (specific fields) and mentions abbreviation behavior. However, it does not specify the output format (e.g., JSON keys) or whether the full text is returned. Still, it provides sufficient context for basic usage.

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

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

The only parameter 'id' has a clear description in both schema and tool description. The description adds context: that the ID is a serial number from search_admin_appeals results, which is beyond the schema's description. With 100% schema coverage, baseline is 3, and the added context justifies a 4.

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 explicitly states the tool extracts administrative appeals adjudication text with specific fields (case name, adjudication agency, etc.). It distinguishes from sibling tools by mentioning search_admin_appeals and get_pipc_decision_text as alternatives for different use cases.

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

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

Provides clear when-to-use context (extracting adjudication details) and explicitly lists alternatives: search_admin_appeals for similar cases, get_pipc_decision_text for PIPC decisions. The phrase '다음: (next:)' offers direct usage guidance.

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

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

No annotations are provided, so the description must convey behavioral traits. It implies a read-only retrieval but does not explicitly state its safety, side effects, or access requirements. The description is adequate but lacks explicit disclosure of non-destructive 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 extremely concise with two sentences plus a note, no superfluous words. It front-loads the core purpose and immediately provides relevant usage details.

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

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

For a simple retrieval tool with no output schema, the description explains usage context and parameter correctly but does not describe the output format (text/structured) or any limits. Slightly incomplete for full agent 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?

The input schema fully describes the mst parameter (coverage 100%), and the description adds critical context: it explains the value's origin (search_admin_rule result) and warns against confusing it with a shorter admin rule ID, thus adding 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 retrieves the full text of administrative rules (행정규칙 본문 조회) and specifies the source (법제처 lawService · target=admrul). It distinguishes itself from siblings by referencing search_admin_rule for obtaining the required mst parameter and suggesting a subsequent tool for 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?

Explicitly instructs to use the mst from search_admin_rule results and warns that it differs from a shorter admin rule ID, preventing misuse. It also recommends next step compare_admin_rule_old_new, providing clear usage 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?

With no annotations, the description carries full behavioral burden. It discloses that the tool returns a list with annex serial number, related law ID, and PDF link, and notes that PDF text extraction is only available in v1.1. It does not mention side effects, authentication, or rate limits, but for a read-only list retrieval, this is adequate.

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 plus a short note on next steps. It is efficiently front-loaded with the main purpose and key details, using minimal words. It could be slightly more structured, but it is still 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 3 parameters, no output schema, and no annotations, the description provides sufficient context: it explains the tool's purpose, parameter usage, response fields (annex serial number, related law ID, PDF link), and suggests follow-up tools. It does not cover error handling or pagination, but for a straightforward list retrieval, it is 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?

Schema coverage is 100%, so baseline is 3. The description adds context for lawName (parent law) and explains the knd enum values (별표/서식/부칙별표/부칙서식/전체) beyond the schema's Korean names. However, it does not add significant new information beyond what is already in 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 retrieves a list of annexes and forms for a given law (법령 별표·서식 목록), including specific filtering by kind (별표/서식/부칙). It distinguishes itself from siblings like get_law_text (which retrieves the main text) and search_admin_rule (for administrative rules).

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

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

The description explains when to use this tool: for standard forms like processing policies and consent forms (처리방침·동의서 같은 표준양식이 별표·서식에 위치). It provides next steps (사용 get_law_text for context, search_admin_rule for administrative rule annexes), but does not explicitly state when not to use it.

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

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

No annotations provided, so description carries the burden. It explains default date range but lacks explicit read-only hint, auth requirements, or rate limits. Still, it provides useful 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?

Concise, front-loaded with purpose, then parameter details and usage tips. No unnecessary sentences or fluff.

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

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

No output schema, but description adequately covers function, parameters, and usage context. Could mention return format or pagination, but remains fairly complete for a history retrieval tool.

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

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

All 4 parameters are described in schema with 100% coverage, but description adds significant value: clarifies lawId vs mst, jo format flexibility and default, and date parameter defaults.

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 article change history for specific laws or articles over time, referencing the source and differentiating from sibling tools by mentioning next steps.

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

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

Provides explicit guidance on mandatory date range with default behavior, and suggests alternative tools (get_historical_law, compare_old_new) for specific follow-up actions.

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 fully disclose behavior. It mentions auto-summarization for long texts and the data source, but lacks details on auth requirements, rate limits, or safe read-only hint. Partial 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, with key info front-loaded: purpose, extracted fields, auto-summarization, and follow-up suggestions. Every sentence 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?

For a simple retrieval tool with one parameter and no output schema, the description covers what it returns, the ID source, and auto-summarization. Could mention formatting details but sufficient for typical use.

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

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

Only one parameter (id) with 100% schema coverage. The schema already explains the ID source. The description adds minor context (source, auto-summarization) but not essential beyond schema. 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 extracts the full text of constitutional decisions, including case name, number, summary, etc. It also distinguishes from sibling search tools via '다음: search_constitutional_decisions로 유사 사건, intelligent_law_search로 인용 조문 검색.' The verb 'get' matches the tool name.

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 contexts (when full text is needed, auto-summarization for long texts) and suggests next steps. However, it does not explicitly state when not to use this tool versus other get_ tools for different document types.

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 states the output is a flat list of mappings and implies a read-only operation, but it lacks details on authentication, rate limits, or the exact structure of the returned list. Basic behavioral transparency is present but not rich.

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

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

The description is concise at a few sentences, with the main purpose front-loaded. It includes an example and actionable next steps without unnecessary verbosity. Every sentence 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?

Given the lack of an output schema, the description explains the high-level return value (flat list of mappings) and provides an example count (59). However, it does not specify the exact fields in each mapping item, which would improve completeness. Nonetheless, for a simple tool, it is fairly 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?

The input schema has 100% description coverage for the single parameter lawId, and the description reinforces its meaning (from search_law, for delegated relations). The description adds context beyond the schema by relating it to the overall workflow, so it scores above 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 explicitly states that the tool returns delegated law relations (법령 위임조문 관계) as a flat list mapping articles of the main law to enforcement decree/rules. It specifies the source (법제처 lawService) and provides an example (PIPA with 59 delegated articles), clearly distinguishing it from siblings like get_law_text or get_three_tier.

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 by suggesting next steps (use get_law_text for text, get_three_tier for visualization) and gives an example usage scenario. However, it does not explicitly state when not to use this tool versus 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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It mentions the source (lawService, target=elaw) and text structure, but does not cover error handling, authentication, or data freshness. Adequate for a simple one-parameter retrieval tool, but could be more explicit.

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?

Three concise sentences that front-load the primary purpose and structure, with additional usage guidance and sibling references. 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?

Given the simplicity of the tool (one parameter, no output schema), the description provides sufficient context: source, structure, use cases, and related tools. It is complete for an agent to select and invoke correctly.

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

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

Schema description coverage is 100% for the single parameter mst. The tool description adds context by referencing its use with get_law_text, reinforcing the parameter's role. This adds marginal value beyond the schema definition.

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 that the tool retrieves English law text from the Ministry of Legislation lawService, with a specific structure (chapter/article). It distinguishes itself from siblings like get_law_text (Korean) and compare_articles (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?

The description explicitly suggests when to use this tool (GDPR comparison, overseas reports) and recommends alternatives for related tasks (get_law_text for Korean, compare_articles for comparison).

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 must convey behavioral traits. It clearly implies a read-only operation (retrieving text) and specifies the data source (lawService). While it doesn't explicitly state read-only or mention error handling, the purpose and usage are transparent enough 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—3 short sentences—yet delivers purpose, usage guidance, tips, and sibling references. 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 tool's simplicity (1 parameter, no output schema), the description fully covers what the tool does, how to use it, and its relationship to siblings. No additional information is needed for correct 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 single parameter 'mst' has a full description in the input schema, and the tool description adds critical context: it must come from get_law_history's result and represents a specific time point. This clarifies the parameter's role beyond the schema definition.

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 law text at a specific point in time ('특정 시점 법령 본문'). It distinguishes from siblings by referencing get_law_history (to obtain mst) and get_law_text (for current 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?

The description explicitly tells when to use this tool (after get_law_history for historical versions) and when not to (use get_law_text for current text). It provides a specific use case (frequently amended laws like PIPA) and directs to next step (get_law_history to check other msts).

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. It transparently explains AI-based semantic matching, absence of direct text matching, and output is list of article titles. Behavior is well-disclosed, though read-only nature could be more explicit.

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 three sentences: core purpose, sibling distinction, and follow-up action. Every sentence adds value, no redundancy or fluff. Ideal length for quick agent comprehension.

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, but description states return is list of article titles. Parameters are fully documented. Follow-up action provided. Missing details like pagination (though display parameter suggests limit), but overall sufficient for a simple recommendation 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% (all 3 parameters described). The description repeats schema info without adding significant new meaning beyond mentioning broader matching for query. Baseline 3 is appropriate as description doesn't substantially extend schema understanding.

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 returns AI-recommended related laws (조문 list) based on keyword semantic similarity. It distinguishes itself from sibling intelligent_law_search by noting broader matching, 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?

Description contrasts this tool with intelligent_law_search (broader matching) and advises follow-up with get_law_text(lawId) for full text. While it hints at when to use, it lacks explicit when-not-to-use instructions, resulting in good but not perfect 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, description carries full burden. It discloses that long reasons are automatically abbreviated ('긴 이유는 자동 축약') and extracts specific fields. This adds behavioral context beyond 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?

Description is concise, front-loads core purpose, and includes usage guidance and sibling references in a well-structured manner.

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, but description lists output components and mentions auto-summarization of long reasons. It provides sufficient context for effective use, though response format and error handling are not covered.

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 a clear parameter description. Tool description repeats the schema info but adds context that ID comes from search_interpretations results, which is helpful but not additional semantic depth.

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 the full text of statutory interpretation cases, listing specific components (subject, query, reply, reasons). It distinguishes from siblings by mentioning alternative tools like search_interpretations and get_law_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?

Provides explicit when-to-use scenario: 'when there is doubt about PIPA provision application, directly check official interpretations.' Also suggests alternatives: search_interpretations for similar cases and get_law_text for cited provisions.

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 fully discloses caching behavior (24-hour cache, bypassCache flag), server-side date filtering (stdDt/endDt), large response size (1.2MB+), and automatic domain abbreviation conversion. No contradictions exist.

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

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

The description is concise for its content, front-loading the purpose. It could be slightly more structured but every sentence 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?

Given no output schema, the description explains return values (bidirectional mapping) and covers all behavioral aspects (caching, filtering, domain aliases). The tool's complexity is well-addressed.

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?

Although schema coverage is 100% (baseline 3), the description adds significant meaning: stdDt/endDt filter on server side ignoring cache, bypassCache forces refresh, display is client-side truncation, and omitting query dumps items. This greatly aids parameter understanding.

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 a law abbreviation dictionary from the Ministry of Legislation, performing partial matching on queries. It distinguishes itself from siblings by mentioning domain-specific abbreviation handling (e.g., '정통망법' via PRIVACY_ALIASES) and bidirectional mapping between abbreviations and full names.

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 describes when to use this tool (for abbreviation lookups) and contrasts it with get_law_text(mst) for full text and search_law(query) for formal search. Examples are provided to illustrate 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 are provided, so the description fully carries the burden. It details the return fields (mst, promulgation date, effective date, amendment type) and target source, but does not mention authentication or rate limits. Given the read-only nature, this is sufficient.

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 at three sentences, front-loaded with core purpose, and every sentence 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?

Despite no output schema, the description clearly explains what is returned (mst, dates, amendment type) and provides usage context with sibling links, making it complete for a history-listing 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?

Input schema has 100% coverage; the description adds context: lawName supports exact match and abbreviations, display default 100 is adequate for all history. This adds meaning beyond the schema definitions.

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 returns a list of law enactment history by effective date, including current, history, and upcoming versions. It distinguishes from siblings by explicitly mentioning get_historical_law and compare_old_new for next steps.

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

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

The description provides explicit when-to-use guidance (e.g., tracking frequent amendments like PIPA) and recommends subsequent tools (get_historical_law for specific text, compare_old_new for comparison), making it clear when not to use this tool.

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

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

With no annotations, the description carries full behavioral burden. It discloses endpoint sharing with a sibling and specifies the output format (indented tree of statute hierarchy). While it doesn't detail all edge cases (e.g., depth limits), it sufficiently explains the tool's behavior for an AI agent.

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 plus a follow-up pointer) and front-loads the core purpose and hierarchy levels. Every sentence adds value, with no redundancy. Ideal length for quick comprehension.

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 no output schema, the description clearly explains the tree output's structure (hierarchy levels). It mentions endpoint sharing and provides next-step references, making the tool's context fully understandable for an AI agent to decide when and how to invoke it.

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 value by indicating both parameters come from search_law results, providing origin context beyond the schema. This extra context justifies a score above the baseline 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 explicitly states the tool visualizes a hierarchy (법령 체계도) as a tree (트리 시각화), listing the layers from 법률 to 행정규칙. It also distinguishes itself from the sibling get_related_laws by noting the shared endpoint but different output format (tree vs. flat list), making the purpose very 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 explicitly contrasts with get_related_laws: tree for hierarchy understanding vs. flat list for search/discovery. It also suggests follow-up tools (get_law_text, get_delegated_laws), providing clear when-to-use 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?

Discloses truncation limit of 12,000 characters and use of efYd for time-specific versions. No annotations provided, so burden is on description; it could mention error cases or response format but is otherwise transparent.

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?

Concise three sentences, front-loaded main purpose, then behavioral details and usage guidance. 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?

No output schema, so description must compensate. It notes results are sorted by article (조문 단위로 정렬됨) and mentions truncation. Could be more detailed on return structure, but is sufficient for 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 baseline is 3. Description adds value by explaining mutual exclusivity of mst and lawId (택1) and clarifying efYd's role for versioned queries, going 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 it retrieves the full text of a law using mst or lawId, returned sorted by article. It distinguishes from sibling tools like get_law_article for specific articles, and mentions related tools for history and relationships.

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?

Explicitly says when to use this tool (for full law text) and when not (for large laws truncated at 12,000 characters, recommending get_law_article for specific articles). Also suggests next steps: get_related_laws and get_law_history.

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 the output includes article ranges and counts, and that it extracts from law JSON with a specific header. However, it does not mention auth requirements, rate limits, or potential size limitations for large trees. Minor omission but overall transparent.

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: a few sentences each serving a purpose. It front-loads the core function, then differentiates from siblings, and ends with usage suggestions. No redundant or 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?

Given no output schema, the description adequately describes the output (structure with article ranges and count). It explains all three parameters, provides a concrete use case, and references related tools. It is complete for a tree/toc 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 coverage is 100% with descriptions, so baseline is 3. The description adds value by clarifying that mst and lawId are alternatives (택1) and efYd is for time-point queries. This extra context justifies a 4.

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 the internal table of contents (편·장·절·관) of a law, including article ranges and counts. It distinguishes itself from get_law_text (full text) and get_law_system_tree (hierarchy of laws), 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.

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

The description explicitly says when to use this tool: for navigating large laws like PIPA to quickly decide which chapter/section to examine. It also tells when not to use it (for full text or system hierarchy) and suggests follow-up tools (get_law_text, compare_articles). This is exceptional 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?

No annotations provided, so description bears full burden. It discloses multiple API calls (lawSearch and lawService), behavior for multiple definitions, and effect of withDefinitions=false. Lacks explicit statement on safety or permissions.

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?

Concise and well-structured with a clear example and follow-up reference. Every sentence 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?

Given schema coverage and lack of output schema, description is complete. It explains integration, behavior for multiple definitions, and provides an example.

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%, and description adds context: explains each parameter's purpose, especially withDefinitions and display. Provides examples and clarifies behavior 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 searches legal terms and integrates definitions from lawService. It distinguishes from sibling tools by specifying that get_term_articles is for tracking articles using the term.

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?

Explicitly tells when to use this tool vs alternatives: '다음: get_term_articles(용어ID)로 해당 용어 사용 조문 추적.' Also clarifies the role of the withDefinitions parameter to toggle definition fetching.

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 discloses that the list is a direct copy from PIPC portal (not curated by us) and that source URL is automatically attached for verification. This covers behavioral aspects like origin and verifiability. Could be improved by noting read-only nature more explicitly.

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 detailed but each sentence adds value. It front-loads the main purpose and then adds nuances. Could be slightly shortened by merging some lines, but overall effective 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?

For a simple list retrieval tool with one parameter and no output schema, the description is comprehensive. It covers what the tool returns, its origin, its relationship to other tools, and usage sequence. No critical gaps remain.

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

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

The sole parameter 'category' is fully described in the schema with enum values and defaults. The description adds context by mapping enum values to actual counts (12 laws, 23 rules) and explaining what 'all' includes. This supplements schema meaningfully.

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 returns PIPC's official curated list of 12 laws and 23 administrative rules, distinguishes it from sectoral guides, and positions it as the entry point for PIPA domain. It also mentions the source URL attachment and relationship with 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?

Explicitly advises use as first entry into PIPA domain, contrasts with sectoral guides, and suggests subsequent tools (search_law, search_admin_rule, get_sectoral_related_laws) for deeper exploration. Provides clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: extraction of structured fields, auto-extraction of annex links, and automatic summarization of long text. It does not mention side effects or authentication requirements, but the disclosed behaviors are sufficient for safe use.

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: three sentences, front-loaded with the primary purpose, followed by details on extracted fields and usage guidance. Every sentence is informative with no redundancy.

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

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

The description covers the tool's purpose, return types (structured fields), input source, and related tools. Although there is no output schema, the description compensates by listing expected fields. It is complete enough for a single-parameter tool.

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

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

The input schema has 100% coverage with a clear description for the 'id' parameter. The main description adds value by stating that the id comes from search_pipc_decisions results, providing crucial context 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 retrieves full PIPC decision text from the legal service, extracts structured fields like case name, summary, order, reasoning, and background, and automatically extracts annex links. It distinguishes from sibling tools like search_pipc_decisions (for searching) and get_law_text (for laws).

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

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

The description explicitly tells when to use this tool: after searching with search_pipc_decisions to get detailed text, and for comparing with law text via get_law_text. It provides a clear next-step context, effectively guiding the agent on tool selection.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It accurately describes the return of hierarchical relationships and mapping sources (PIPC combined laws plus ministry mapping). No mention of destructive or auth requirements, which is acceptable for a read-only query.

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

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

The description is concise and front-loaded with the main action in parentheses. Every sentence adds unique value: target service, hierarchy details, data sources, parameter advice, and follow-up steps. 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 no output schema, the description adequately explains what is returned (hierarchy and related laws) and includes context about data sources. It covers the main behavioral aspects for a 2-parameter tool, though the exact return structure could be more concrete.

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 fully describes both parameters with origins from search_law results (100% coverage). The description only adds reinforcement that mst is recommended and one parameter is needed, providing minimal additional semantic 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 queries related laws and subordinate administrative rules with a specific target (lsStmd) and returns hierarchical relationships. However, it does not explicitly differentiate from sibling tools like get_delegated_laws or get_intelligent_related_laws, 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?

The description recommends using mst parameter and provides next-step tools (get_law_text, search_admin_rule) for text retrieval, implying this tool is for structure. But it lacks explicit guidance on when to use versus alternatives or 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?

With no annotations, the description fully discloses behavior: it indexes PIPC guides as-is (curation 0), splits official vs additional mentions, attaches sources for verification, normalizes aliases, and notes it is a starting point. This provides comprehensive 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 somewhat lengthy but each sentence adds value and is front-loaded with purpose. Minor redundancy could be trimmed, but overall 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 has only two simple parameters and no output schema, the description fully covers output composition (official vs additional), source attribution, and limitations. It is complete 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%, so baseline is 3. The description adds value by explaining default behavior (list sectors if unspecified), alias normalization, and the effect of include_additional, going 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 it is a lookup tool for PIPC sectoral related laws, specifying 8 sectors and detailing what it returns (official laws, additional mentions). It distinguishes from siblings by naming alternative tools for unlisted sectors or cross-domain queries.

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

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

The description explicitly says when to use this tool (as a starting point for sectoral mappings) and when not (for sectors not listed or cross-domain), directing to siblings like search_law, intelligent_law_search, get_pipc_curated_corpus.

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 discloses that results are grouped by matching term groups, homonyms are separated, no pagination is available, and results are truncated by maxArticles. It also gives an example (개인정보 → ~700 articles). However, it does not explicitly state that the operation is read-only or mention authentication/permission requirements, which would be helpful.

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

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

The description is concise and front-loaded with the core purpose. Every sentence adds value: purpose, grouping logic, homonym handling, pagination behavior, next steps. No redundant or unclear phrases.

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, the description explains the return type (list of articles grouped by term) and mentions the body preview behavior (200 chars if includeBody true). It provides sufficient context for the agent to understand the output format. Could be improved by explicitly listing the response fields (e.g., lawId, article number), but overall it is complete enough.

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 context beyond the schema by explaining the purpose of maxArticles (truncation) and providing an example query (개인정보). The example illustrates how the tool behaves with a real term, adding semantic 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 tracks articles using specific legal terms, returns a list grouped by term, and distinguishes from sibling tools like 'get_legal_term' (definitions) and 'get_law_text' (full law text). It uses specific verbs and resources: '법령용어가 사용된 조문 추적' and '매칭 용어 그룹별로 ... 조문 목록 반환'.

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

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

The description explicitly tells when to use the tool (when you have a legal term keyword and need all articles containing it), what not to expect (no pagination, truncation by maxArticles), and provides follow-up tool recommendations ('다음: get_law_text ...' and 'get_legal_term').

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 responsibility. It describes the comparison operation but does not explicitly state that it is read-only or non-destructive. While the nature of the tool implies a safe query, transparency could be improved by stating that it does not modify any 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 concise, using four sentences to cover purpose, parameters, an example, and follow-up tools. It is front-loaded with the main objective. A slight improvement could be breaking into bullet points for readability, but overall 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?

No output schema is provided, and the description does not specify the return format or structure of the comparison results. While the example implies what the output looks like, explicit details (e.g., whether it's a list of mappings, fields returned) are missing, which reduces completeness for a simple tool with two parameters.

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 both parameters with descriptions. The description adds context: mst must be the '본법 mst' from search_law/get_law_history, and knd values are explained with their meanings. This enhances understanding beyond the schema alone.

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: comparing three-tier delegation and citation relationships among Korean law, enforcement decree, and enforcement regulation. It specifies the data source (lawService, target=thdCmp) and provides concrete examples like PIPA §29 to 시행령 §30. The tool is distinct from siblings as no other tool explicitly offers this three-tier 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?

The description explains the two modes (knd=1 for citation, knd=2 for delegation) with default behavior. It gives a real-world example (PIPA safety measures) and suggests subsequent steps using get_law_text and get_admin_rule_text. This provides clear guidance on when to use this tool and what to do next.

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?

Discloses semantic search behavior and domain selection via search parameter. No annotations provided, but description covers primary behavioral traits for a non-destructive search tool. Lacks mention of rate limits or result set metadata.

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?

Concise, front-loaded with purpose, uses bullet-point clarity. Every sentence adds useful context 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?

Explains overall workflow (search then retrieve full text). Does not describe pagination parameters (display, page) in description, but schema covers them adequately. No output schema, but return format is implied.

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?

Adds value beyond schema by explaining search parameter domain options and giving natural language query examples. Schema already provides good descriptions for all 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?

Clearly states it's an intelligent semantic search on clause text, distinguishes from sibling search_law that only matches law names. Provides example keywords and target agency.

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?

Explicitly contrasts with search_law (law name matching) and recommends get_law_text(mst) for full text retrieval after searching. Gives clear when-to-use guidance.

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

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention read-only nature, rate limits, authentication needs, or any side effects. The description only describes the tool's function without 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 two sentences with relevant details, but it includes a parenthetical reference to an internal code (W2.5) that may not be clear to all users. It is relatively concise but 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?

For a search tool with three parameters and no output schema, the description covers the domain and usage context. It mentions follow-up tool and example keywords. However, it lacks information about pagination, result format, or any limitations, which would be useful for 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 each parameter has a description in the schema. The tool description adds example keywords and context (e.g., PIPA violations) but does not significantly enhance understanding beyond the schema's parameter descriptions. The examples are helpful but not critical.

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

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

The description clearly identifies the tool as a search for administrative appeal precedents (행정심판 재결례 검색) from a specific source (법제처 lawSearch · target=decc). It distinguishes itself from the sibling tool get_admin_appeal_text by indicating that tool retrieves the full text. The verb '검색' and the resource are specific.

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 recommends using get_admin_appeal_text for full text after searching, providing a clear workflow. It also gives context about the types of cases covered (PIPA violations, administrative dispositions). However, it does not specify when not to use this tool compared to other search tools like search_admin_rule.

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 describes the action (search metadata) but does not disclose any behavioral traits such as rate limits, authentication needs, or side effects. The description is adequate for a read-only search 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: two sentences plus a usage pointer. It is front-loaded with the main purpose and efficiently includes key context and next steps without 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?

The description covers the tool's purpose, scope, and typical use cases, and it points to subsequent tools. However, since there is no output schema, the description does not detail the metadata fields returned, which is a minor gap for completeness.

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

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

Schema description coverage is 100%, and the description adds the same context as the schema (e.g., PIPC and ministry instructions). It does not provide additional meaning beyond what is already in the schema, so no extra value is added.

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

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

The description clearly states the tool searches administrative rules (행정규칙 검색), specifies the target (lawSearch, target=admrul), and lists types (고시·훈령·예규). It distinguishes from siblings by noting that this tool retrieves metadata, while get_admin_rule_text and compare_admin_rule_old_new handle text and comparisons.

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 the agent to next tools (get_admin_rule_text and compare_admin_rule_old_new) after using this one, providing a clear workflow. However, it does not explicitly state when not to use this tool or alternatives among the many sibling search tools.

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

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

No annotations are provided, so the description carries full responsibility. It mentions the target (detc) and metadata nature of results, but does not disclose behavioral traits such as rate limits, authentication, or error handling. The description gives a general sense but lacks depth.

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 plus a referral, all front-loaded with core purpose. Every sentence adds necessary information without redundancy. It is highly 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?

While the description states results are metadata about decisions (위헌·합헌·각하 등), it does not specify the exact fields or structure returned. With no output schema, more detail on return format would improve completeness. Pagination info is covered by schema but not description.

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% (baseline 3). The description adds value by explaining the query parameter with example keywords ('개인정보 자기결정권', '주민등록번호') and hinting at matching logic (사건명·사건번호 매칭). This enriches the schema's basic descriptions.

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

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

The description clearly states the tool searches for constitutional court decisions (헌법재판소 결정례) with specific types (위헌·합헌·각하) and provides an example case (99헌마513). It also distinguishes from the sibling tool get_constitutional_decision_text by directing users to retrieve full text after searching.

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

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

The description explicitly suggests using get_constitutional_decision_text for full text after searching, providing a clear workflow. However, it does not specify when to use this tool over other search tools (e.g., search_law, search_interpretations) or state exclusions, which slightly limits 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?

No annotations are provided, so the description carries full burden. It reveals the target source (elaw) and suggests read-only behavior by describing it as a search tool, but does not explicitly state it is non-destructive, rate limits, or auth requirements. The description is adequate but could be more transparent about 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 concise (3 sentences) and front-loaded with the core purpose. Some internal codes (W2.7, v2) may be cryptic, but overall information density is high without unnecessary fluff.

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

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

Given no output schema, the description adequately covers usage context and next steps. It does not describe output format, but for a search tool that returns a list, this is acceptable. The description is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with clear descriptions. The description adds value by explaining query matching behavior (accepts English and Korean names with examples). This extra context justifies a score above the baseline 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 specifies the tool's purpose: searching English versions of Korean statutes (영문 법령 검색) with targets like PIPA. It distinguishes itself by mentioning specific use cases (GDPR comparison, overseas reports) and directing to subsequent tools (get_english_law_text, compare_articles), differentiating it from sibling tools like search_law (Korean text) or compare_articles (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?

The description provides context for when to use the tool (searching English law translations for tasks like PIPA research or GDPR comparison) and mentions alternative workflows (use get_english_law_text for full text, compare_articles for PIPA↔GDPR comparison). It lacks explicit 'when not to use' guidance, but the context is strong.

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 inform about behavioral traits. It clarifies that the tool returns metadata of official decisions (not full text) and points to a follow-up tool. However, it does not disclose any limits, authentication needs, or the nature of the response format, which would be helpful 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.

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

The description is very concise: two sentence fragments and a follow-up suggestion. Every part is essential, with no redundant information. It front-loads the tool's core purpose and efficiently guides 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 that there is no output schema, the description should ideally specify what fields are returned in the results. It only mentions '메타' (metadata), which is vague. While it hints at the utility, it could be more complete by listing typical result fields like case number, title, date, etc.

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?

Although the input schema covers all parameters with descriptions, the tool description adds valuable context by specifying that the query matches against subject name, case number, inquiry agency, and reply agency. This goes beyond the schema's basic description of 'keyword' and enhances understanding.

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 that this tool searches for statutory interpretation cases from the Ministry of Government Legislation, specifying the resource (법제처 lawSearch, target=expc) and content (official reply metadata). It distinguishes from sibling search tools like search_law or search_admin_appeals by mentioning PIPA and enforcement ordinance application cases, and points to the follow-up tool get_interpretation_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?

The description explicitly states when to use the tool: 'when in doubt about the interpretation of provisions' and directs users to get_interpretation_text for the full text. It does not explicitly exclude other scenarios, but the context is clear enough for 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 are provided, so the description carries full burden. It describes the search functionality and abbreviation recognition, but does not disclose behavioral traits like rate limits, authentication, or side effects. The quirk about short law names is mentioned in the display parameter, but overall transparency is moderate.

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 purpose and efficiency. Every sentence adds value, and no extraneous information is present.

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

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

For a search tool with 4 fully documented parameters and no output schema, the description explains what the search returns (law names, metadata) and mentions abbreviation recognition. It is fairly complete, though a bit more detail on return format could 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 description coverage is 100%. The description adds value by explaining abbreviation recognition in both main description and query parameter. The display parameter includes a note about a quirk with short law names, which goes 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 '법령 검색' (law search) with specific verb+resource, and distinguishes from siblings by pointing to get_law_text and get_related_laws for further steps. It also mentions abbreviation recognition and scope prioritization.

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 indicates when to use this tool (searching laws) and provides next steps (get_law_text, get_related_laws). It implicitly contrasts with siblings but does not explicitly state when not to use this tool.

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

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

No annotations provided, so description should compensate. It states 'all decisions' but doesn't mention authentication, rate limits, or read-only nature. Minimal behavioral disclosure.

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 concise, front-loaded with purpose, and efficiently covers types, domain core, and next tool 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?

No output schema, but description covers what data is accessible (위반 사례, 과징금, 시정조치). Could mention pagination, but not essential given schema parameters. Adequate for search tool.

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

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

All 3 parameters have schema descriptions (100% coverage). Description adds example keywords but doesn't significantly extend beyond schema. 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?

Description clearly states the tool searches PIPC decisions, lists specific types (심의·의결, 침해요인 평가, 분쟁조정), and distinguishes from sibling tool get_pipc_decision_text by mentioning full text retrieval as next step.

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?

Description indicates use case (direct check of violations, fines, corrective orders) and suggests follow-up tool. However, no explicit when-not or comparison with sibling search tools like search_privacy_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?

With no annotations, the description carries full burden. It discloses the data source, number of cases, retrieval method (BM25 with contextual retrieval), auto-attribution, and differentiator from other APIs. It falls short of mentioning pagination behavior 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?

The description is information-dense without being verbose, covering core function, filters, differentiator, example, attribution, and sibling tool references in a logical order. Minor redundancy could be trimmed but overall 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 7 parameters, no annotations, and no output schema, the description adequately explains the tool's operation, filtering capabilities, and output characteristic (attribution). It lacks description of result format but provides sufficient context for correct invocation.

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

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

Schema coverage is 100%, baseline 3. The description adds value by explaining the tree filter structure, year range narrowing, and providing an example that illustrates parameter interaction, going beyond the schema definitions.

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 BM25 search on PIPC privacy.go.kr counseling cases and explicitly contrasts with sibling tools search_privacy_guides and search_pipc_decisions, making the purpose and differentiation unmistakable.

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

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

It provides explicit guidance on when to use this tool versus alternatives, stating to use search_privacy_guides for official guides and search_pipc_decisions for violation decisions. It also gives a concrete example query.

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 discloses the retrieval method (BM25, Contextual Retrieval), corpus size, source_type behavior, and automatic PIPC attribution with license. It does not detail response structure or rate limits, but the key behavioral traits for an agent selecting the tool are covered.

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 dense and somewhat long, but every sentence carries distinct information: corpus composition, differentiation, usage guidance, parameter capability, attribution, and sibling routing. The most important purpose and differentiator are front-loaded, making it easy for an agent to scan.

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

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

For a retrieval tool with no output schema, the description covers the corpus scope, retrieval technique, attribution behavior, and routing to alternatives. It does not explicitly describe the return shape beyond attribution, but it gives enough context for an agent to decide whether and how to invoke it.

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 value beyond the schema by explaining that source_type can split guide/case searches and by characterizing the query domain as PIPC practical materials. It reinforces the query examples in the schema without duplicating them.

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 names a specific verb (integrated BM25 search) and a precise resource (PIPC official guides + privacy.go.kr consultation cases, 2,699 chunks). It distinguishes itself from sibling tools by stating it covers PIPC practical materials that the law-API lacks, and explicitly routes narrower searches to search_privacy_cases/search_privacy_guides and law text to search_law/get_law_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?

Explicit guidance: 'LLM 첫 진입에 가장 자연스러운 도구' tells the agent when to start here, and the closing sentence names the exact alternatives for narrower searches and statutory text. It also mentions source_type filtering as a way to split guide vs. case searches, giving concrete usage direction.

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 available, the description carries the full transparency burden. It discloses the retrieval algorithm (BM25 + Contextual Retrieval), corpus scale (954 chunks), the meaning of each doc_type, and automatic attachment of PIPC attribution and page information under the pipc-attribution license. It does not describe result format or failure/limit behaviors, but for a read-only search tool this is strong disclosure.

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 long but densely structured and front-loaded, leading with the core purpose in the first sentence. It packs doc_type details into readable parenthetical lists and uses routing at the end. Some content repeats the schema's own parameter descriptions, but the description adds dates and detailed content breakdowns not present there.

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 3 parameters, no annotations, and no output schema, the description covers corpus provenance, content per doc_type, licensing, and sibling routing. It could additionally describe the shape of returned results or edge cases, but the essentials for correct selection and invocation are present, and attribution behavior is disclosed.

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 baseline is 3. The description adds substantial semantic value beyond the schema by explaining what each doc_type refers to, down to document dates, chunk counts, and contents (e.g., pseudonym's main/separate volumes, sectoral's 8 subfields). Query and display parameters receive less added meaning beyond the schema's examples, but doc_type is the high-complexity parameter and is richly annotated.

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

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

The description opens with a specific verb and resource: 'PIPC 공식 가이드 7종 BM25 검색 (Contextual Retrieval, 총 954청크)' – a BM25 search over 7 official PIPC guides. It also distinguishes itself from siblings by stating the differentiating value ('법제처 API가 못 가진 PIPC 실무 안내가 차별화') and pointing to alternative tools for nearby tasks.

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

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

It provides explicit routing guidance: '다음: search_privacy_cases로 실제 상담 사례, search_law로 관련 법조문', telling the agent when to use sibling tools instead. It also clarifies this tool's unique scope as PIPC practical guidance not covered by the Ministry of Government Legislation API, giving clear selection context, though not exhaustively covering every sibling search tool.

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

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

With no annotations provided (0% coverage), the description fully bears the burden of disclosing behavior. It details the stepwise verification process (4-tier check), special features (as_of temporal verification, alias normalization), and output markers ([HALLUCINATION_DETECTED]). It also mentions providing accurate evidence and next-tool guidance. This is comprehensive and transparent.

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 relatively short but dense with information. It is structured as a single coherent paragraph with clear logical flow (purpose, method, features, output, next steps). It avoids unnecessary words and front-loads the key points. Slightly more structure (e.g., bullet points) could improve readability, but it is already 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 absence of an output schema, the description adequately explains what the tool does, how it works, and what it returns (hallucination markers, evidence, next-step suggestions). It also connects to sibling tools for follow-up actions. The complexity of verifying legal citations is well-covered, and the description leaves minimal gaps for a typical use case.

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 (citation and as_of) are described in the schema (100% coverage), and the description adds valuable context: examples of accepted citation formats for 'citation' (e.g., 'PIPA §15 ① 6호', '개인정보 보호법 제15조제1항제6호'), automatic alias normalization, and an explicit example for 'as_of' ('20190601'). This goes beyond the schema's basic 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 explicitly states the tool's purpose: to verify legal citations against an actual law API to detect hallucinations. It specifies the four-tier hierarchy (law, article, paragraph, subparagraph) and gives concrete examples like 'PIPA §15 ① 6호'. This clearly distinguishes it from sibling tools like search_law or get_law_text, which are for different purposes.

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

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

The description provides clear guidance on when to use the tool: to verify citations and detect hallucinations. It also includes next-step recommendations (search_law for full name, get_law_text for text), but does not explicitly state when not to use it compared to other tools like compare_articles or search_pipc_decisions. However, the context makes the intended usage fairly clear.

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