K-Tour Info

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

Annotations already declare read-only, idempotent, closed-world, so the description correctly spends its words elsewhere: nearest-first ordering, distances returned in meters, Korean-only naming, and geographic restriction to Korea (consistent with openWorldHint=false). It stops short of noting any rate limits, coverage caveats, or that a category filter can sharply reduce results.

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?

A single dense sentence that front-loads the operation and packs scope, ordering, unit and locale into it. Slightly awkward phrasing ('radius of a latitude/longitude') but no filler.

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

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

With no output schema, the description covers the key return traits (ordering, distance unit, Korean-only names) and the region constraint, which is enough to call correctly. It omits what fields come back per place and whether category filtering changes ordering or coverage, which would round it out.

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 units, defaults, ranges and an enum legend already documented per-parameter. The description only alludes to radius and adds nothing about lat/lng ordering, limit behavior, or default radius, so it neither helps nor compensates.

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+scope: proximity search by lat/lng within a radius, restricted to Korea. This meaningfully separates it from search_places (keyword) and get_related_places, though the description never names those siblings, so differentiation is inferential rather than explicit.

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?

No statement of when to use this over search_places, get_related_places, or generate_itinerary, and no prerequisites. The only usable cue ('within a radius of a lat/lng') is implied by the name and schema rather than stated as 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description earns credit by disclosing the shape of the generated result (day grouping, visiting order, approximate timetable, meal stops), which matters because there is no output schema; it stops short of covering empty-area behavior, determinism, or cost/latency.

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?

A single front-loaded sentence that specifies the resource, the output structure, and the inclusions with no filler. Every clause carries information an agent can use.

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 all five parameters optional and no output schema, the description usefully explains what comes back, which is the main gap it needed to fill. It is close to complete, lacking only what happens with an unrecognized or empty area and whether the timetable is fixed or variable.

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 each parameter is documented with defaults, bounds, and enum fallback notes, so the schema does the heavy lifting. The description only adds the notion of 'a region' mapping to the area parameter and nothing about per_day, num_days, day_start, or locale behavior, so baseline 3 applies.

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

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

States a specific verb+resource ('Build a day-by-day sightseeing itinerary for a region') plus the concrete output shape: spots grouped by day, in visiting order, with approximate timetable and meal stops. That level of detail makes it clearly distinct from lookup siblings like search_places and find_nearby_places, though no sibling is named 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?

Usage is only implied: the description frames the tool as producing a multi-day plan, which suggests it is the right choice when the user wants an itinerary rather than individual places. There is no explicit 'use this when...' or 'use X instead for single-place lookups' statement, and no prerequisites are stated.

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, so the description wisely spends its words elsewhere: the direction of the metric, the ~30-day horizon, and the hard requirement that names be in Korean (a real failure mode for callers). Pagination behavior and the full returned field set are left unstated.

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?

Three compact sentences: definition, intended use, then the prerequisite caveat. Front-loaded and every sentence carries distinct information with no restatement of the schema.

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, five-optional-parameter lookup with no output schema, the description covers what is being returned (daily crowd level via cnctr_rate), the time range, and the naming constraint. Remaining gaps are minor: whether results are per-spot-per-day rows and how limit interacts with the ~30-day window.

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 baseline is 3; the description earns above that by adding operational meaning not in the schema — that poi_name/signgu values must be Korean and must be sourced via search_places with locale 'ko' rather than transliterated by the agent.

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 ('Daily crowd-level forecast'), scopes it geographically and temporally ('Korean tourist spots over the next ~30 days'), and defines the core metric ('cnctr_rate, higher = busier'). No sibling tool does anything similar, and the reference to search_places for name resolution further separates it from the discovery 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?

'Use it to pick quieter days or spots' names the decision this tool supports, and the prerequisite workflow ('use search_places with locale ko to get the Korean name first') tells the agent what to do before calling. It stops short of explicit exclusions or a named alternative for non-Korean destinations.

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 readOnly/openWorld/idempotent semantics, so the description's job is to add domain context — and it does: the ranking comes from monthly Korean travel-movement data and results are Korean-language names. It does not say what happens for a non-Korean or unknown POI (empty result versus error), which is the main remaining behavioral 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?

A single front-loaded sentence with zero filler; the core concept is stated before the data provenance and language caveat.

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, and the description does not say what a result item contains beyond 'names in Korean' — no mention of rank, co-visit counts, or whether categories are returned. For a ranking/recommendation tool this leaves the return shape partially unspecified.

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

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

With 100% schema description coverage (including the category enum legend and the limit default of 8), the schema already carries the parameter meaning. The description only adds the constraint that poi_name must be a Korean name, which is marginal beyond the schema's own example '경복궁'.

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

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

The description states a specific resource (related spots) and the mechanic behind it — 'Visitors to X also visited Y' — plus the data source (Korean travel-movement data, monthly). This is clearly distinguishable from find_nearby_places or search_places in concept, though it never names those siblings to make the contrast explicit.

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 when-to-use or when-not guidance and no alternative is named, even though find_nearby_places is a near-neighbor an agent could easily confuse with this one. The recommendation intent is only implied by the quoted phrase and the 'ranked' wording.

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 and closed-world, so the safety profile is covered. The description's real contribution is the date-overlap semantics ('running at any point between'), which is behavior the schema's bare 'YYYY-MM-DD' does not convey. It says nothing about result ordering, the default limit of 12, or how results are truncated at 40.

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?

A single front-loaded clause with no wasted words, and the scoping rule precedes the optional filter. It reads as a noun phrase rather than a sentence, and a little more could have been said about return shape at near-zero 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?

The tool is simple, every parameter is documented in-schema, and annotations carry the safety profile, so an agent can call this correctly from the current text. The only gap is return-shape guidance, which is absent because there is no output schema; for a read-only list tool that is a minor omission.

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?

At 100% schema coverage the schema already defines all four parameters, including area examples, date format, and limit bounds with default. The description confirms area is optional and clarifies date matching as overlap rather than containment, which is genuine added value — but the baseline for full coverage is 3.

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 the specific resource (Korean festivals and events) and states the selection rule — anything running at any point between two dates, optionally narrowed to one region. That overlap semantics is meaningfully more precise than a generic 'list' verb. It does not need to differentiate from siblings since none of them return festivals, though it could have explicitly said so.

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?

'Optionally in one region' implies the filter is discretionary but there is no statement of when to reach for this tool versus search_places or find_nearby_places, and no exclusions or prerequisites. Usage is inferable from the resource name alone rather than articulated.

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 this as a safe, read-only, idempotent search. The description adds useful behavioral context by naming the dataset scope (50,000+ Korean places) and, importantly with no output schema, the fields returned. It still omits result ordering, pagination/no-results behavior, and any auth or rate-limit 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?

Two sentences, front-loaded with purpose and followed by return fields. Every phrase carries useful information and there is no filler.

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

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

For a read-only search tool with fully documented parameters and no output schema, the description supplies the essential purpose, search axes, and return shape. It stops just short of fully complete by not covering result ordering, filter combination, or no-results 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 the schema already documents all five parameters, enum values, and locale fallback behavior. The description only maps the high-level search dimensions (keyword, region, category) and does not add semantics for limit, locale, or how filters combine.

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: searching Korean tourist attractions, restaurants, lodging, shopping, culture facilities and festivals. It also names the search axes (keyword, region, category), making the basic function clear. However, it does not explicitly distinguish itself from siblings such as find_nearby_places or list_festivals.

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 listed search dimensions: keyword, region and category. The description never states when to choose this tool over find_nearby_places, get_related_places, or list_festivals, and gives no exclusions or prerequisites.

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