get_next_shuttle

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

Annotations include readOnlyHint=true and openWorldHint=true, which signal this is a safe read operation that may return dynamic data. The description adds the '현재 시각 기준' (based on current time) detail and the regular-semester-only operating constraint, which is useful behavioral context. However, it doesn't disclose what happens outside the semester (empty response? error?), nor whether results are sorted or limited to one entry.

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 a single, efficient sentence that conveys purpose and the operating constraint. It's compact and front-loaded with the core function. Slightly more detail on edge cases (off-semester behavior) could improve it, but for a zero-parameter query tool, this level of brevity is appropriate.

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 zero-parameter, read-only tool with readOnlyHint and openWorldHint annotations, the description provides the essential purpose (next departure). The semester-only constraint is captured. However, given the sibling tools include get_bus_arrival and get_shuttle_schedule which could overlap, the description could better clarify what distinguishes 'next departure by current time' from those alternatives. Also, the off-semester behavior is 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?

The tool has 0 parameters, so the description carries no parameter documentation burden. The baseline for 0-param tools is 4. The description accurately reflects that no inputs are needed since it queries based on the current time. No schema coverage concern applies here.

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 the tool queries the next departure time of Kangwon National University's DuRi bus based on the current time ('현재 시각 기준 다음 출발 시각'). It identifies the resource (bus) and the operation (query next departure). However, it doesn't clearly distinguish from sibling tools like get_bus_arrival or get_shuttle_schedule, which could overlap in purpose. The verb '조회' (query) plus resource '두리버스' is reasonably specific, but the relationship to nearby siblings is unclear.

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 mentions '정규학기만 운영' (only operates during regular semesters), which provides some usage context. However, it doesn't explicitly state when to use this vs alternatives like get_bus_arrival or get_shuttle_schedule, nor does it note any exclusions or when NOT to use it. The semester-only constraint is helpful context but no alternatives are named or distinguished.

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