get_mainline_ticketing_stat

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

No annotations provided, so description must carry behavioral disclosure. It discloses the data refresh schedule (monthly on 1st, M-1) which is a useful behavioral trait. However, it does not explicitly state read-only nature, error behavior, or limits, though the 'get' prefix implies read-only. Missing explicit side-effect disclosure.

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?

Description is a single line with no fluff. Purpose is front-loaded, then update schedule, then parameter definitions. Efficient and well-structured.

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?

Output schema exists, so return values need not be described. Tool is a simple statistics query with two optional params; description covers param semantics and refresh info. However, it lacks usage context and differentiation from sibling stats tools, which is a gap. Overall adequate for a simple tool but incomplete in guidance.

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 has 0% description coverage, so description fully compensates. It defines ntsl_ym as 판매연월(YYYYMM) with format, and ise_type as 발권유형명 (ticketing type name). Both parameters are explained with meaning and format, which is essential given no schema descriptions.

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?

Description states '간선열차 발권유형 통계' (mainline train ticketing type statistics), a specific resource and purpose. It distinguishes from siblings like get_mainline_station_per by focusing on ticketing types rather than stations or routes. The update schedule is an extra detail, not obfuscating the purpose.

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 guidance on when to use this tool versus alternatives. The description only provides param meanings and update cadence, with no mention of scenarios or exclusions. Among many sibling stats tools, no discriminating use case is given.

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