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

No annotations are provided, so the description carries the full burden. It does disclose a useful behavioral trait beyond the schema: a two-stage strategy that consults a verified catalog first and only escalates to KOSIS integrated search when nothing is found. It says nothing about result format, latency, rate limits, or whether results are cached/authoritative.

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 short sentences, front-loaded with the core purpose before the retrieval strategy and the 'first step' framing. 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 low-complexity 3-parameter lookup tool with no output schema and no annotations, the description covers what it does and how it resolves queries well enough to invoke it. The main omission is any hint of what the returned catalog entries look like, which is a minor gap for a finder tool.

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

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

Schema description coverage is 100%, with each parameter documented in the schema (query examples, max_results default, include_search semantics). The description adds no parameter-level meaning beyond that, so the 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?

States a specific verb and resource: finding statistical tables from natural-language queries, and positions itself as the entry point of a statistics lookup flow. It implicitly distinguishes itself from the raw KOSIS search sibling by describing a catalog-first strategy, though it never names kosis_search or kosis_list directly.

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?

Gives clear context for when to reach for this tool: '통계 조회의 첫 단계입니다' (the first step of a statistics lookup) and explains the catalog-first-then-fallback ordering. It does not explicitly state when NOT to use it or which sibling to prefer for raw search, so it stops short of full alternative routing.

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 does disclose one valuable trait – automatic period-splitting when the result exceeds 40,000 cells – but says nothing about pagination, return shape, or rate/permission constraints that an agent would want for a 9-parameter data pull.

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 tight sentences with zero filler, and the core purpose plus the key behavioral constraint (40,000-cell auto-split) are front-loaded before the sibling redirect.

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 data-retrieval tool with a fully documented 9-parameter schema and no output schema, the description covers purpose, modes, the large-result behavior, and the escape hatch to kosis_export. The main remaining gap is the shape of the returned data, which no output schema documents either.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema with format hints (e.g. YYYYMM, 'ALL'). The description only restates the period-vs-recent choice at a high level and adds no parameter-level 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?

Names a specific verb and resource (retrieving statistical table data) and scopes it to two modes, period-based or recent-N. It differentiates itself from kosis_export by routing large-row cases there, but gives no signal about how it differs from kosis_trend or kosis_table_meta.

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 offers the two invocation modes (기간 지정 또는 최근 N개 시점) and names the alternative tool (kosis_export) with the condition that selects it (행이 많으면). It stops short of stating when NOT to use this tool beyond the row-count case.

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, so the description carries the full burden. It usefully discloses the output artifact structure (two sheets, xlsx + CSV) and the KOSIS_EXPORT_DIR configuration, but says nothing about overwrite behavior, required write permissions on the directory, or whether a file path/confirmation is returned.

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

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

Two tightly packed sentences: the operation and output formats come first, the output-location detail second. No filler and nothing redundant with the schema.

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 nine-parameter export tool with no annotations and no output schema, the definition covers the operation, artifacts, and destination folder but omits what the call returns (e.g., saved path) and any failure/overwrite semantics. Adequate but leaves real gaps for a write-to-disk 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%, so all nine parameters are already documented in the schema. The description adds no parameter-level detail beyond the KOSIS_EXPORT_DIR environmental note; baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb (저장합니다 / save) and resource (통계표 자료), plus the concrete output forms (xlsx, CSV, raw-data sheet + time-period sheet). This clearly separates it from data-fetching siblings like kosis_data, though the description never names an alternative 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 purpose implies 'use this when you want the table written to disk rather than returned in-chat', but there is no explicit when-to-use/when-not guidance or reference to the sibling kosis_data it overlaps with. Usage must be inferred from the name and format details.

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

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

No annotations are present, so the description carries the full behavioral burden. It usefully discloses that this is a step-by-step (iterative) tree traversal, which is behavior beyond the schema, but it does not state read-only safety, what is returned, or how to proceed after a call.

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 efficient sentence, front-loaded with the resource and the traversal mode. It avoids waste, though it is arguably too terse for a tool with no annotations.

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 two-parameter tool with a fully documented schema, the description covers the core purpose. It omits important operational context: that it returns child nodes, how to use parent_id='0' for the root, and that repeated calls are needed to reach a table.

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%: both vw_cd and parent_id are fully documented with defaults and enum-like values. The description adds no parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb+resource: exploring the KOSIS statistics list, which is a theme/institution classification tree. The phrase '한 단계씩' (one step at a time) signals hierarchical traversal and distinguishes it from search-style siblings, though no sibling is named 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?

Usage is implied by '한 단계씩 탐색' – the agent can infer this tool is for iterative top-down browsing rather than searching or fetching data. However, no explicit when-to-use guidance or alternatives (e.g., kosis_search) 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 behavioral burden, and it adds almost nothing beyond the schema. It does not disclose result shape, pagination limits, whether results are ranked, or any cost/rate behavior for a tool that hits an external search endpoint.

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

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

Two short sentences, front-loaded with the action and followed by the routing condition, with no filler.

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?

Covers purpose and a rough usage condition, but for a search tool with no output schema the description omits anything about what results look like or how to page through them. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so page, sort, count, query and org_id are already fully documented in the schema. The description only restates that 기관·정렬·페이지 are specifiable, adding no format or syntax detail beyond it.

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?

States a specific verb+resource (실행한다 / KOSIS 통합검색) and frames it as the direct search entry point. The clause about finding tables not in the catalog hints at a distinction from catalog-oriented siblings, though it does not name 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?

"카탈로그에 없는 통계표를 찾을 때 씁니다" gives a when-to-use condition, which implies the catalog tools are the alternative path. However, it never names kosis_list or find_table explicitly, so the routing decision is left to inference.

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 conveys that this is a lookup/조회 step that returns codes and feeds into kosis_data, which implies a read operation, but it says nothing about permissions, return format, or failure behavior for a metadata 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?

Two compact sentences, front-loaded with the what (ITM/OBJ code lookup) followed by the workflow position. No filler; both sentences carry information, though it is minimal overall.

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

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

For a two-parameter, fully-required metadata lookup with no output schema, the description adequately conveys what is retrieved and how it fits before kosis_data. Slightly more on the return shape would help, but it is largely 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 description coverage is 100%, with org_id and tbl_id both documented (including examples and their origin in find_table results). The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

States a concrete verb and resource: retrieving the item (ITM) and classification (OBJ) codes of a statistical table. This is distinct from the data-pulling siblings like kosis_data, which the description references, though it does not explicitly name find_table or other siblings for contrast.

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 second sentence positions the tool as a preparatory step before kosis_data ('the step to check codes to put into kosis_data'), giving implied workflow context. It stops short of naming alternatives or stating when not to use it, so guidance is only implied.

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 does disclose the computation semantics (직전 시점 대비 증감, 구간 요약, CAGR), which is the key behavioral trait, but says nothing about missing periods, minimum data requirements, or how the default 5-point window is chosen.

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

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

Two sentences with zero filler: the first front-loads what is computed and the output shape, the second gives the motivating use case. Every clause earns its place.

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 10-parameter analytical tool with no annotations and no output schema, the description does help by naming the returned metrics. But it omits default behavior (5 recent points), error handling, and any guidance on the required classification identifiers beyond what the schema already says.

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%, covering the date formats, ALL convention, group_by, and include_series, so the baseline is 3. The description adds no parameter-level meaning beyond what the schema already states.

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

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

The description names a specific action (시계열로 묶어 증감·증감률·CAGR 계산) on a specific resource (통계표 자료), so an agent knows exactly what comes back. It is clear but does not distinguish itself explicitly from the sibling kosis_data, which likely returns raw observations.

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 second sentence gives a use case (거시 추이와 시장 규모 변화 파악), which implies when to reach for this tool. However, it never states when NOT to use it or points to kosis_data/kosis_export for raw series or export, so routing remains inferred.

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