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

No usable annotation flags are verifiable in this context, so the description carries the transparency burden. It adds genuine behavioral context: the KOSIS two-layer (STAT_NM/TBL_NM) structure, the caller-driven layer choice, and the accessed-date requirement for dataset citations. However, it never states what the tool returns (citation string? formatting?), whether the operation is pure/read-only, or any failure behavior — gaps for a tool with no output schema.

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?

Purpose is front-loaded, and the ⚠️ block economically steers the agent away from overuse by naming alternatives. The layer-semantics paragraph is the longest section but is justified because it determines citation structure. The trailing Args line is minimal; each sentence 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 3-parameter, no-nested, no-output-schema tool, the description covers purpose, usage conditions, and layer semantics well. But because no output schema exists, the description should explain the return value, and it does not; two of three parameters also remain under-documented. Adequate for a simple auxiliary tool, 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 0%, so the description must document parameters; it explicitly covers only 'accessed' (YYYY-MM-DD and why it is needed). The two-layer discussion indirectly hints at what 'id' refers to (a table or survey), but the 'style' parameter is never mentioned and no enum/default guidance exists — a meaningful gap for a citation-formatting 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 and resource: '통계표 하나를 서지(인용) 칸으로 투영한다' — projecting one statistical table into a citation field, explicitly marked as an auxiliary feature. It also names sibling tools (kosis_search for metadata, kosis_data for numbers) as the mainline, which differentiates this tool without requiring an agent to open other schemas.

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 explicit when-to-use (only when handing off to a bibliographic management tool) and when-not-to (when the goal is using statistics, kosis_search and kosis_data are the main tools). It further instructs the caller to choose the citation layer — container_title for the survey layer, title for the table layer — leaving no ambiguity about selection criteria.

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

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

Annotations already indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds useful behavior: saving to files, variable column structure, and auto-adjustment of axes. However, it does not disclose other behaviors such as file overwriting, authentication requirements, or rate limits. It adds some value beyond annotations but is not comprehensive.

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

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

The description is concise with two sentences. The first sentence states the main purpose, and the second warns about variable columns. It is efficient and front-loaded, though the second sentence is a bit long and could be split 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?

Given the tool's complexity (18 parameters, no output schema, no enums), the description is far from complete. It does not explain required parameters like org_id, tbl_id, or prd_se, nor optional ones like start/end/recent. The warning about variable columns is helpful, but the overall context is insufficient for an agent to call the tool correctly without further investigation.

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. It explains obj_l2~obj_l8 auto-adjustment and the formats parameter implicitly (xlsx/csv/json/sqlite). However, it leaves the other 14 parameters (org_id, tbl_id, prd_se, start, end, recent, name, items, obj_l1) undocumented. This is a significant gap for a tool with 18 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?

States a clear verb+resource: receives statistics table values and saves them as xlsx/csv/json/sqlite. It also mentions the variable column structure, but does not differentiate from sibling tools like kosis_data or kosis_indicator_data, which may also fetch data. The purpose is specific but not distinguished from alternatives.

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

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

No guidance on when to use this tool vs alternatives. It provides a technical note about variable columns and auto-adjustment, but does not state when this tool is preferred over siblings like kosis_data. The agent is left to infer usage from the name and description.

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

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

The description richly discloses behaviors beyond annotations: it explains automatic axis-count matching (with error codes 20/21), automatic period splitting for >40,000 cells, auto-filling of obj_l2-8 with 'ALL', and the presence of meta.obj_levels in the result. It also notes the 40,000-cell limit (err 31). These are valuable behavioral traits not covered by the readOnlyHint/openWorldHint annotations.

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

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

The description is well-structured: a one-line summary, a highlighted note about classification axes, then a bulleted Args list. Key behaviors are front-loaded with red emojis to draw attention. Every sentence adds value—no fluff or repetition. It is detailed but efficiently organized.

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

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

Given the complexity (16 params, no output schema, no enums), the description is remarkably complete. It covers error conditions, parameter relationships, alternatives, and behavioral nuances. It mentions the result's meta.obj_levels, which gives insight into the return structure. An agent can reliably call this tool correctly without additional documentation.

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?

With 0% schema description coverage, the description fully compensates by documenting all 16 parameters. It explains each parameter's purpose, format (e.g., '101' for org_id, 'DT_1B040A3' for tbl_id), valid values (Y/H/Q/M/D for prd_se), and special behaviors (wildcards like '11*', multiple codes '11+21', and auto-fill logic). This is exceptional given the schema provides no help.

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 clear, specific verb and resource: 'Gets the numbers of a statistical table.' This unambiguously states the tool's purpose and inherently distinguishes it from siblings like kosis_meta (metadata) and kosis_search. It is not a tautology and adds concrete scope.

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 alternatives: it directs users to kosis_collect for file retrieval and to kosis_meta for validating prd_se and items. It also explains when to use start/end vs recent and the auto-fill behavior for obj_l2-8. However, it does not explicitly contrast with kosis_indicator_data, a sibling that might overlap, so it stops short of a perfect 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds content-level behavior by listing what the explanation contains, but it does not discuss return format or limitations. This is acceptable given the 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?

Two short sentences with no fluff; the resource type comes first and the usage rationale second. It is concise and front-loaded, though the second sentence is somewhat indirect.

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 read-only tool, the description covers return content and one use case. However, there is no output schema and no explanation of parameter semantics, so an agent cannot fully infer invocation details from this description alone.

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

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

Schema description coverage is 0% and the description does not explain org_id or tbl_id formats, provenance, or how to obtain them. The parameter names are somewhat self-explanatory, but the description fails to compensate for the lack of schema documentation.

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 that the tool provides statistical explanation/survey overview with purpose, basis, period, and scope. This is specific enough to identify the tool's resource and distinguish it from generic data or status siblings, though it does not explicitly contrast with kosis_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?

It gives a clear usage context: statistical tables lack abstracts, so this explanation is material when relevance scoring or summarization is needed. It does not mention exclusions or alternatives, but the intended use case is explicit.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds useful behavioral context by listing limitations and pitfalls, signaling that this is a meta/orientation resource rather than a data-returning 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 a single front-loaded phrase with a compact list of covered topics. There is no wasted wording or redundancy with the schema or 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 no-parameter, read-only guide tool, the description is reasonably complete: it states what knowledge areas it covers and flags limitations and pitfalls. It does not describe the response format, but no output schema exists and the tool's purpose as a guide makes that less critical.

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 is empty with 0 parameters and 100% schema coverage, so there are no parameter semantics for the description to clarify. A baseline of 4 is appropriate because no parameter documentation is needed.

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 this tool provides the knowledge needed to use the KOSIS API, specifically covering service view, cycle, meta types, limitations, and pitfalls. This is clear as a guide/resource, but it does not explicitly differentiate itself from siblings like kosis_explain.

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 'what to know when using this API' implies the agent should consult this guide alongside or before the other kosis_* tools, but no explicit when-to-use or when-not-to-use guidance is given. Alternatives are not named or excluded.

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

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

The description prominently discloses that the server does not filter by time range, that the tool filters locally, and that the outcome is reported via meta.server_filtered=false and meta.filter_note. This is valuable behavioral information beyond the readOnlyHint annotation and contradicts nothing.

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 purpose is stated first, followed by a justified warning and a clean Args list. The warning is slightly long but contains essential caveats needed for correct usage, so it 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?

The description provides all necessary input semantics, the critical filtering caveat, and mentions relevant metadata keys. Since there is no output schema, the absence of output format details is acceptable; the tool can be used correctly with the given information.

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

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

The schema provides zero parameter descriptions, but the description explains all four parameters: jipyo_id, start, end, and recent, including the special meaning of start/end as mode switches rather than true server-side filters. This fully compensates for the schema's lack of documentation.

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 time-series values for major indicators by jipyo_id, and references kosis_indicator_search for finding the ID. It is specific enough to distinguish the resource, though it does not explicitly differentiate it from sibling data tools like kosis_data.

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 practical usage instructions: start/end range examples, behavior when empty, and recent usage with constraints. It also warns about server-side filtering behavior. However, it does not explicitly state when to use this tool versus the other sibling data tools.

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

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

The readOnlyHint and openWorldHint annotations already signal safety, and the description adds meaningful behavior: it auto-paginates through all pages and reports pages read in meta.pages. No side effects are claimed, so there is no contradiction with the annotations.

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

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

The description is compact and well structured, with a purpose statement, a usage distinction, a pagination warning, and an Args list. It is slightly repetitive in emphasizing the indicator-vs-table distinction, but all sentences carry useful information.

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

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

The description covers key usage context and pagination, but with no output schema it does not describe the returned item fields or structure beyond meta.pages. An agent would still need to infer what an indicator result object contains and how to use the returned IDs with related 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?

Although the schema has no descriptions, the Args section explains all three parameters: name with examples, jipyo_id as a direct-ID alternative, and max_records as the maximum number of returned items. It also clarifies that either name or jipyo_id should be supplied, which is important operational guidance.

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: finding major KOSIS indicators by name, and explicitly distinguishes this from the statistical-table series. It also names the sibling tool kosis_search for table-oriented searches, so an agent can disambiguate immediately.

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 gives concrete guidance: use kosis_search instead when working at the table level, and explains that indicator results are curated. It also describes pagination behavior, though it does not explicitly mention when to use kosis_indicator_data instead of this 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?

Annotations already declare this as read-only and non-destructive. The description adds useful behavioral detail beyond that: traversal is one step at a time, empty parent_id returns top-level items, and an empirical note contradicts the development guide's claim that parent_id is required. It does not describe return shape, but that is minor for a simple read-only list 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 compact and efficiently structured: a one-sentence purpose statement followed by a concise argument list. There is no filler, and the empirically grounded note about parent_id 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 two-parameter, read-only listing tool, the description covers purpose, parameter semantics, and key call behavior. It does not explicitly describe the return format, but the nature of a one-level tree scan makes it reasonably inferable, and the annotations cover the safety profile.

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 0%, so the description carries the full parameter-documentation burden. Both parameters are meaningfully explained: vw_cd is tied to the service-view definitions in kosis_guide, and parent_id's optionality and empty-value behavior are explicitly clarified.

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 action ('scans one level of the statistics list tree') and a clear resource, optionally scoped by topic or institution. It is clearly not tautological and conveys the tool's basic function, but it does not explicitly differentiate it from sibling tools such as kosis_search or kosis_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?

The context of use is implied: browse the statistics list hierarchy one level at a time, and leave parent_id empty to get the top level. However, the description never states when to prefer this tool over its siblings, nor does it mention any exclusions or alternative 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?

Beyond the readOnlyHint annotation, the description discloses specific error behaviors (err 20/21 vs. err 30), what kinds are not supported (NCD, OBJ, CLS), and that axes are automatically handled by kosis_data. This adds meaningful 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 dense but well-organized, front-loading the main purpose then listing crucial warnings. Each sentence contributes actionable information, and the use of emojis aids scannability without adding 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?

For a metadata-lookup tool with no output schema, the description covers all essential context: what it returns, relationship to sibling tools, error semantics, and limitations. It is complete enough for an agent to decide when and how to use 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?

The description explains the 'kind' parameter and its accepted values (from kosis_guide) and its default, but does not elaborate on org_id or tbl_id. Since these are self-explanatory in context and the schema covers them implicitly, the description adds moderate semantic value beyond the raw 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 that the tool retrieves metadata (items, periods, sources, comments) for a statistical table, distinguishing it from data retrieval. It is specific about the resource and the scope of information provided.

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

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

Explicitly instructs to call this tool before kosis_data to check ITM and PRD to avoid errors 20/21, and warns about the absence of classification-axis kinds and the error behavior of unknown kinds. It also points to kosis_guide for possible kind values, providing 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?

Annotations already provide readOnlyHint and openWorldHint, so the description need not restate safety. It adds useful behavioral specifics: search scope is by name/content and max_records caps the result count. It does not describe output shape or pagination, but for a simple read-only search this is a minor gap with no contradiction.

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 compact and front-loaded: one sentence states purpose and a short Args block defines the parameters. There is no filler, repetition, or unnecessary detail.

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

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

For a two-parameter read-only search tool with helpful annotations, the description covers the essential invocation details: what is searched, how to phrase the query, and the result cap. The only notable absence is a pointer to sibling tools for alternative use cases, but the simple scope and annotations make the definition sufficiently 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 0%, but the description fully compensates by clearly defining query as the search term with concrete examples and max_records as the maximum number of results to return. Both parameters receive meaning beyond their bare schema titles.

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 action ('찾는다/finds') and resource ('통계표/statistical tables'), and specifies the search is by name or content. It is clear but does not explicitly distinguish it from sibling tools such as kosis_list or kosis_meta, so it falls just short of full differentiation.

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 examples (e.g., '사교육비', '출산율') and 'KOSIS 통합검색' imply this is for finding tables by keyword, giving some contextual guidance. However, there is no explicit statement about when to use this tool versus the sibling tools or when not to use it.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses meaningful behavioral traits: it checks authentication-key possession and performs one live network round trip to KOSIS. This reveals the external dependency, latency, and auth-relevant behavior, which are valuable for the agent to anticipate.

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 short, front-loaded sentence that conveys the tool's purpose and behavior with no filler. Every part of the description adds information.

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

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

For a zero-parameter status-check tool with no output schema, the description is largely complete: it says what is checked and that a live network call occurs. The only minor gap is that it does not specify the exact return format, but this is low-impact for such a simple 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 tool has zero parameters and schema coverage is 100%, so the baseline of 4 applies. The description does not need to explain parameter meanings since there are none.

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 and resource: '연결 점검' (connection check) for KOSIS, and specifies two concrete checks: whether an API key is held and whether one actual round trip works. This clearly distinguishes the status tool from siblings like kosis_data, kosis_search, or kosis_explain.

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 when to use the tool: when an agent needs to verify KOSIS connectivity or API key validity before relying on other KOSIS operations. It does not explicitly name alternatives, but none of the sibling tools serve this health-check role, so the context is sufficient.

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