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

With no annotations provided, the description carries the behavioral burden. It discloses that the tool returns candidate/status information rather than a final decision, which is useful. However, it says nothing about the refresh parameter's caching behavior, side effects, or any operational characteristics such as data freshness.

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 entire description is one tight Korean sentence with no filler. The main return value is stated first and the important non-confirmation caveat follows immediately, so it is both concise and appropriately 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 five parameters, zero schema coverage, no annotations, and a sibling set of legal-research tools, this description is too sparse for confident selection and correct invocation. An agent could call it minimally with only effective_on, but it has no guidance on the optional filters, refresh semantics, or how it relates to sibling tools.

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

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

Schema description coverage is 0%, yet the description only reinforces that effective_on is the date anchor. The remaining parameters (mst, law_id, refresh, document_id) are completely unexplained, leaving the agent unable to determine their roles from the 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 uses a specific verb ('반환' - returns) and a clear resource: statutory candidates and supplementary-provision confirmation status based on an effective date. It also explicitly disclaims final transaction application, which differentiates it from verification/decision tools like verify_legal_citations.

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

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

The description clearly implies this tool is for checking candidate laws as of a given effective date and explicitly states it does not confirm transaction application. However, it does not name sibling alternatives or provide explicit when-to-use versus when-not-to-use guidance beyond that caveat.

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 of behavioral disclosure. It does reveal a read-like retrieval action and cursor-based pagination, but it omits critical behavioral context such as refresh semantics, what 'stored vs official' implies, rate limits, authentication requirements, or side effects of parameters like attachment or response_type.

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

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

The description is one short, front-loaded sentence with no wasted words, which is good for conciseness. However, it leans toward under-specification rather than efficient completeness, leaving a lot of operational detail absent.

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

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

Even though an output schema exists, this is a complex 13-parameter legal document retrieval tool with zero annotations and zero schema parameter descriptions. The single-sentence description is far from sufficient for an agent to know how to construct a correct call or interpret edge cases.

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

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

The schema has 13 parameters with 0% description coverage, so the description must compensate but barely does. The only hint is '절 단위 cursor', which loosely maps to section_cursor, while target, article, refresh, provider, document_id, effective_on, response_type, identifier_kind, source_category, and source_document_id remain completely unexplained.

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 uses a specific verb ('조회한다' / retrieves) and names a concrete resource: stored documents or official full texts. It also adds the distinguishing mechanism of section-unit cursor pagination, which is enough to separate it from the sibling search/verification tools, though it never explicitly contrasts them.

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?

There is no guidance on when to use this tool versus alternatives such as search_legal_sources, get_applicable_law, or verify_legal_citations. The description states what the tool does but provides no context about intended scenarios, exclusions, or prerequisites.

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 behavioral burden and does disclose two non-obvious behaviors: results are restricted to the current authenticated principal/organization and the response is paginated via cursor. This is meaningful transparency, although it stops short of specifying ordering, empty-result behavior, or explicit read-only confirmation beyond the verb '조회한다'.

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

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

The description is one compact sentence that front-loads the resource and scope and ends with the pagination mode. Every phrase earns its place, with no filler or redundancy.

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

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

For a 3-parameter read tool with an output schema, the description covers scope and pagination well, but leaves room around when to use this over related tools and what limit means. It is minimally sufficient but not fully self-contained.

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

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

Schema description coverage is 0%, so the description must compensate, but it only mentions cursor pagination and never defines report_id, limit, or cursor as parameters. The agent must rely on parameter names, types, and defaults alone, leaving the semantics of limit and the relationship between report_id and cursor unclear.

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

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

The description states a specific lookup action ('조회한다') targeting '조사 보고서와 근거' (research report and evidence), scoped to the currently authenticated principal/organization. It clearly identifies the resource and operation, though it does not explicitly differentiate from sibling tools such as research_tax_issue or search_knowledge.

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

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

The phrase '현재 인증 주체·조직 범위의' provides a clear access scope that implies when the tool is applicable. However, there is no explicit when-to-use/when-not-to-use guidance or mention of a preferred sibling alternative, so usage must be inferred from the scope wording.

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 behavioral disclosure. It clearly indicates a read-only operation ('returns status') but does not disclose whether the status is cached, live, or what 'implementation, activation, validation' concretely entail. It is not misleading, but it adds only minimal behavioral context beyond the plain meaning of the tool name.

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

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

A single, well-formed sentence that front-loads the action and resource and packs the key status dimensions into a compact list. There is no wasted text or redundant repetition of the tool name.

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 zero-parameter, read-only status tool with an output schema, the description is largely sufficient. It identifies what is returned and from which sources. It could mention when to use it relative to the legal-research siblings, but the low complexity and existing output schema keep the gap small.

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

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

The tool has zero parameters, so the schema fully documents the input surface. Per the baseline for 0-parameter tools, the description does not need to compensate for undocumented parameters. The description adds semantic context about what the status represents, which is welcome but not necessary.

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

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

The description states a specific verb ('반환한다' / returns) and a clear resource ('공식 출처와 로컬 저장소' / official sources and local repository), with the exact aspects covered ('구현·활성화·검증 상태'). It does not explicitly contrast itself with sibling tools, but the status-focused purpose is distinct enough from the search/retrieve siblings.

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

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

The description gives no guidance on when to call this tool versus searching knowledge bases, retrieving legal documents, or verifying citations. There are no exclusions, prerequisites, or alternative-tool hints. For a zero-parameter status tool this is a moderate gap, but it still leaves the caller to infer the appropriate 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 provided, the description carries the full burden. It discloses a key behavioral trait: the tool follows a deterministic research plan and does not automatically finalize tax conclusions. However, it does not disclose what the output contains, whether it invokes other tools, whether it can fail, or any side effects. The disclosure is useful but incomplete for a research tool with no annotation support.

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

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

The description is a single, compact sentence that front-loads the core purpose and includes a meaningful behavioral caveat. It is efficient and readable, though it could be slightly more structured by separating the caveat into its own sentence for clarity.

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

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

The tool has 9 parameters, no annotations, and an output schema, but the description does not explain the research workflow, how parameters interact, or what the output represents. The 'does not auto-conclude' hint is valuable but leaves the agent uncertain about what the tool actually returns and how to interpret the result. For a complex research tool, this is a significant gap.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not explain any of the 9 parameters. The description mentions 'official sources' and 'tax conclusions' but does not clarify what 'issue', 'tax_type', 'jurisdiction', 'research_as_of', or 'upstream' mean semantically. The agent must infer parameter meaning entirely from names and defaults, which is risky for a complex research tool.

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

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

The description states a specific verb ('research') and resource ('tax issue'), and adds meaningful qualifiers: it collects and verifies official sources with a deterministic research plan, and explicitly does not auto-confirm tax conclusions. This distinguishes it from sibling tools like search_knowledge or get_applicable_law, though it doesn't name them explicitly.

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

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

The description implies this is the tool to use when a structured, evidence-based tax research process is needed, and the 'does not auto-conclude' phrase hints it is a research step rather than a final answer. However, it does not explicitly state when to use this tool versus siblings like search_legal_sources or get_research_report, nor does it mention prerequisites or exclusions.

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

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

Without annotations, the description carries the burden of behavioral disclosure. It explicitly states read-only ('읽기 전용') and that approval status is not changed ('승인 상태는 변경하지 않는다'), which are valuable non-mutating guarantees. It does not cover return format or auth, but with output schema present, those are less critical.

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

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

A single, tightly written sentence that front-loads the essential purpose and adds a safety-critical non-mutation clause, with no wasted words.

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

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

The description covers the core purpose and non-mutating nature, and the output schema takes care of return values. However, parameter semantics are not explained and usage guidance is implicit, leaving some ambiguity around k_ar_id and search behavior for an agent.

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

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

Schema description coverage is 0%, and the description adds no direct detail about 'query', 'limit', or 'k_ar_id'. The names are somewhat self-explanatory, and the K-AR knowledge context implies k_ar_id relates to knowledge records, but the description does not compensate for the missing schema descriptions.

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

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

The description states a specific verb ('검색' - search) and resource ('기존 K-AR 지식' - existing K-AR knowledge), making the core purpose clear. However, it does not explicitly differentiate from the sibling tool search_legal_sources, though the K-AR knowledge scope hints at internal knowledge versus legal sources.

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

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

The phrase '기존 K-AR 지식' implies this tool is for searching existing internal knowledge, which gives some guidance on when to use it. No explicit when-to-use or when-not-to-use guidance is provided, nor are any alternatives mentioned.

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

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

With no annotations, the description carries the behavioral burden and does disclose a meaningful distinction: searching the local index versus explicitly querying the official API. It also implies a read-only operation, but it does not address official API rate limits, authentication, or consequences of upstream calls.

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

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

The description is a single front-loaded Korean sentence with no filler or repetition. However, it is so brief that it under-serves the complexity of 11 parameters, so it earns strong concision credit rather than maximum completeness.

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?

A complex search tool with 11 parameters, no annotations, and no parameter descriptions needs much more context than this one sentence provides. The output schema may clarify return shape, but invocation behavior, mode selection, and optional-filter semantics remain largely unexplained.

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

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

The schema has 11 parameters with 0% schema description coverage, and the description only hints at the local/upstream provider distinction. The description does not explain query, filters, cursor, target, jurisdiction, document_type, or response_type, leaving the agent to guess their semantics.

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

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

The description identifies a clear action (검색/조회) and concrete resources: the local legal index and the official Ministry of Government Legislation API. It distinguishes this tool from legal-document retrieval or tax research, though the dual 'local or upstream' phrasing leaves some ambiguity about the default mode.

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 two usage modes but gives no criteria for choosing between the local index and the official API, and it never mentions when to prefer this tool over siblings such as search_knowledge or get_legal_document. No exclusions, prerequisites, or alternative routing are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, whether it makes external calls, what it returns on success or failure, or any side effects. The phrase 'verifies' implies a read/check action, but that is not explicit. This is a significant gap for a tool with zero annotation coverage.

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

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

The description is a single short sentence, which is concise and front-loaded. However, it is so brief that it sacrifices necessary detail. It earns a middle score: not verbose, but under-specified for a tool with a verification purpose and multiple inputs.

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

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

Given the tool's complexity (verifying multiple aspects of citations) and the absence of annotations or output schema details, the description is incomplete. It does not explain what the verification returns, how results are structured, or what constitutes a successful verification. The output schema exists but its content is not described, so the description should compensate – it does not. An agent would be under-equipped to call this tool correctly and interpret results.

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

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

Schema description coverage is 0%, so the description must compensate for the parameters. It mentions 'document, metadata, location, and quote' which loosely map to document_id, expected_date/provider (metadata), locator (location), and quote, but it does not explain the meaning of each parameter or how they interact. An agent would need to infer the role of each parameter from the names alone, which is insufficient given the verification context.

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

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

The description states it 'separately verifies document, metadata, location, and quote consistency' – a specific action (verify) on a defined scope (consistency of four elements). It is not a tautology and gives a reasonable sense of purpose, but it does not clearly differentiate from siblings like search_legal_sources or get_legal_document. It could be more specific about the verification result and the exact process.

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?

There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, typical scenarios, or exclusions. The description simply states what it does without context. An agent would have to infer usage from the name and sibling names, which is insufficient.

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