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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: it flags the output as an estimate ('결과는 추정치'), names the data sources (국토교통부 KTX fares, KOBUS bus timetable) with reference dates, and promises a source plus page URL. It does not, however, explain default behavior, precision, or how partial inputs are handled.

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 purpose is front-loaded in the first clause, but the description then packs in a URL, reference dates, and source attributions in mixed Korean/English. The reference block ('확인일 KTX 2026-10-12·고속버스 2026-10-13·출처...') is dense and partially redundant, though it is not egregiously long.

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 an 18-parameter tool with 0 required params, no output schema, and 11% schema coverage, the description is thin. It never explains how the optional inputs combine (e.g., built-in fares vs. supplied fare, or min/max range pairs) or what a caller must supply for a meaningful estimate.

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 only 11% (2 of 18 params), so the description must compensate and largely fails to. It names the categories 'transport, stay, food, admission' which loosely groups the stay_/food_/admission_/fare params, but the 16 undocumented parameters (toll, car_km, fuel_price, car_km_per_l, rooms, people, nights, mode enums, etc.) get no explanation of units, interaction, or defaults.

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 (Korea domestic trip budget) and enumerates the cost categories it covers (transport, stay, food, admission ranges), which is more than a tautology. Sibling tools are all unrelated calculators (tax, electricity, GPA), so no differentiation is required. It is clear what the tool computes, though the reference metadata slightly muddies the opening.

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, when not to, or what alternatives exist. The only usage-adjacent sentence is 'Returns an estimate with the source and page URL,' which describes output rather than selection criteria.

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