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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by stating it does not call or combine raw data, reinforcing that it is a metadata-only check. This goes beyond the annotations by clarifying the tool's non-execution nature.

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 concise sentence that front-loads the primary action and adds a clarifying exclusion. Every clause contributes meaning without redundancy or fluff.

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

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

The tool is simple (2 params, no output schema) and the description covers the core function and non-execution behavior. However, it lacks parameter semantics for 'regions' and provides no details about output or return values. It is minimally viable but has clear gaps for an agent's full understanding.

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

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

Schema description coverage is 0%, so the description must explain parameters. It mentions '카탈로그 ID' (catalog ID) which maps to dataset_ids, but does not explain the 'regions' parameter or how it is used. The description only indirectly references 지역 (region) as a check item, leaving the regions parameter semantically 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 clearly states the tool checks whether selected catalog IDs exist and organizes items to verify on the official page (schema, region, auth, join keys). It uses a specific verb (확인, 정리) and distinct resource (catalog IDs). It also explicitly excludes calling or combining raw data, distinguishing it from sibling tools like recommend_data_combination or design_public_data_product.

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

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

The description implies usage as a preliminary feasibility check before combining data, and notes it does not execute raw data calls or joins. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention cases where it should not be used. No alternatives or exclusions are named.

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, idempotentHint, and destructiveHint, so the safety profile is known. The description adds valuable context by clarifying that it draws from a static list and does not query live data, giving the agent a clear mental model of the tool's behavior beyond the annotations. No contradictions 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 a single, well-structured Korean sentence that states the core function and a critical limitation, with no redundancy or filler. It is front-loaded with the primary action and includes an important boundary in the same 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?

With five parameters and no output schema, the description should explain how inputs influence the result and what the reference design proposal looks like. It mentions the content areas (product composition, data flow, verification procedures, expected outputs) but gives no details on parameter usage or output format, leaving significant gaps for an agent to 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?

The schema lists five parameters (goal, limit, regions, data_needs, desired_outputs) with 0% description coverage. The description makes no mention of any parameter, leaving the agent without any guidance on what values to provide or how the parameters shape the design. The description fails to compensate for the lack of schema coverage.

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 creates a reference design proposal for product composition, data flow, verification procedures, and expected outputs, based on a static list of data types and official providers. The verb '만듭니다' (creates) is specific, and the resource is clearly '공공데이터 서비스·제품 설계' (public data service/product design). This distinguishes it from sibling tools that list, search, or recommend data combinations.

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

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

The description implies usage for design tasks rather than actual data retrieval, especially with the note '실제 데이터는 조회하지 않습니다' (doesn't query actual data). However, it does not explicitly mention alternatives or state when to use this tool over others, leaving the guidance implicit rather than 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?

The description goes beyond annotations by noting that the numbers are a static snapshot, not the current total of all public data in South Korea. It also mentions 'current runtime channel', providing useful context about the tool's scope. Annotations already indicate read-only and idempotent behavior, and the description complements them without 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 two sentences long and front-loaded with the action ('returns') and the specific items returned. The second sentence adds an important caveat, keeping it concise without unnecessary detail. Every word contributes value.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description adequately lists all return values and their semantic meaning. The snapshot caveat adds necessary context about data freshness, making the tool's output interpretable without further 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?

The tool takes no parameters, so parameter semantics are trivially satisfied. The description does not need to explain parameters, and the empty input schema is fully consistent. The baseline score of 4 applies given the absence of 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?

The description clearly states what the tool does: it returns specific inventory coverage metrics (runtime channel, base date, row counts, differences, type counts). The verb '반환합니다' (returns) and the explicit list of returned data make the purpose unambiguous and distinct from sibling tools that list or search datasets.

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

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

The description implies usage for checking coverage status but does not explicitly state when to use this tool versus alternatives like 'search_public_datasets' or 'list_public_data_sources'. There is no mention of exclusions or alternative tools, so guidance is only implicit via the scope of the returned data.

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 annotations already declare the read-only, idempotent, non-destructive nature. The description adds behavioral context by listing exactly which fields are returned and which are omitted (source description, fields, contact info, actual values, join keys). This goes beyond annotations by clarifying the tool's scope.

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

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

The description is two short sentences. The first sentence lists the returned fields, the second states exclusions. Every word is information-dense 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?

For a simple detail-retrieval tool with one parameter and no output schema, the description covers the purpose, the data returned, and the exclusions. It could have mentioned that the ID must originate from `search_public_datasets`, but it is strongly implied. Given the tool's simplicity, this is 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?

The schema only provides the parameter name (`dataset_id`) and type/length constraints. The description adds crucial semantic meaning by identifying it as a 'search result ID', clarifying that it must come from a previous search operation. This fully compensates for the 0% schema description coverage.

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 the specific verb '조회합니다' (retrieves) and enumerates the exact data fields returned (data type, institution, classification, format, update cycle, keywords, official link). It also explicitly states what is not included, which helps differentiate it from tools that return full dataset content. This makes the purpose unambiguous and distinguishes it from sibling tools like search_public_datasets.

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 '검색 결과 ID로' indicates that this tool is intended for use after obtaining an ID from a search result, providing clear context for when to call it. However, it does not explicitly name alternative tools or state exclusions (e.g., 'use this instead of X'). The condition is implied, not fully 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?

Beyond the annotations (read-only, idempotent), the description discloses valuable behavioral traits: it operates only on local data without external network access, and it explicitly cautions about row count discrepancies (96,056 vs 87,581), preventing misinterpretation of national totals. This is rich contextual transparency.

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

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

The description is three concise sentences, front-loaded with the primary purpose, followed by a data quality caveat and a scope clarification. Every sentence adds substantive value without redundancy, achieving a high signal-to-noise ratio.

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 important context about local-only operation and data limitations, but with 7 undocumented parameters and no output schema, it leaves the agent short of understanding how to construct queries or interpret results. It is a minimally viable description for a list tool, but gaps remain in parameter and return-value coverage.

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 any of the 7 parameters (limit, offset, query, enabled, etc.). It mentions 'reference date and row count ranges' but fails to connect these to specific parameters or provide filter guidance, leaving the agent without adequate parameter meaning.

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 action (retrieve/list), resource (static metadata sources), and scope (local runtime only, not external portals). It explicitly says 'does not access external portals,' distinguishing it from sibling tools like search_public_datasets.

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

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

The description provides clear context for when to use the tool: when needing local static metadata sources and their reference date/row count ranges. It notes it does not access external portals, implying a boundary, but does not explicitly name alternative tools or state 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?

Beyond the readOnly and idempotent annotations, the description adds important behavioral context: it operates on a static list and does not actually fetch, process, or combine data; those steps are left to the user after checking official pages. This boundary-setting is valuable.

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

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

The description is two sentences, front-loaded with the core action and followed by a scope clarification. Every sentence carries necessary information with no redundancies.

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 recommendation tool, it covers the main workflow and output (data types, institutions, links), but lacks details on optional parameters and result ranking/format. Given the absence of an output schema, more could be added, but it is largely sufficient.

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 only partially compensates. It explains that the goal is broken into data needs, which relates to 'goal' and 'data_needs', but it does not describe 'limit' or 'regions' parameters or their formats.

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 decomposes a service/analysis goal into data needs and recommends relevant public data types, institutions, and official verification links from the entire static list. This specific verb+resource+scope distinguishes it from sibling tools like search_public_datasets or list_public_data_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?

It provides a clear usage context: when the user has a desired service/analysis and wants to identify relevant public data. However, it does not explicitly mention alternatives or when not to use this tool, which would make it 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?

The description adds meaningful behavioral context beyond the read-only/idempotent annotations: it specifies the snapshot date (2026-06-30), that the source is a fixed local list, that it does not access external APIs or raw data, and that license indications are merely metadata for verification. This helps set accurate expectations about data freshness and limitations.

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

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

The description is two sentences: the first states the action and scope, the second clarifies limitations. It is front-loaded and every sentence adds value without redundancy or excessive 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?

Given the tool has 14 parameters and no output schema, the description gives enough high-level context for an agent to know what the tool does and its limitations, but it does not cover parameter semantics, result structure, or pagination behavior. It is adequate for selection but lacks depth for confident invocation without relying on parameter names 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 the 14 parameters. It mentions searchable fields (name, agency, classification, format, keyword) but does not map them to schema properties like 'query', 'providers', 'formats', or 'classifications', nor does it clarify how array filters or booleans (e.g., 'include_non_data') behave. The description provides minimal compensation 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 clearly states the tool's function: searching a local static list for metadata fields like name, agency, classification, format, and keyword, plus official link candidates. It uses a specific verb ('검색합니다') and resource, and its scope is delineated from sibling tools that list, fetch details, or recommend combinations.

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 the tool is for searching metadata and distinguishes itself by noting it does not query raw values or external APIs, but it does not explicitly state when to prefer this over sibling tools or when not to use it. No alternatives are named, so usage guidance is only implicit.

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