Who qualifies for 10,956 Korean government benefits (보조금24). Plus public data and weather.
Scored across 10 tools
The three benefits tools are clearly separated by role: codebook defines inputs, match finds candidates, and detail explains applications. search_data and search_catalog are also distinguished by loaded-data vs full-catalog, though list_datasets, list_regions, and region_overview have some overlapping inventory-like behavior.
All names use snake_case and several follow clear patterns such as benefits_*, list_*, and search_*. However, tools like demand_rank, region_overview, and weather_now do not follow the same verb_noun structure, making the naming convention mixed but still readable.
Ten tools is not inherently excessive, but only three of them serve the server's stated Korea Benefits Eligibility purpose. The other seven tools cover unrelated public-data search, weather, and demand ranking, making the tool surface feel padded and off-scope.
The core benefits eligibility workflow is reasonably covered: match returns candidate programs, detail provides application guidance, and codebook explains classification values. However, there is no direct keyword/name search for benefits, and the unrelated subdomains are only partially covered, so the overall surface has noticeable gaps.
The full list of classification values used for eligibility matching, with what each means. Read this when you do not know what to put into benefits_match. / 자격 판정에 쓰는 분류 값의 전체 목록과 뜻.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
See how to apply for one benefit programme: what it provides, the application deadline, required documents, contact point and the law it rests on. Use the id returned by benefits_match. / 지원내용·신청기한·구비서류·문의처·근거법령을 봅니다.
| Name | Required | Description | Default |
|---|---|---|---|
| serviceId | Yes | benefits_match 결과의 서비스ID |
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.
Find Korean government benefit programmes a person may be eligible for. Filters all 10,956 original records of the Ministry of the Interior and Safety Bojogeum24 registry by age, income bracket, household type and personal traits. A programme that does not state a condition is treated as UNRESTRICTED, not as excluded — so the fewer conditions you give, the more results you get. WARNING: the final entitlement decision belongs to the administering agency. This is a candidate list. / 보조금24 원본 10,956건에서 자격 조건으로 걸러 줍니다. 최종 수급 여부는 소관 기관이 정합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years. Omit to apply no age condition. / 나이(만). 생략하면 조건을 걸지 않습니다 | |
| limit | No | Max records (default 20). / 최대 건수(기본 20) | |
| gender | No | Gender (optional). / 성별. 생략 가능 | |
| income | No | Household median-income bracket. OMIT it if you do not know — guessing drops programmes that would have matched. / 모르면 생략하십시오. 찍으면 맞는 제도가 빠집니다 | |
| offset | No | How many to skip (pagination). / 건너뛸 건수(페이지네이션) | |
| traits | No | Personal traits (multiple allowed): life stage, occupation, school level, health. / 대상 특성(복수 가능) | |
| household | No | Household types (multiple allowed). / 가구 유형(복수 가능) |
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.
Search-demand ranking. It is an index relative to an anchor (libraries), NOT an absolute search volume. Use it to compare what people look for more, for market or topic research. / 검색 수요 순위. 앵커 대비 상대 지수이며 절대 검색량이 아닙니다. 시장·주제 조사에서 무엇을 더 많이 찾는지 비교할 때 씁니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records (default 30, max 500). / 최대 건수 | |
| heldOnly | No | Keep only topics we actually hold data for. / 우리가 실제로 자료를 가진 주제만 추립니다 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the key behavioral fact that it is a relative index, not absolute, which is useful. However, it does not disclose output format or how to interpret rank values.
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 front-loaded with the most important caveat (relative vs absolute). Every sentence earns its place, and the bilingual repetition is not redundant—it serves the same message efficiently.
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 no output schema, the description does not explain what the return value looks like (e.g., sorted list, rank score meaning). Also, the anchor is mentioned as 'libraries' but no parameter exists to change it, leaving a potential gap in how an agent would use 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 input schema provides complete descriptions for both parameters (limit and heldOnly) at 100% coverage. The tool description adds nothing beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: it ranks search-demand, and crucially clarifies it is a relative index anchored to libraries, not an absolute volume. This distinguishes it from sibling search tools like search_data and search_catalog.
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 a clear use case: to compare relative search interest for market/topic research. It also warns against treating it as absolute search volume, implicitly telling the agent when not to use it, though it does not name an explicit alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The datasets we have actually loaded, with record counts. Check what we can answer from. / 실제로 적재해 둔 자료 목록과 건수입니다. 무엇으로 답할 수 있는지 확인할 때 씁니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Part of a dataset name (optional). Empty means the full list. / 자료 이름 일부(선택) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the call as read-only, idempotent, and non-destructive. The description adds the useful behavioral detail that it returns only locally loaded datasets with record counts, which goes beyond the annotations and is not contradicted.
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 core statement is one short sentence and is front-loaded in English. The Korean translation repeats the same content, adding a little length, but the overall description is compact and every clause contributes meaning.
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 zero-required-parameter tool with strong annotations, the description covers what it returns, its scope, and why to call it. It does not spell out the exact output shape, but the list-with-counts description is sufficient for correct invocation.
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 single optional query parameter is already fully described in the schema, including that empty means the full list. The description adds no additional parameter-level meaning, so the schema-coverage baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: listing the loaded datasets and their record counts. It also differentiates from siblings like search_catalog and search_data by emphasizing that only actually loaded data is included, so an agent can tell this tool apart from the search-oriented tools.
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 use context: use this when checking what data is available to answer from. It does not explicitly name alternatives or say when not to use it, but the 'actually loaded' framing provides enough context to route an agent appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Korean districts where several kinds of data overlap. Check here first to see which regions we can actually answer about. / 자료가 여러 종류 겹쳐 있는 시군구 목록입니다. 어느 지역에 대해 답할 수 있는지 먼저 확인할 때 씁니다.
| Name | Required | Description | Default |
|---|---|---|---|
| minAxes | No | Minimum number of overlapping dataset kinds (default 2). / 최소 자료 종류 수 |
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 useful behavioral context by explaining that results are limited to regions with overlapping dataset kinds, but it does not disclose output format, ordering, or threshold behavior beyond what the schema already says.
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 description is compact and front-loaded with the core meaning, and the Korean translation is helpful for the domain. It is slightly redundant because the Korean sentence repeats the English content, but the overall length is appropriate and every core idea 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 simple read-only list tool with one optional parameter and rich annotations, the description is largely complete: it defines the resource, the filter criterion, and the intended first-step usage. It does not specify the exact return shape, but the absence of an output schema is less critical given the low complexity.
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 single minAxes parameter is already documented as the minimum number of overlapping dataset kinds. The description's mention of 'several kinds of data overlap' loosely aligns with this parameter but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's resource (Korean 시군구 districts) and its specific purpose: listing regions where multiple dataset kinds overlap. It also frames the tool as a first-check for answerable regions, which distinguishes it from sibling tools like list_datasets or region_overview.
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 to see which regions we can actually answer about' provides explicit usage context and tells the agent when to call this tool. It does not name alternatives or state when not to use it, but the placement cue is strong enough for a clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See at a glance what kinds of data we hold for one Korean city or district, and how many records of each. Good as a first look before planning a trip or a site survey. Returns counts per dataset kind, so you can then drill in with search_data. / 한 시군구에 어떤 자료가 몇 건씩 있는지 한눈에 봅니다. 여행 계획이나 현장 조사 전에 먼저 훑어볼 때 씁니다. 자세한 레코드는 search_data 로 이어서 찾습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| sido | Yes | Province or metropolitan city, e.g. Jeju. / 시도 | |
| sigungu | No | City or district (optional), e.g. Jeju-si. / 시군구 (선택) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds behavioral value by stating the output is counts per dataset kind and that it serves as a precursor to search_data. It does not go into detail about what happens when sigungu is omitted, but that is a minor gap given 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?
Two concise English sentences, each earning its place: the first defines purpose and output, the second gives usage context and a pointer to the next step. The Korean translation is redundant but not harmful and is a common practice for regional tools. No filler 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?
The description clearly covers the return type (counts per dataset kind) and directs to search_data. However, the optional sigungu parameter is not explained behaviorally: the description implies a single city/district, but does not state what happens when sigungu is omitted (e.g., province-level rollup). This is a meaningful gap for correct invocation, but not severe given the tool's simplicity and the schema's note that sigungu is optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both parameters (sido and sigungu) have clear descriptions in the schema. The description only adds the phrase 'one Korean city or district' which aligns with the schema but does not provide extra syntax or format details. Baseline 3 is appropriate as the schema already carries the parameter semantics.
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-resource pair: 'See at a glance what kinds of data we hold for one Korean city or district, and how many records of each.' It also clearly differentiates from search_data by stating it returns counts per dataset kind rather than detailed records, making the tool's role unmistakable.
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 explicitly provides usage context: 'Good as a first look before planning a trip or a site survey.' It also names the alternative tool and directs the agent to it: 'so you can then drill in with search_data.' This gives clear when-to-use and follow-up guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the entire data.go.kr catalogue — INCLUDING datasets we have not loaded yet. Use it when search_data comes back empty, to find out whether such data exists at all and where to get it. / 공공데이터포털 대장 전체 검색. 아직 적재하지 않은 자료도 나옵니다. search_data 결과가 비었을 때, 그런 자료가 있기는 한지와 어디서 받는지 확인할 때 씁니다.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | API | FILE | LINKED | STD (optional) / 자료 유형(선택) | |
| limit | No | Max records (default 20, max 200). / 최대 건수 | |
| query | Yes | Text to match against dataset names. / 자료 이름으로 찾을 말 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context beyond that: it searches a broader universe than loaded datasets and indicates that results point to where the data can be obtained. It does not describe output structure or pagination, but the annotation coverage lowers the burden.
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: the core scope appears in the first sentence, followed by usage guidance. The bilingual repetition adds length but does not obscure the message; it remains well-structured and to the point.
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 fully documented parameters and clear sibling differentiation, the description covers the essential semantics: what is searched, when to use it, and what the results reveal. The lack of an output schema is partially offset by stating that results indicate existence and source, though a bit more return-format detail would make it fully 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%, so query, type, and limit are already documented in the input schema. The description adds overall scope context but does not enrich individual parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Search the entire data.go.kr catalogue — INCLUDING datasets we have not loaded yet.' It also differentiates itself from sibling search tools by explicitly invoking search_data and contrasting scope, so an agent can tell them apart without opening the 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?
Gives an explicit trigger condition: 'Use it when search_data comes back empty, to find out whether such data exists at all and where to get it.' This names the alternative tool and the exact scenario where this tool should be selected, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Korean public-data records by region and topic. Examples: Gangneung libraries, Busan Jung-gu parking, Jeju tourism. A region word is read as an administrative area (abbreviations work); the rest is matched against record content and dataset names. The response echoes exactly how it was read in interpreted. Use it for what-is-where questions. / 지역과 주제로 공공데이터 레코드를 찾습니다. 예: 강릉 도서관 · 부산 중구 주차장 · 제주 관광. 「어디에 무엇이 있나」를 물을 때 씁니다. 해석 결과는 interpreted 에 밝힙니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records (default 20, max 200). / 최대 건수 | |
| query | Yes | What to find. Region plus topic works best, e.g. Suwon library. / 찾을 말. 지역 + 주제 형태를 권장합니다. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, it explains parsing behavior: region words are read as administrative areas, abbreviations work, and the rest of the query is matched against record content and dataset names. It also discloses the `interpreted` echo, which is valuable for verifying how the query was understood.
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 with the main purpose, examples, parsing behavior, and use case. The Korean translation duplicates the same content without adding new information, slightly padding the description, but the overall length is still compact and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, it covers query format, interpretation behavior, examples, and a way to verify interpretation via `interpreted`. It could briefly describe the shape of returned records, but nothing essential for correct invocation 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?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantic detail for the query parameter: administrative-area interpretation, abbreviation support, and matching targets. It adds nothing about limit, but that parameter is already self-explanatory in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: find Korean public-data records by region and topic, with concrete examples (Gangneung libraries, Busan Jung-gu parking, Jeju tourism). It does not explicitly differentiate itself from the sibling search_catalog, which keeps it from a 5.
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 clear usage context: 'Use it for what-is-where questions' and recommends a region-plus-topic query shape. It does not state when not to use it or name alternatives, but the use case is explicit enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current nationwide Korean temperature, humidity and wind, plus weather warnings that are IN EFFECT RIGHT NOW. Based on the KMA ultra-short-term observation. These are observations, not a forecast, so it cannot answer about tomorrow. / 기상청 초단기실황 + 현재 발효 중인 특보. 예보가 아니라 관측값입니다. 지금 날씨·특보를 물을 때 씁니다(내일 날씨는 답하지 못합니다).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds genuinely useful context beyond annotations: the KMA ultra-short-term observation data source, the observation-vs-forecast semantics, nationwide scope, and the 'right now' temporal guarantee. Minor gap: no mention of update latency or output format.
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 portion is two tight sentences with the purpose front-loaded and the limiting exclusion second. The bilingual Korean repetition adds length and is somewhat redundant for an LLM agent, though it increases accessibility for Korean users. Overall efficient and well-structured, with a slight redundancy cost.
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, read-only tool, the description is nearly complete: it lists returned data elements (temperature, humidity, wind, warnings), scope, source, and temporal semantics. With no output schema present, it stops short of describing return format or units, but the agent knows what kind of data to expect and what questions it can answer.
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, so the schema covers 100% of parameter documentation. Baseline 4 applies because there is nothing for the description to add — no parameter names, defaults, or constraints exist to explain. The description appropriately focuses on behavior instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and scope: nationwide Korean current temperature, humidity, wind, and active warnings from KMA observations. It explicitly distinguishes itself from a forecast tool ('not a forecast', 'cannot answer about tomorrow'), and none of the sibling tools overlap with weather, so an agent can identify its job 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?
The description gives an explicit when-to-use ('use when asking about current weather/warnings') and an explicit when-not-to-use ('cannot answer about tomorrow's weather'). The Korean sentence states the usage condition directly, and the exclusion of forecast questions is unambiguous even though no alternative weather tool exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
benefits_codebookbenefits_detailbenefits_matchdemand_ranklist_datasetslist_regionsregion_overviewsearch_catalogsearch_dataweather_nowKorean government open data - weather, population, law search via data.go.kr
Nationwide Korea: bus stops in 138 cities, 30-year climate normals, tourism (KR/EN).
Access Korea’s G2B procurement and Nara Market data for bid notices, awards, contracts, statistics…
Korean business, parcel and simple-auth employment, income, pension, license and health data
Add one secure layer between your agents and this server.