transit_next

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

No annotations are supplied, so the description carries the full disclosure burden. It says nothing about whether times are real-time or static timetable data, how results are ordered, whether an empty list is possible, or whether any authentication/context (such as the caller's home campus) affects the answer. Only the read-only nature is inferable from the wording.

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?

It is a single short sentence with the core purpose front-loaded and nothing redundant. It is arguably too terse for the disclosure burden it bears without annotations, but no wording is wasted.

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 simple two-parameter read tool with a fully documented schema this is close to sufficient, but with no output schema the description should at least characterize the return shape (for example, a list of upcoming departure times with campus labels) or note whether results are time-ordered. That gap keeps it at minimum-viable.

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 100%, so both parameters are already documented in the schema, including the enum values for campus and the limit range. The description's parenthetical '可指定始发校区' restates the campus parameter without adding semantics (for example, default behavior when omitted or how limit interacts with ordering). Baseline 3 applies.

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 uses a specific verb-plus-resource pairing ('下一批发车时刻' for campus shuttle departures) and adds the scope qualifier that a campus can be specified. An agent knows exactly what data this returns. It does not name any sibling, but no sibling in the list covers transit, so differentiation is not needed here.

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 phrase '下一批' implies the use case of checking upcoming departures, which is enough to select the tool in context, but there is no explicit when-to-use or when-not guidance and no prerequisites (for example, whether a campus name is required for meaningful results). Usage is only implied.

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