star365 Korea Data

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds that the list is 'full' (implying no pagination) and includes meanings, but says nothing further about caching, format, or other behavioral traits.

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, front-loaded sentences with no filler, and the usage trigger comes before the bilingual restatement. The Korean translation duplicates the same content, which is a small redundancy for non-Korean agents but is clearly intentional.

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 parameters and no output schema, the description carries the burden of describing the return payload, and it does so at a high level ('full list of classification values ... with what each means'). It stops short of describing the record shape, but for a zero-arg codebook that 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?

The tool takes zero parameters, which is the baseline-4 case; there are no parameter semantics to explain. The description correctly implies a parameterless lookup rather than suggesting any argument 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?

States a concrete deliverable — the full list of classification values used for eligibility matching, including their meanings — which is a specific resource rather than a restatement of the name. It actively distinguishes itself from the sibling benefits_match by positioning itself as the prerequisite lookup for that tool.

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 names the trigger condition ('when you do not know what to put into benefits_match') and the sibling it routes against. An agent reading only this line knows exactly when to call this tool instead of benefits_match.

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, destructiveHint=false and closed-world behavior, so the safety profile is covered. The description adds value beyond that by disclosing the shape of the returned record (contents, deadline, documents, contact, legal basis), which is meaningful for a single-record lookup with no output schema. It does not mention missing-id or not-found 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?

Front-loads the core purpose and the returned fields, then adds the routing instruction, all in two sentences with no filler. The line is short enough to scan quickly despite the bilingual duplication that serves the tool's Korean-language domain.

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 one-parameter lookup with no output schema, the description covers both the calling contract (the id from benefits_match) and the essential return contents, so nothing an agent needs in order to call and interpret the result is missing. The annotations already carry 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 description coverage is 100% and the schema already states the parameter is the service ID from benefits_match, so the description's 'Use the id returned by benefits_match' largely restates the schema. No additional syntax, format, or validity constraints are provided, which matches the baseline for a well-documented single parameter.

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 ('See ... one benefit programme') and enumerates exactly what the record contains (benefits, deadline, documents, contact, legal basis). It also names the sibling it depends on (benefits_match), so an agent can distinguish it from the search-style match tool without opening either schema.

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 tells the agent to use the id returned by benefits_match, which establishes the correct call sequence and the alternative tool for discovery. It stops short of stating when not to use it or what to do if no id is available, so it is clear context rather than a full when/when-not rule set.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the matching semantics — missing conditions are UNRESTRICTED rather than excluded — plus the explicit caveat that results are candidates and final entitlement rests with the administering agency. It does not describe pagination behaviour or the shape/size of a result set beyond 'candidate list'.

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?

Front-loaded with the core purpose before the filtering detail and the warning, and no sentence is wasted. The trailing Korean sentence restates the same two points already made in English, which is mildly redundant but serves a bilingual audience.

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 7 optional parameters, no output schema and no required inputs, the description covers the crucial behavioural facts (open-ended condition matching, non-authoritative results) that an agent needs before calling. It stops short of describing what a returned record contains, which is a minor gap given the absence of an output schema.

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 the schema already documents each parameter, including how to omit age and income. The description reinforces the omit-to-broaden rule and characterises traits as life stage/occupation/school/health, but adds little syntax or meaning beyond the schema, 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 ('Find') and resource ('Korean government benefit programmes') with an explicit scope: filtering the 10,956-record Bojogeum24 registry by age, income, household and traits. It is clearly distinguishable from siblings like benefits_detail (single record) and benefits_codebook (enum reference).

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 real usage guidance: omit conditions you are unsure about, because unstated conditions are treated as UNRESTRICTED and guessing drops matches ('the fewer conditions you give, the more results you get'). However it never names an alternative tool or states when a sibling such as benefits_detail should be used instead.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed world), so the bar is lower. The description adds a genuinely non-obvious semantic caveat: the value is a relative index anchored to libraries, not an absolute search volume. That is the single most likely misinterpretation of the output and the description preempts it.

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 English text is front-loaded and every sentence earns its place, with the critical caveat ('NOT an absolute search volume') placed before the use-case guidance. The full Korean mirror of the same text roughly doubles the length without adding information, which keeps it from a 5.

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 carries some burden for explaining what comes back, and it only says the output is an index relative to an anchor without describing the record shape, ranking direction, or scale. For a simple 2-parameter, no-required-parameter read tool this is adequate but not 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% and both parameters (limit, heldOnly) are documented in the schema, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already states, though the mention of the 'libraries' anchor loosely frames what heldOnly/topic results mean.

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 resource and metric ('Search-demand ranking') and immediately clarifies what the metric actually means ('an index relative to an anchor (libraries), NOT an absolute search volume'). That is more precise than the bare tool name. It does not explicitly differentiate from siblings, but none of the listed siblings (search_catalog, list_regions, benefits_*) overlap with a demand-index metric, so differentiation is not really needed.

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 one affirmative use case ('compare what people look for more, for market or topic research'), which tells the agent the intended context. However, it names no alternatives and states no conditions under which this tool should NOT be used (e.g., vs. search_catalog for retrieving actual records). Usage is implied rather than bounded.

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=false and non-destructive, so the safety profile is fully covered. The description adds useful context about what is returned (loaded datasets plus record counts), but says nothing about ordering, pagination, or how 'loaded' is determined.

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?

Very short and front-loaded: the core fact (loaded datasets with counts) comes first, followed by the purpose and a translation. The bilingual repetition doubles the length but mirrors the schema's own bilingual style, so it's defensible rather than wasteful.

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 one-optional-parameter read tool with full annotation coverage and a fully described schema, the description supplies what the structured fields cannot: that the list reflects actually loaded data and includes counts. The absence of an output schema is mitigated by this statement of what is returned.

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 the single optional 'query' parameter is already fully documented in the schema, including empty-means-full-list behavior. The description adds nothing further about parameter behavior, which is the expected baseline when the schema does the work.

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?

Specific verb+resource: it lists the datasets that are actually loaded and mentions record counts, which clarifies the scope beyond a raw catalog listing. It doesn't name which sibling to use instead when the user wants search rather than enumeration, so it falls short of full sibling 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?

'Check what we can answer from' implies the use case (assessing available coverage) but never states when to prefer this over search_catalog or search_data, nor any preconditions. Usage is inferable but not 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=true, idempotentHint=true, and non-destructive, so the safety profile is covered. The description adds little beyond reiterating that regions overlap data; it does not explain the minAxes filtering behavior, output format, or why 'check here first' matters. With the low bar set by rich annotations, this still under-delivers.

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 short and front-loads the core idea, which is good. However, the bilingual duplication doubles the length without adding information, and the second sentence after the slash is just a Korean translation rather than new guidance.

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 one-param, read-only list tool with no output schema, the description is minimally adequate: it tells the agent this is a starting point for region availability. It still lacks clarity on what the returned list contains and how minAxes changes it, leaving some 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 coverage is 100% and the single parameter minAxes is fully documented in the schema, including its default and meaning. The description adds no extra meaning about how minAxes affects the result set, so 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?

The description states a specific resource (Korean districts / 시군구) with a qualifier (where several kinds of data overlap), which is more precise than a bare 'list regions'. It does not, however, mention the sibling region_overview or distinguish scope from that tool, so sibling differentiation is missing.

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 'Check here first' implies a recommended entry point, which hints at when to use it, but no explicit when/when-not or named alternatives are given. An agent gets a soft suggestion rather than a clear routing rule.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds useful behavioral context the annotations cannot: the tool returns aggregated counts per dataset kind rather than records, which is exactly what an agent needs to know before calling it. No pagination or size limits are mentioned, though.

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 English text is front-loaded and every sentence earns its place: purpose, use context, return shape, and next step. The Korean line only partially restates the first sentence, which is intentional for a bilingual audience but does add mild duplication.

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?

There is no output schema, so the description carries the burden of explaining the return value, and it does so (counts per dataset kind). For a low-complexity two-parameter read tool this is nearly complete; only output ordering or empty-result behavior is left unstated.

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 both sido and sigungu (including its optionality and examples) are already documented in the schema. The description only restates that the unit is a Korean city/district, adding no new syntax or filtering semantics beyond baseline.

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: it reports what dataset kinds exist for one sido/sigungu and counts records per kind. It also implicitly separates itself from search_data by framing itself as the aggregate view that precedes record-level drilling.

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?

"Good as a first look before planning a trip or a site survey" gives a clear use context, and "then drill in with search_data" names the follow-up alternative. It never states when this tool is the wrong choice, so it stops short of a full 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 cover the safety profile (readOnly, idempotent, non-destructive). The description adds important behavioral context: it searches the entire catalogue including datasets that have not been loaded, implying results may be metadata rather than actual data. This is valuable beyond the annotations, though no return format or rate limits are mentioned.

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, front-loaded with purpose then usage. Bilingual repetition is minimal and serves a clear audience. Every 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 read-only search tool with full schema coverage and annotations, the description covers purpose, when to use, and what to expect ('whether such data exists at all and where to get it'). It lacks explicit details on result format or pagination, but these are minor given the absence of an output schema.

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 the schema already documents all three parameters with descriptions. The tool description adds no additional parameter semantics, so the baseline score 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 (search) and resource (entire data.go.kr catalogue), and explicitly distinguishes itself from the sibling search_data by including datasets not yet loaded. An agent can immediately tell what this tool does and how it differs.

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 an explicit trigger: 'Use it when search_data comes back empty,' names the alternative (search_data), and explains the goal (find out whether data exists and where to get it). This is a complete routing instruction with no ambiguity.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuine behavioral detail: how the query is parsed, that abbreviations work for regions, and that the interpretation is echoed in `interpreted` — non-obvious output behavior. No rate limits or ordering details.

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?

Front-loaded with purpose, then examples, then parsing semantics, then the routing cue. The bilingual duplication is deliberate for the audience, though it roughly doubles the text without adding new semantics.

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 search with no output schema, the description supplies the parsing contract and flags the `interpreted` echo field, which is what an agent most needs to trust results. Missing result ordering, pagination beyond `limit`, and returned-field shape, but the essentials are 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 100%, so baseline is 3. The description exceeds that by explaining the parsing model of `query` — a region word is read as an administrative area (abbreviations accepted) and the remainder is matched against record content and dataset names. `limit` is left to the schema, which documents it adequately.

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 ('Find') and resource ('Korean public-data records') scoped by region and topic, with concrete examples (Gangneung libraries, Jeju tourism). It is distinguishable from catalog-style siblings, but never names them, so an agent must infer the boundary against search_catalog/list_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?

'Use it for what-is-where questions' gives an implied usage context, and the examples hint at region+topic phrasing. However, with nine siblings including search_catalog and list_regions, no explicit when-not or alternative routing 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds meaningful context beyond them: the data is observational rather than predictive, it includes active weather warnings, and it originates from KMA ultra-short-term observation. It does not discuss refresh cadence or geographic resolution, but that is minor for a parameterless read.

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?

Content is front-loaded: what you get, the source, then the temporal limitation. It is efficient, with only mild redundancy from the bilingual English/Korean duplication.

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 input parameters and no output schema, the description carries the burden of conveying what comes back; it lists the returned quantities (temperature, humidity, wind, warnings) and the source. It stops short of explaining the return structure or geographic granularity (nationwide aggregate vs. per-region readings), 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?

The tool takes zero parameters, so the schema has nothing to explain and the baseline is 4. There is no input whose semantics require clarification.

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 resource (current Korean temperature, humidity, wind, in-effect weather warnings) with clear scope (nationwide, right now) and names the data source (KMA ultra-short-term observation). The explicit contrast with forecasts makes the tool unambiguously distinct from a predictive weather tool.

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 clear when-to-use (current observed conditions) and an explicit when-not (cannot answer about tomorrow / not a forecast). No sibling alternative is named, but no weather-forecast sibling exists among the listed tools, so the exclusion is effectively complete.

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