Korea Travel Demand & Price Archive (요즘인기여행)

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the data is a 7-day rolling purchase count scraped daily from Naver, the ranking is externally determined, and each row carries share %, typical nights, and a 30-day median comparison. It does not cover freshness lag or update timing, but the added context is substantial.

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 statement is front-loaded and dense with no filler, followed by a faithful Korean mirror for the Korean-language audience. The bilingual duplication doubles the length, but the content is non-redundant in meaning and each sentence carries information.

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 properly compensates by enumerating the returned fields (share %, typical nights, 30-day median comparison) and the aggregation level. The main remaining gap is the relationship between the limit parameter and pagination/ordering, but for a simple two-parameter read tool this is nearly complete.

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

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

Schema description coverage is 100% and the enum parameter carries its own Korean description, so the schema does the heavy lifting. The description echoes the city-vs-country dimension but adds no syntax, default, or format detail beyond what the schema already states, making 3 the correct 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 names a specific resource (a daily demand index for Korean outbound package tours) and states precisely what is measured and how (sum of 'N people bought in the last 7 days' shown on Naver package-tour product pages, aggregated to city/country). It also disclaims the ranking authority ('Ranking is set by Naver buyers, not by us'), which cleanly separates it from sibling tools like get_tours or list_popular_packages.

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 makes the tool's domain obvious (demand ranking data) so usage is implied, but it never states when to pick it over get_tours, list_popular_packages, or get_series_history, nor any exclusions or prerequisites. No explicit when/when-not guidance is present.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds meaningful provenance context: MyRealTrip comes from an official API while Trip.com and Agoda are read from search screens (method=screen). It also discloses the deliberate no-'cheapest'-judgement behavior, which is real behavioral information beyond 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?

The English sentence is front-loaded and information-dense, but the entire content is then repeated near-verbatim in Korean, doubling the length with no new information for an agent. That duplication dilutes an otherwise tight description.

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 does the work of explaining what comes back: three seller values as-is plus a 30-day median comparison, with no cheapest ranking. That is nearly complete, though exact response shape or handling of unavailable sellers is left unstated.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces the fixed same-date methodology but adds no syntax or format detail beyond what the city/all_dates descriptions already provide, 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?

States a specific verb and resource — direct round-trip economy fare from Incheon — plus concrete scope (1 adult, same dates, Friday departure, three named sellers). An agent can distinguish this from get_hotel_prices, get_tours, or get_demand_index without opening any 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?

'For a popular city' hints at applicability but no explicit when/how condition or named alternative is given, and none of the siblings are referenced. The 3-seller same-date constraint is described, but the agent must infer when this tool is the right pick.

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

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

Annotations already cover read-only/idempotent safety, and the description adds genuinely non-obvious behavior: values are ordinal rank only with no absolute booking counts, data is a dated snapshot (2026-10-21), and each item carries 30-day history. The 'do not merge with Naver buyer index' caveat is a real analytical trap it warns about.

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 and informative, but the entire Korean sentence restates the English text, roughly doubling length with little added information beyond localized search terms. Dense single-sentence packing of a dozen return fields also makes it harder to scan.

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 enumerating what comes back (rank, cumulative reviews, rating, adult-min price, departure-fixed flags, per-city package counts, top-10 search keywords, 30-day history). Combined with scope and data vintage, an agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 100% (the city param already documents Korean/English/airport-code forms), so baseline is 3. The description adds the behavioral default — omitting city yields an all-cities summary — which is meaning the schema's optional/not-required status alone does not convey.

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

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

Names a specific resource (top-20 Hanatour packages per city, ranked by the site's own booking order) plus the exact fields returned and the dataset vintage. It also explicitly distinguishes itself from the Naver buyer index, so an agent can separate it from get_demand_index without opening any 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 concrete usage rules: omit city for an all-cities summary, read trends separately from the Naver index, and don't merge the two signals. That is an explicit when-to-use plus a when-not-to-use/alternative condition, which is the top of the scale.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds substantial non-obvious context: tax-inclusive vs tax-exclusive scope per seller, the Agoda dual-entry (method=screen vs Lite API), and the caveat to compare only tax-inclusive scopes. It stops short of noting freshness, caching, or failure modes.

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 explanation is front-loaded and dense with genuinely useful detail, but the entire content is then repeated verbatim in Korean, roughly doubling length with no added information for an agent reading either language. The core is efficient; the duplication is not.

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 a fairly complex result shape (hotels × sellers × two day-types), the description does well to explain the seller list, the reason Agoda returns two entries, and the price_scope field. A fuller sketch of the returned record structure would close the remaining gap.

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

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

Schema coverage is 100% and both parameters (city, limit) are fully documented in the schema, including accepted Korean/English names and airport codes. The description adds no syntax beyond that, 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 names a specific verb+resource (get hotel prices) and precisely scopes the result: the 20 most-reviewed hotels for a popular city, priced for 2 adults on the next weekday and weekend. It is trivially distinguishable from siblings like get_direct_flights, get_tours, and get_demand_index.

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 'For a popular city' implies the applicable context, but there is no explicit when-to-use/when-not guidance and no alternative named. Because the sibling tools address entirely different resources, the risk of mis-selection is low, leaving this merely implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds behavior annotations don't: the archive boundary (2026-10-14), that a 30-day summary is bundled with the daily values, and the cross-series comparison restriction.

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 and scope, and the constraint sentence is short and useful. The full English/Korean duplication doubles the length for the same content, which is the only structural waste.

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

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

With no output schema, the description carries the return-value burden and does name the payload (daily values plus 30-day summary) and the data availability window. It omits ordering, pagination/truncation behavior at the 120-day cap, and error cases, but nothing essential to invoking it correctly 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 description coverage is 100%, so the schema already documents both parameters and the default (기본 30). The description only restates 'last N days', adding the archive floor but no format or unit details 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?

States a specific verb+resource: 'Daily observed values of one series_id for the last N days', plus what else comes back (the 30-day summary). An agent can tell this is a per-series time-series fetch rather than a search. It does not explicitly name the sibling it complements (search_series), so it stops short of 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?

Gives a real usage constraint ('Compare only within the same series_id') and the archive start date, which frames when data exists. However, it never says when to use this versus search_series or the other sibling tools, and the prerequisite that series_id must come from search_series lives only in the schema description.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: a hard top-3 cap, an exclusion list of product categories, and the shape of the returned fields. It stops short of covering pagination or failure behavior, but for a bounded read tool this is solid.

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 action and scope, and each clause conveys a distinct constraint (top 3, exclusions, returned fields). The Korean sentence largely restates the English one, which is redundant token cost, though it plausibly serves the Korean-language 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?

For a single-parameter tool with no output schema, the description supplies everything critical: the count (top 3), the excluded categories, and the fields returned. Coverage of edge cases such as unknown or non-popular cities is absent, but the definition is otherwise sufficient to invoke 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?

Only one parameter exists and the schema already documents accepted city formats (Korean, English, airport codes) at 100% coverage, so the baseline is 3. The description adds only the mild constraint that the city should be a 'popular' one, which is marginal value over 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?

States a specific resource and scope: the top 3 best-selling tours/tickets on MyRealTrip for a popular city, with explicit category exclusions (SIM/WiFi/pickup/insurance) and the fields returned (from-price, rating, reviews). It implicitly distinguishes itself from hotel/package siblings, but never names an alternative tool directly.

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?

Usage is implied by the phrase 'for a popular city', which hints at an applicable scope without stating when to choose this over get_hotel_prices or list_popular_packages. No explicit when/when-not guidance or prerequisite conditions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds useful content-level context about today's freshness and data-availability flags per city. However, it does not discuss authentication needs, rate limits, or return format, so it adds only moderate value beyond annotations.

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

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

The description is front-loaded with the English statement of purpose and then provides a Korean translation. It is efficient and short, though the bilingual duplication adds some redundancy for a purely English-reading agent. No sentence is confusing or wasted in substance.

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 low complexity (no parameters, no output schema, simple read-only list), the description adequately covers what the tool returns and the freshness of the data. Annotations already supply the safety and openness attributes. Only minor gaps remain, such as not clarifying pagination or output ordering, which are unlikely to affect 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 tool has zero input parameters, so the baseline is 4. The schema is empty by design and needs no description compensation. There are no parameter semantics to clarify.

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 clear list operation over a specific resource ('All mapped cities') and enumerates the included fields (demand rank, weekly buyers, typical nights, data presence). It distinguishes itself indirectly as the city-level catalog versus per-entity siblings like get_demand_index or get_hotel_prices, but does not name alternatives explicitly.

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?

There is no statement of when to use this tool versus alternatives such as get_demand_index or get_direct_flights. The context is only implied by the content fields. No exclusions or prerequisites are mentioned.

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

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

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so the safety profile is covered. The description adds genuinely new behavioral substance: the exact returned fields (weekly buyers, adult price with coupon applied) and the price-drop semantics (current vs 20-day high), which matters since no output schema exists.

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

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

The content is front-loaded reasonably, but the entire payload is duplicated in English and Korean with no added information, roughly doubling length without earning it. The field list is dense and otherwise tight, but the bilingual restatement is waste for a reader who understands one language.

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 correctly steps in to enumerate the returned fields and the two result modes, and the four optional parameters are fully covered by the schema. What remains missing is routing relative to sibling tour-listing tools, which is a minor gap for a list endpoint.

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 city, country, kind, and limit thoroughly, including accepted script/ISO/airport-code formats and the enum semantics. The description only restates 'filter by city or country,' adding no syntax or constraint detail 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?

The description states a specific verb and resource ('per-product list of Naver overseas package tours') and enumerates the returned fields, so an agent knows exactly what it produces. It does not, however, differentiate itself from the sibling get_tours or explain how the two overlap, which keeps it out of 5 territory.

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?

There is no statement of when to choose this tool over get_tours, get_demand_index, or get_hotel_prices, and no prerequisites or exclusions are given. The popular vs price_drop distinction is a mode of this tool, not guidance about selecting among tools, so the agent is left to infer 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds behavior annotations do not: the return content (today's value plus 30-day median/min/max per series), which is especially valuable since there is no output schema.

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 purpose and return shape, and every English sentence earns its place. The full Korean restatement duplicates the same content, which is reasonable for a bilingual audience but does cost some compactness.

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 with no output schema, the description supplies the filter axes and the shape of what comes back, so an agent can call it correctly. Remaining gaps (result ordering, how limit interacts with broad queries) are minor rather than blocking.

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. The description goes beyond the schema by giving concrete metric examples (package_weekly_buyers, hotel_price, tour_price_from, etc.) that the schema defers to an external SCHEMA.md table, genuinely improving how the metric parameter can be populated.

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 archive's series'), defines what a series is ('one series = one comparable condition'), and enumerates the filter dimensions (metric, city, country, free text). It is clearly a discovery tool distinct from get_series_history, though it never names that sibling to sharpen the boundary.

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?

Usage is implied by listing the filter dimensions and the returned statistics, so an agent can infer this is the entry point for locating series. There is no explicit when-to-use/when-not guidance and no mention of get_series_history as the follow-up for historical data.

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