get_urban_train_composition

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

With no annotations available, the description carries the full burden and succeeds: it discloses the return contents, input format variation, agency availability limitations, the use of '데이터수정일' from _meta to indicate data recency, and the mandated behavior for stale data and empty results. It even tells the model not to fabricate data when the result is empty.

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 core purpose and fields, then parameter guidance, then data availability, and finally response formatting rules. The answer-guidance section is extensive, but it is relevant to behavioral transparency and is clearly separated into a directed block; a slight trim would still improve conciseness.

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 an output schema present, the description covers invocation semantics, output fields, downstream usage, provider exclusions, and response expectations. Nothing an agent needs to call the tool correctly or interpret its result 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 coverage is 0% and the schema only defines operator as a string, so this description is the sole source of parameter meaning. It adds concrete semantics by stating that operator can be either a code like 'BS' or a name like '부산교통공사', which materially improves correct invocation.

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: '도시철도 운영기관별 열차 편성종류 조회 (역 무관)' and enumerates the returned fields (composition type code, composition name, seat/door/wheelchair counts per car). It also distinguishes itself from sibling tools by explaining that the result is independent of station and by identifying get_urban_train_facility as the downstream consumer of its outputs.

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 clearly explains how to chain this tool with get_urban_train_facility by passing cpsTpCd and scarNo into composition_type and scar_seq, and it lists agencies that do or do not provide the data. However, it does not explicitly contrast this tool with other sibling tools that fetch similar rolling-stock or train composition data, so the exclusion guidance is only partial.

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