get_urban_transfer_info

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

With no annotations provided, the description carries the full disclosure burden does substantial work: it specifies how data recency from _meta's '데이터수정일' should be reported, tone rules for recent vs. outdated data, the notify-once-by-oldest-date rule, the prohibition on repeating notices, and the explicit 'don't fabricate, say 데이터 없음' instruction for empty results. It lacks auth/rate-limit detail but the output schema covers return shape, making this strong behavioral coverage.

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

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

The core purpose and parameter meanings are front-loaded in the first two lines, followed by a structured bullet-point guidance section that earns its length by encoding multi-branch formatting rules. The guidance block is dense but not redundant; mild verbosity in the answer guidelines prevents a 5.

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 2-parameter tool with an output schema present, the description covers purpose, both parameter semantics, and exhaustive response-handling behavior. The main gap is not differentiating against the get_station_transfer_info sibling, no explanation of the 'operator' value format. Otherwise an agent has enough to call 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 description coverage is 0%, so the description is the sole source of parameter meaning. It defines station_name as '역명' (station name) and operator as '운영기관 코드/명(선택)' (operating agency code/name, optional), correctly reflecting the operator default and required-status of station_name. It adds the optionality and semantic role beyond the bare schema, though it omits format examples or code-list references.

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 opens with a specific verb+resource: '도시철도 역사 환승정보 조회' (urban railway station transfer info lookup) and enumerates the data scope (환승노선·환승거리·동선 – transfer routes, distances, movement paths). This is specific enough to convey the tool's purpose, and the 'urban' qualifier distinguishes it from the non-urban sibling get_station_transfer_info, though that sibling is not 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?

The long '답변 지침' (answer guidelines) block governs response formatting — data recency notices, tone variation by modification date, and empty-result handling — none of which help an agent choose this tool over alternatives like get_station_transfer_info, search_urban_station, or get_urban_station_info. No when-to-use, when-not-to-use, or prerequisite guidance is provided.

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