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

With no annotations, the description carries the burden of behavioral disclosure. It adds the key detail that output is raw/non-normalized and references get_dataset_spec for parameters, but it omits read-only behavior, error handling, or pagination 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?

The English sentence is concise and front-loaded with the main action. The Korean sentence is a direct translation that adds redundancy, though it is short and doesn't significantly harm clarity.

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

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

Given the absence of annotations and output schema, the description mentions raw rows and the spec-check prerequisite but does not clarify the tool's scope (generic for all catalog datasets) or return value structure. This is adequate but leaves gaps for an agent to fully understand behavior.

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 parameters are already documented with meanings (e.g., limit default/max, params order). The description adds only a dependency hint to get_dataset_spec, which is already referenced in the params schema, providing no additional semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Invoke') with a clear resource ('catalog dataset by id') and states the output ('RAW non-normalized rows'). It distinguishes itself from siblings like get_dataset_spec by emphasizing data invocation rather than metadata retrieval.

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

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

It explicitly instructs to 'check get_dataset_spec first for required params,' establishing a prerequisite for use. However, it does not explicitly contrast with alternatives like search_dataset or specialized getters, leaving some ambiguity about when to use this over them.

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?

No annotations are present, so the description carries the burden. It discloses that results include location, phone, and per-day operating hours (via Korean text) and that this is a read-only find operation, which is sufficient for an agent to understand side-effect-free behavior.

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

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

The description is compact: one English sentence, a Korean equivalent, and a usage example. It is front-loaded with the action and avoids fluff; the Korean portions serve local users without bloating the definition.

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 compensates by naming the main returned attributes (location, phone, hours) and giving a concrete example. It doesn't mention edge cases like empty results or combined filters, but for a simple optional-parameter search tool this is adequate.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds a natural-language summary of the district/name search and an example query, slightly enriching the schema by tying parameters to real user intents, though it does not add new constraints.

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 'Find', names the resource 'Seoul pharmacies', and specifies search criteria ('by district or name keyword') plus key output ('per-day operating hours'), clearly distinguishing it from generic sibling search_place.

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 an explicit use case with an example query ('What time does a Gangnam-gu pharmacy close?') and states the tool is for pharmacy-specific lookups. It does not explicitly name siblings as alternatives, so no full when-not-to-use list, but context is clear.

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?

With no annotations, the description carries the full behavioral disclosure burden. It reveals one key behavior: omitting the district parameter returns all 25 districts. It also notes that data is real-time and includes specific metrics (PM10/PM2.5, grade). However, it does not describe the output structure, error handling, or any broader behavioral traits, so transparency is adequate but not rich.

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 first sentence gives the core purpose, the second covers the optional scope, and the Korean text provides a usage example. Every sentence earns its place, and the structure is easy to scan. It is concise without being under-specified.

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 (one optional parameter, no output schema), the description is largely sufficient. It explains the tool's purpose, the data returned, and the option to fetch all districts. However, it does not specify the exact return format or any authentication/rate limits, which would improve completeness—though for a read-only, low-complexity tool, this is a minor gap.

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

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

The input schema already provides a full description for the 'district' parameter: '자치구명 (예: "강남구") — 생략 시 25개 전체', which covers the omit behavior. The tool description essentially repeats this with 'Omit district to get all 25', adding no new semantic information. Since schema coverage is 100%, the description's redundant repetition yields no extra credit.

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: 'Get real-time air quality (PM10/PM2.5, grade) for Seoul districts.' It clearly identifies the resource (Seoul districts) and the data captured (PM10/PM2.5, grade), and the clause 'Omit district to get all 25' further distinguishes it from sibling tools like get_weather or get_city_snapshot. This is a clear, unambiguous purpose.

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 a clear usage context: it is intended for air quality queries about Seoul districts, with the example question '"오늘 강남구 미세먼지 어때?" 류 질문에 사용.' This tells an agent when to invoke the tool. However, it does not mention when not to use it or name alternative tools, so it lacks explicit exclusions.

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 behavioral details such as 'real-time available bike counts' and 'location-based works via name keyword matching.' However, it does not clarify how lat/lng and radiusM interact, what happens when both query and coordinates are provided, or what the response structure is. Given no annotations, more disclosure is needed.

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 relatively concise, using two sentences. There is some bilingual redundancy, but the Korean note adds a behavioral clarification. It is front-loaded with the main purpose and does not waste words.

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

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

The description covers the primary purpose and real-time counts, but it does not explain the response format, default behaviors, or parameter interactions. Since there is no output schema, the description should better describe what the returned data contains. The gap is moderate but notable.

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 covers all 5 parameters with descriptions (100% coverage), so the description does not need to repeat them. It adds a query example ('강남역') and clarifies that query is a name keyword, but this is marginal beyond the schema. Baseline 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 clearly states 'Find Seoul public bike stations by name keyword and/or coordinates, with real-time available bike counts.' This specifies the verb, resource, and outcome, and the focus on bike stations distinguishes it from sibling location 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?

The description implies usage for bike station queries by stating its purpose, but it does not explicitly mention when to use this tool versus alternatives like search_place or get_city_snapshot. It provides context through 'real-time available bike counts' but lacks exclusions or explicit alternative guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is a 'ONE call' snapshot, implying aggregation, but does not disclose potential caveats such as data freshness, rate limits, failure behavior on invalid places, or whether the response is real-time or cached. The description focuses on capabilities rather than 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?

The description is concise and front-loaded, with the core purpose in the first sentence and usage guidance in the second. The Korean sentences that follow largely repeat the English content, introducing some redundancy but also serving localization. Every sentence contributes, though the bilingual duplication prevents a perfect score.

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 must convey the return contents. It lists the categories (population/congestion, weather, road, top events) but leaves terms like 'population/congestion' and 'top events' ambiguous (top by what? congestion of traffic or people?). Given the tool aggregates multiple data sources, more detail about the combined response structure would improve completeness.

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 has 100% coverage for the single 'place' parameter, with a description '핫스팟 장소명' (hotspot place name). The tool description adds a concrete example ('지금 홍대 어때?') and clarifies the scope is 'Seoul hotspot', reinforcing the meaning. However, it does not add significant additional semantics beyond the schema, matching the 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?

The description clearly states the tool's purpose with a specific verb ('Get a combined snapshot') and resource ('of a Seoul hotspot'), and explicitly enumerates the combined content ('population/congestion + weather + road + top events'). It is easily distinguished from siblings like get_weather or get_road_traffic, which cover individual data types.

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

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

The description provides explicit usage guidance: 'Prefer this for broad "how is X right now?" questions.' It also includes a Korean equivalent, reinforcing the context. However, it does not explicitly name alternative tools or state when NOT to use it, though the sibling list makes the alternatives implicit.

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?

With no annotations, the description carries the full burden. It discloses the real-time nature, the data source (신한카드 실시간 결제 기반), the output granularity (4 levels and per-industry breakdown), and the supported scope (82 places). It does not detail error handling or return format, but the provided traits are substantial for a read-only retrieval tool.

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

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

The description is concise and front-loaded: one English sentence describes the core function and scope, followed by two short Korean phrases for data source and usage example. Every clause earns its place with no redundancy or 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 single-parameter read tool with no output schema, the description provides key completion details: return content (activity level and industry breakdown), supported scope (82 places), and an example user question. It could mention unsupported place behavior, but the overall context is adequate for selection and 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 input schema already has 100% coverage: the 'place' parameter description says '핫스팟 장소명 (상권은 82곳만 지원)'. The tool description repeats this ('Seoul hotspot (82 supported places)') but adds no new parameter-level meaning beyond the schema, so the 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 starts with a specific verb 'Get' and clearly defines the resource: 'real-time card-payment based commercial activity level' with a 4-level scale and 'per-industry breakdown for a Seoul hotspot (82 supported places).' This clearly distinguishes it from sibling tools like get_population or get_city_snapshot by naming the data source and specific output.

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

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

It gives concrete usage context: 'Seoul hotspot (82 supported places)' and a Korean example query '지금 성수동 장사 잘돼?' (Is business good in Seongsu-dong right now?). This implies when to use it, though it does not explicitly name alternative tools or edge-case exclusions.

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?

With no annotations, the description carries the burden of behavioral disclosure. 'Get' clearly implies a read-only operation, and listing the returned spec elements (path parameters, response fields, call example) gives useful context. However, it does not disclose error behavior, authentication requirements, or the fact that this is metadata rather than an actual data call, leaving some gaps.

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-loaded with the key information. However, the second sentence in Korean largely repeats the first sentence's meaning, which is redundant for an AI agent. It is still efficient, but not every word 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the essential aspects: what it returns, and when to use it. It does not explain return formatting or error conditions, but that is not critical for a straightforward spec-fetching tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only mentions 'catalog dataset id' in passing and does not add semantic detail beyond what the schema already provides for the 'id' parameter. It adds no additional meaning about the parameter's format or usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and a clear resource 'dataset call specification', explicitly listing the return contents (path parameters, response fields, call example). It distinguishes itself from sibling data-retrieval tools by referencing call_dataset, indicating it is a preparatory metadata 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?

The description provides explicit when-to-use guidance: 'call_dataset 호출 전' (before calling call_dataset) and '확인합니다' (check). It implies this tool is for pre-call preparation, but it does not mention exclusions or alternative tools, so it lacks a full when-not-to-use clause.

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?

No annotations are provided, so the description must carry the burden. It indicates a read operation fetching text alerts, but does not disclose details like time window, response format, or any limitations. This is minimal but not contradictory.

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-loaded, but includes some redundancy: the English sentence and Korean sentence say the same thing. The usage example adds value, but the duplicate translation could be trimmed.

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-parameter tool with no annotations or output schema, the description appropriately conveys the core function and typical usage. It does not describe the return value structure, but that gap is minor for a getter of text alerts.

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 only parameter 'place' has a schema description ('핫스팟 장소명'). The tool description adds little beyond that, just using the term 'hotspot area'. With 100% schema coverage, baseline 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 clearly states it retrieves recent emergency disaster text alerts for a Seoul hotspot area. This is distinct from all sibling tools which cover other location-based data (population, traffic, weather), making the purpose unambiguous.

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 includes a concrete example query ('지금 재난문자 온 거 있어?' - 'Is there a disaster text right now?') that signals when to use this tool. It does not explicitly mention alternatives or when not to use, but the use case is clear.

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?

No annotations are present, so the description carries the burden of behavioral disclosure. It reveals a key trait: the data is de-facto (living) and not real-time, implying a delay. However, it does not mention return format, authentication, rate limits, or pagination, leaving some transparency gaps. The non-real-time distinction is valuable but not exhaustive.

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 succinct sentences: the first states the core purpose, the second (Korean) provides a crucial usage exclusion. No filler, front-loaded, and perfectly sized for an agent to scan quickly.

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 has four optional parameters and no output schema, and the description provides enough context for selection: what data it returns, the key non-real-time caveat, and the sibling alternative. Minor omissions—behavior when no parameters are supplied or what the response looks like—prevent a perfect score, but overall it is well contextualized.

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%—each parameter already has a description (e.g., date format, timeSlot pattern, dongCode usage). The description mentions 'by administrative dong and hour' which maps to dongCode and timeSlot, but adds little beyond what the schema already provides. Thus 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?

Description uses a specific verb 'Get' and names the resource: de-facto (living) population estimates by administrative dong and hour. It clearly distinguishes from sibling get_population by explicitly stating this is not real-time, making its scope unambiguous.

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 an explicit exclusion and alternative: '실시간 아님 — 실시간 혼잡은 get_population 사용' (not real-time, use get_population for real-time congestion). This tells the agent exactly when to choose this tool over the sibling tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the schema by noting the real-time nature and the limitation to 122 linked parking lots ('실시간 연계 122곳 한정'). It also clarifies that keyword matching applies to lot name and address. This is strong for a read-only tool, though it does not describe return format or error behavior.

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

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

The description is compact and front-loaded: a clear English sentence, a Korean restatement with a key limitation, and a concrete usage example. Every sentence contributes value, with no redundancy or 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 two-parameter read tool with no output schema, the description covers the essential aspects: purpose, filtering behavior, limitation, and usage context. It does not explicitly describe the return format, but the tool name and phrasing 'available spaces' make this fairly clear. Minor gaps remain around result ordering or no-match behavior, but overall it is 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?

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning for the query parameter by specifying that it matches against 'lot name and address,' which is not in the schema description. This additional semantic nuance justifies a score above 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?

The description clearly states the tool's function: 'Get real-time available spaces in Seoul public parking lots, filtered by place/district keyword matched against lot name and address.' It uses a specific verb and resource, and the mention of keyword-based filtering distinguishes it from sibling tools like get_bike_stations or search_place.

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 includes an explicit usage example: '"종로 주차 자리 있어?" 류 질문에 사용.' This provides clear context for when to apply the tool, but it does not mention alternatives or explicitly state when not to use it, so it falls short of 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It transparently describes the operation as a query ("조회합니다") and lists the returned data types: real-time population, congestion level, demographics, and optional forecast. It does not mention limitations like stale data or error behavior, but for a read-only lookup, this is reasonably complete.

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: two sentences (one English, one Korean) plus a usage example. It front-loads the core purpose, includes a bilingual summary, and gives a concrete user query example—all without fluff. 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?

Given no output schema, the description sufficiently explains what the tool returns (population, congestion, demographics, forecast). It also clarifies the optional forecasting behavior. However, it does not explain return format, error handling, or the need for a validated place (though that is in the schema). For a simple 2-param read tool, it is mostly 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% with detailed parameter descriptions for 'place' (recommending search_place) and 'includeForecast' (default false). The tool description adds further context that the forecast is a '12-hour AI forecast', enhancing understanding beyond the raw schema. This exceeds the baseline for high 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 what the tool does: 'Get real-time population, congestion level (여유/보통/약간 붐빔/붐빔), demographics, and optional 12-hour AI forecast for a Seoul hotspot.' This specific verb+resource combination distinguishes it from siblings like get_living_population and get_city_snapshot by focusing on hotspot congestion with demographic data.

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

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

The description provides when-to-use context with the Korean query example ("지금 강남역 혼잡해?" 류 질문에 사용) and recommends using search_place to confirm the place name. However, it does not explicitly state exclusions or alternatives, so it lacks complete when-not-to-use guidance.

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

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

With no annotations, the description must carry the behavioral burden. It adds useful details like the geographic scope (Seoul), price unit, and filterability. However, it doesn't specify return format, property types (e.g., apartments vs. all types), sorting, or default behavior when no filters are provided, leaving some ambiguity.

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. The main verb and resource appear first, followed by a parenthetical unit note and filtering possibilities. The Korean title and usage example are efficient and directly relevant, with no wasted words.

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 query tool with no output schema, the description is reasonably complete but leaves gaps. It doesn't clarify whether results are limited to apartments, what the default scope is when no filters are given, or what fields are in the output. The schema helps with parameters but not with return semantics.

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% with each parameter described. The description mentions filterable by district/dong/year, which mirrors the schema but adds little new meaning. It doesn't explain nuances like the limit parameter or combinations of filters, so the baseline 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 clearly states the tool's function with a specific verb and resource: 'Get Seoul real-estate sale transaction records'. It also mentions the price unit (만원) and filter criteria, making it distinctly different from sibling tools like get_weather or get_population.

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 a concrete usage example in Korean: 'Use for questions like "Gangnam-gu apartment real transaction price?"'. This gives clear context for when to use the tool, although it doesn't explicitly enumerate exclusions or alternative tools.

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation through the verb 'Get' and describes the returned data (speed, congestion, incidents). It does not mention side effects, permissions, or error behavior, but for a straightforward data-retrieval tool, this is reasonably transparent.

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 brief and front-loaded with the main function. It includes a Korean translation and an example, all in about 30 words. The translation is somewhat redundant for English speakers but does not bloat the description excessively. Overall, it is concise and well-structured.

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 tool with one parameter and no output schema, the description covers the essential context: what data is returned, the geographic scope, and a usage example. It does not mention output format or data freshness, but these are not critical for understanding how 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 input schema describes the parameter 'place' as '핫스팟 장소명' (hotspot place name). The description adds significant meaning by specifying 'around a Seoul hotspot' and giving an example (Gwanghwamun), clarifying the geographic scope and what kind of place is expected. This goes beyond the schema's minimal description.

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: 'Get average road speed, congestion message, and accident/control incidents around a Seoul hotspot.' It specifies a concrete verb (Get), the data returned, and the geographic scope. This clearly distinguishes it from sibling tools like get_disaster_alerts or get_weather.

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 a specific usage example: '"광화문 근처 길 막혀?" 류 질문에 사용' (use for questions like 'Is the road near Gwanghwamun blocked?'). This gives clear context on when to use the tool. However, it does not explicitly mention when not to use it or suggest alternative tools, so it stops short of a perfect score.

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?

No annotations are provided, so the description carries the full burden. It discloses input formatting rules (omit '역' suffix, use '서울' for '서울역') and offers a Korean usage example, which is useful. However, it does not disclose error behavior (e.g., unknown station) or response format, leaving some ambiguity for a tool that likely returns real-time data with limited context.

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

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

The description is short and front-loaded: the English purpose statement comes first, followed by a usage hint in English, then the same information is repeated in Korean along with a sample query. The repetition is somewhat redundant (English and Korean say similar things), but the overall length is appropriate and each sentence contributes to usability.

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 (two params, no output schema). The description covers the core purpose and input format but omits what the response looks like (e.g., next train times, directions, count). Given no output schema, the description could have disclosed return value structure or note that data is real-time and may vary. It is adequate for invocation but not fully complete for setting expectations.

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 station and limit are described). The description adds an English-language rule about omitting the '역' suffix and gives an explicit example ('강남'), which complements the Korean schema description. It also clarifies the station parameter's intended value in a way that is accessible to non-Korean speakers, adding meaningful semantic context 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 starts with a clear verb and resource: 'Get real-time subway train arrivals for a Seoul station.' This precisely states the tool's function and distinguishes it from siblings like get_subway_ridership (ridership statistics vs. live arrivals). The added example and Korean usage hint reinforce specificity.

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 concrete guidance: 'Pass the station name WITHOUT the "역" suffix if possible (e.g. "강남").' and includes a sample query in Korean ("2호선 강남역 열차 언제 와?") to indicate the intended use case. While it does not explicitly list alternatives or when-not-to-use, the real-time scope and contrast with siblings like get_subway_ridership imply appropriate usage.

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?

No annotations are provided, so the description carries the burden. It discloses the data availability lag (2-4 days ago) and describes the output as per-station boarding/alighting counts. It does not mention operational details like rate limits, but for a read-only data lookup this is sufficient.

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 somewhat repetitive with the bilingual phrasing (English and Korean) and an example query, but it remains compact and front-loaded with the core action. It earns a 4 for being efficient despite minor redundancy.

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 and no annotations, the description provides sufficient context for an agent to understand what the tool returns and its limitations. It could explicitly list return fields, but 'boarding/alighting counts' and station/line filters are clear enough for a data retrieval tool.

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

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

Input schema has 100% coverage with descriptions for all 4 parameters (date pattern, line partial match, limit range, station partial match). The description adds a usage example but no additional parameter semantics beyond what the schema already provides, so baseline 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?

Description uses a specific verb 'Get' and resource 'per-station daily subway boarding/alighting counts for a date', which clearly distinguishes from siblings like get_subway_arrivals by focusing on daily boarding/alighting instead of real-time arrivals.

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: data available up to 2-4 days ago and an example query for daily passenger counts. It does not explicitly exclude real-time use or name alternatives, but the phrasing implies historical ridership queries rather than live arrivals.

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?

No annotations are provided, so the description carries the full burden. It clearly states that the tool returns current conditions and lists all included data types. It also specifies the geographic scope (Seoul hotspot). This is adequate for a simple, read-only weather tool, though it doesn't mention units or handling of unknown places, which are minor gaps.

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 core purpose. It includes both English and Korean versions, which is slightly redundant but the Korean portion adds the example use case. Overall, every sentence contributes value without excessive length.

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 tool with one parameter and no output schema, the description is sufficiently complete. It enumerates all returned data fields, specifies the geographic context, and gives an example query. It doesn't describe the return format in detail, but the list of attributes compensates for 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?

The schema describes the only parameter 'place' as '핫스팟 장소명' (hotspot place name), and the description adds 'Seoul hotspot' and an example ('여의도'). This gives the agent a clear understanding of what values to provide, going beyond the schema's minimal description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb 'Get' and specifies the resource: current weather data including temperature, precipitation, fine dust, UV, sunrise/sunset, and weather warnings for a Seoul hotspot. This detailed list makes the tool's purpose unambiguous and distinguishes it from sibling tools like get_air_quality, which focuses only on air quality.

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: 'for a Seoul hotspot' and includes a concrete example question, '지금 여의도 날씨 어때?' (What's the weather in Yeouido now?). While it doesn't explicitly exclude alternatives like get_air_quality, the example and wording strongly imply use for general weather inquiries, giving reasonable guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool can handle natural-language-style questions and supports filtering by multiple criteria. However, it does not explain the return format, default behavior with no parameters, or data source, which would add further 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 compact and front-loaded with a clear English sentence, followed by a Korean translation and an example. The Korean translation is redundant since it mirrors the title, but the example adds value and the overall length is appropriate.

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 search tool with 7 optional parameters and no output schema, the description provides a solid overview including event categories, filter dimensions, and an example use case. It could be enhanced by mentioning default result limits or the nature of events covered, but it is adequate for invoking the tool.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description groups parameters into meaningful categories (keyword/category/district/date-range/free-only), which adds a useful high-level overview, but it does not add semantics beyond what the schema already provides for each 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?

The description clearly states the tool searches Seoul cultural events, listing specific event categories (concerts, exhibitions, festivals) and filter dimensions (keyword, category, district, date-range, free-only). This is specific and easily distinguishable from sibling tools like search_place or get_weather.

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 includes a concrete example query ('이번 주말 마포구 무료 공연 있어?' meaning 'Is there a free performance in Mapo-gu this weekend?') which illustrates a natural language usage scenario. It does not explicitly name alternative tools or state when not to use it, but the domain is clear enough and distinct from siblings.

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

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

No annotations are present, so the description carries the transparency burden. It discloses the catalog size, the routing behavior to dedicated tools, and the fallback to call_dataset. This is useful contextual behavior beyond a basic search, though it doesn't specify the response 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 description is compact, but the Korean sentence partly repeats the English sentence. However, it also adds the call_dataset instruction, so each sentence contributes something distinct.

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

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

For a simple search tool with one parameter and no output schema, the description provides sufficient context: it names the catalog, explains the routing logic, and points to the alternative for tools without dedicated access. Minor omission is the result format, but not critical.

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

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

The schema covers 100% of the query parameter with a Korean description and examples. The description adds no extra parameter-level detail, so the 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 clearly states it searches a curated catalog of 28 Seoul Open Data datasets by keyword, which is a specific verb-resource pair. It also distinguishes from siblings like search_place and search_cultural_events, which search different types of data.

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

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

Explicit guidance is provided: entries with a dedicated tool point you to it, and data without a dedicated tool should be accessed via call_dataset. This clarifies when to use this tool versus the alternatives.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool maps to a fixed set of 121 official real-time hotspots, implying a constrained resolution rather than a general search. However, it does not describe what happens on no match, the output format, or any other behavioral edge cases, leaving a significant gap.

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 key purpose clear in the first sentence. However, it includes a bilingual repetition of the same message in Korean, which adds length without new information. A single-language description would have been more efficient, so not 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?

This is a simple one-parameter tool with no annotations and no output schema, so the description needs to cover core behavior and return expectations. It correctly explains the purpose and scope (matching to 121 hotspots) and gives usage guidance, but it lacks any description of the return value or failure behavior. Given the absence of an output schema, this is a meaningful gap, though the tool is simple enough that the description is not fatally inadequate.

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 already documents the 'query' parameter with examples (100% coverage), so the baseline is 3. The description adds semantic value by characterizing the input as 'free-form place name' and '자연어 장소명' (natural language place name), clarifying that it accepts natural language phrasing rather than structured identifiers. This goes beyond the schema's mere label.

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: 'Resolve a free-form place name to one of Seoul's 121 official real-time hotspots.' This specifies a concrete verb ('Resolve') and a well-defined resource (Seoul's 121 official hotspots), distinguishing it from the many data-fetching sibling tools like get_subway_arrivals or get_weather.

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

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

The description provides explicit usage guidance: 'Use FIRST when the user mentions a Seoul location.' This tells the agent exactly when to invoke this tool, but it does not name specific alternative tools or state when not to use it, so it stops short of the full 'when/when-not/alternatives' criterion.

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