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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minor behavioral details such as the sample key being limited to 10 items and default language behavior, but it does not disclose the return response structure or pagination semantics. These additions are useful but not extensive.

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 well-structured, with a one-line summary, a brief list of example indicators, and clearly separated Args and Returns sections. It is front-loaded with the purpose and contains no redundant sentences.

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 read-only tool, the description explains parameters and indicates a list return, but it does not detail the exact fields of each indicator or any error handling. Given there is no output schema, the description could be more explicit about the response structure, but the tool's simplicity and annotation coverage partially compensate.

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 bears the full burden of explaining parameters. It clearly describes start_count (start order), end_count (end order), and language options (kr/en), including defaults and the automatic limit of 10 for sample keys. This adds meaningful context beyond the bare schema fields.

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 the top 100 key economic indicators, listing specific examples like GDP growth, base rate, CPI, unemployment, and M1/M2 money supply. It distinguishes itself from siblings (e.g., search_statistics) because it provides a pre-defined curated list, not a search function.

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 is provided on when to use this tool versus its siblings. It does not mention alternatives, exclusions, or conditions for preferring this tool over search_statistics or get_popular_statistic. The agent is left to infer 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?

Annotations already cover readOnly/idempotent/non-destructive, and the description adds per-indicator defaults (e.g., changes_only 기본 True for 기준금리), output format semantics, and the fallback behavior of returning the latest period if results are too large. This is beyond the annotations and no contradiction exists.

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 organized into distinct sections (overview, supported indicators, Args, Returns) with no redundant prose. Each bullet adds keyword mappings or parameter semantics that are absent from 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 tool with 7 parameters and no output schema, the description covers return formats and behavior. However, it leaves some details vague, such as exact date string formats per frequency and per-indicator defaults for transform/changes_only, so an agent may still need to infer them.

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 Args section documents all seven parameters, including defaults for recent_years, output_format, and allowed transform values. It also maps indicator keywords to their meanings, which the raw schema cannot convey.

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 immediately states it retrieves Bank of Korea core economic indicators in a single call without code lookup ('코드 검색 없이'), and enumerates the supported indicators. This specific verb+resource framing clearly differentiates it from sibling tools that search statistics tables or items.

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 says to use this tool when users request popular indicators like 기준금리, 성장률, or 물가상승률, eliminating the need to search codes. However, it never names sibling tools or states when not to use it, so the guidance is contextual but not exclusionary.

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 read-only and non-destructive behavior, so no contradiction exists; the description's '조회' matches readOnlyHint. It adds useful context about the content returned (structure, creation method, description) but not deeper behavioral details such as pagination limits or unknown-name handling.

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 front-loaded and the Args section is compactly organized. The only minor waste is the final 'Returns: 메타데이터' line, which largely restates the opening sentence.

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 read-only metadata lookup with four simple parameters, the description covers the required argument, defaults, allowed language values, and an example data_name. Without an output schema, the return description is still thin (just '메타데이터'), but the description is enough 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 description coverage is 0%, so the description carries the burden; it provides a required data_name example, defines start_count/end_count as sequence bounds with defaults, and constrains language to 'kr' or 'en'. This adds real value beyond the typed schema fields.

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 ('조회' / retrieve) and a concrete resource: metadata of a statistics dataset, including structure, methodology, and description. This clearly separates it from sibling tools that search statistics or return key statistics values.

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 sentence implies use when the agent needs dataset metadata, but it never states explicit conditions or names alternatives such as get_key_statistics or search_statistics. No 'when not to use' guidance is 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds value by explaining pagination behavior (has_more=true means increase start_count) and the language parameter, which are not available from annotations. No contradiction exists.

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, front-loaded with the purpose in the first sentence, and uses a structured Args/Returns layout. Every element—purpose, parameter semantics, pagination hint—has a purpose, 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?

Despite having no output schema, the description discloses the shape of the result (a list of 세부항목) and the pagination contract, while all four parameters are documented. For a simple read-only listing tool, nothing needed for a correct first call is missing.

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 carries the full burden and succeeds: it explains stat_code is mandatory and where to obtain it, provides defaults for start_count/end_count, and lists the accepted values for language ('kr' or 'en'). This goes beyond the schema's bare types and 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 uses a specific verb ('조회합니다') and a precise resource: the detailed items of a particular statistical table, listing the fields returned (항목코드, 지원 주기, 수록 기간, 단위). It does not explicitly contrast with sibling tools, but the scope is unambiguous and it references search_statistic_tables as the source of the required stat_code.

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 Args section gives clear context: stat_code is required and must come from search_statistic_tables, and start_count/end_count control pagination. It does not state when not to use this tool or name alternative tools for the same purpose, so it earns a 4 rather than a 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, openWorldHint, idempotentHint, destructiveHint=false. The description adds substantial behavioral context beyond annotations: smart date auto-fill, truncated=true with guidance, transform calculations, format variations, changes_only behavior, prefer_latest default, and pagination via start_count/end_count. No contradiction with 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 long but well-structured with bullet points and sections. Key behaviors (smart dates, truncation, transform, formats) are front-loaded, then date format rules, then parameter details. Every sentence adds value; no fluff. Given 15 parameters, the length is appropriate and 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?

With no output schema, the description must explain return formats, and it does: 'compact' (array of [time, value] per series), 'csv', 'json'. It also covers pagination, truncation, transform options, date formats for all cycles, and the behavior of changes_only and prefer_latest. All necessary information for an agent to call the tool correctly is present.

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 carries the full burden of parameter explanation. It does so excellently: each parameter is documented in the Args section with types, defaults, and examples (e.g., stat_code examples, cycle options with format rules, output_format options, transform options, and the warning about item_code1-4 returning huge results). This fully compensates 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 clearly states it retrieves statistical time series data by conditions, with a specific verb and resource. It mentions stat_code and cycle as required, and the examples (기준금리, 소비자물가) distinguish it from sibling tools like get_statistic_meta or search_statistic_tables.

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 the tool (time series queries) and provides extensive usage details like smart date defaults, truncation behavior, and format options. However, it does not explicitly mention alternative tools or exclusions, leaving some inference to the agent. It is clear enough that this is the time series query tool among the siblings.

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 mark it read-only and idempotent; the description adds useful behavioral detail: it uses a local index, responds immediately without an API call, returns relevance-ordered results, and filters by SRCH_YN. This is consistent with the annotations and adds context beyond them, though it doesn't disclose edge cases such as invalid parent_code 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 structure is clear: purpose, behavioral note, three bullet modes, Args, Returns. It is longer than minimal but every section adds value; a small redundancy is repeating defaults that already exist in 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?

With no output schema, it lists the returned fields (STAT_CODE, STAT_NAME, CYCLE, SRCH_YN) and explains the three call patterns, so an agent can invoke it correctly. It could be slightly more complete by explicitly routing to a sibling tool for other search needs, but that is more a usage-guideline gap than a completeness failure.

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 Args section fully compensates by explaining all four parameters, giving example values (물가, 금리, 0000000001), and defining searchable_only and limit semantics with defaults. This gives an agent everything needed to fill the parameters correctly.

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: it searches statistic tables by name and traverses the statistic-table classification tree, returning STAT_CODE values. This is clear, though it does not explicitly distinguish itself from siblings like search_statistics or search_statistic_word, so it falls just short of full marks.

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 usage modes: keyword for name search, parent_code for direct children, neither for root categories, and combined for scoped search. It notes the local-index/no-api-call property as a context cue, but it never names an alternative tool or says when not to use this one.

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 the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: it queries the Bank of Korea glossary and discloses the ECOS firewall quirk where '/' is replaced by a space. This helps an agent anticipate search behavior for terms containing slashes.

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 with an intro, examples, a behavioral note, Args, and Returns. It is reasonably compact, though the first two sentences are somewhat redundant—both say the tool searches definitions from the glossary.

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 search tool, the description covers the source, examples, parameter meanings, a behavioral quirk, and the return type ('용어 정의 목록'). It does not detail response fields, but no output schema exists and the tool is straightforward enough that this is a minor 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%, but the description compensates fully by explaining every parameter: 'word' is the term to search, 'start_count' and 'end_count' define the result range with defaults, and 'language' specifies 'kr' or 'en'. This adds real meaning beyond the bare 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 a specific verb and resource: searching definitions of economic/statistics terms from the Bank of Korea terminology dictionary. It also gives concrete examples like '기준금리' and 'GDP', which makes the tool's purpose unambiguous and distinct from sibling tools that search statistics data or tables.

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 establishes the context: this is a dictionary-lookup tool for term definitions, not a data/table search. It does not explicitly name alternative sibling tools or state when not to use it, but the scope is specific enough that an agent can infer appropriate usage.

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