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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety behavior is covered. The description adds useful behavioral context beyond annotations: it returns single-journey fares in NT$, broken down by train type and passenger type, and includes distance. It does not describe error behavior or result shape, but for a read-only lookup the added context is substantial.

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 definition is one front-loaded sentence plus a concrete example. Every part earns its place: scope, currency, fare dimensions, distance, and parameter example.

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-only fare lookup with no output schema, the description gives enough to understand the domain and expected return content. The main remaining gap is that it does not specify the return structure or how multiple fare rows are presented.

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 must compensate. It does so by saying fares are between two stations and by mapping the example values '嘉義' and '奮起湖' directly to the from/to parameters, making clear that both parameters are station names. It still lacks accepted naming conventions or station-value guidance.

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 resource and scope: Alishan Forest Railway single-journey fares between two stations, in NT$, by train type and passenger type. Naming the railway line clearly distinguishes it from sibling fare tools such as tra_fare, thsr_fare, ferry_fare, and metro_fare. The example further anchors what the tool does.

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 does not explicitly say when to use this tool or when to choose an alternative fare tool. Usage is only implied by the Alishan Forest Railway name, with no exclusions or comparison to siblings.

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

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

Annotations already cover readOnlyHint and openWorldHint. The description adds context annotations cannot: services change with season and weather, and the result itself tells the caller when to re-check the official site. That freshness caveat is genuinely useful behavioral disclosure about the reliability and nature of the returned data.

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?

Three short sentences with the purpose front-loaded, followed by the freshness caveat and a concrete example. Efficient; the trailing example fragment is terse but functional rather than wasteful.

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?

A simple two-optional-parameter read tool with no output schema and annotations already declaring its safety profile. The description covers scope, data volatility, and a usage example; only the return shape is unaddressed, which is acceptable for a low-complexity tool.

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 100%, so both `from` and `to` are fully documented including accepted name or station-ID forms. The description only restates the from/to pairing via an example and adds no format or edge-case detail beyond the schema, so 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?

States a specific verb+resource (regular timetable of the Alishan Forest Railway) and its scope: all trains, or trains between two stations with times. The operator is named explicitly, which is enough to separate it from the sibling tra_timetable and thsr_timetable without opening any schema.

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?

Usage is implied by the operator-specific framing and the from/to example, so an agent can infer it's the AFR counterpart to the other rail timetable tools. However, no alternative is named and there is no explicit when-not guidance, so routing is left partly to inference.

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

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

Annotations already declare this as a read-only, open-world operation, lowering the disclosure burden. The description adds useful behavioral context about alert categories and affected routes/stops, but does not cover pagination behavior, rate limits, or return format details.

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, compact, and free of redundant explanation. The single summary sentence plus short examples efficiently communicates scope and query patterns.

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?

With no output schema, the description appropriately indicates the kind of information returned: alert types plus affected routes and stops. It is largely complete for a simple read-only alert lookup, though return shape and pagination remain implicit.

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 all four parameters are already well documented. The description reinforces city and route usage with examples but adds little beyond the schema for limit and keyword.

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 resource, bus service alerts, and enumerates the alert types: detours, suspensions, moved stops, extra services, and operator news. It also clarifies scope with city or InterCity coaches and affected routes/stops, so an agent can distinguish it from unrelated sibling tools.

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?

It gives clear usage context: query by city, optionally by route, and supports InterCity coaches. It does not explicitly name alternatives such as ferry_alerts or rail_alerts, but the bus-specific scope makes the intended use clear.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds the important context that this is live data and enumerates the possible ETA states, including the terminal case "last bus has passed" and the following-bus minutes. It says nothing about rate limits, caching, or data freshness/auth requirements for TDX.

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?

Three short sentences, front-loaded with what the tool returns before the narrowing hint and the example. No filler, though the phrase "Give stop to see one stop only" is slightly awkward and could be phrased more crisply.

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?

With no output schema, the description carries the burden of explaining return values and does so well by showing the ETA string formats and the trailing minutes for subsequent buses. Minor gaps remain around result volume defaults and whether the call needs credentials, but nothing essential for correct invocation 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 description coverage is 100%, so city, stop, limit, direction and routeName are all documented in the schema, including the stop substring behavior and direction enum. The description's example (city "Taipei", routeName "307", stop "西門") is illustrative but adds no meaning beyond what the schema already states, so the 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?

States a specific verb+resource: live estimated arrival times for the next buses at a route's stops. The concrete return-value examples ("4 min", "arriving now", "last bus has passed") make the purpose unambiguous. It does not explicitly distinguish itself from siblings like bus_positions or tra_live_board, so it stops short of a 5.

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?

"Give stop to see one stop only" implies how to narrow results, and the worked example shows a typical call. However, there is no guidance on when to use this versus bus_positions or tra_live_board, nor any prerequisite such as needing to resolve routeName first (that hint lives only in the schema).

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-data profile are covered. The description adds useful context by specifying that results include each vehicle's position, speed, direction, and status, but it does not discuss data freshness, rate limits, empty results, or other operational caveats.

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 two sentences and immediately front-loads the purpose before giving a compact example. Every part of it contributes to understanding the tool's output and usage.

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?

With no output schema, the description helpfully enumerates the returned fields and the real-time scope. Parameters are fully covered by the schema, but the description could still say more about result limitations or completeness for a live vehicle feed.

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 the schema already documents city, direction, and routeName in detail. The description's example illustrates city and routeName but does not add meaning beyond the schema, especially for the optional direction parameter.

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 clearly states that the tool returns live positions of buses on a specific route, including position, speed, direction, and status. It is specific about the resource and real-time scope, though it does not explicitly differentiate itself from siblings such as bus_eta or bus_route_stops.

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 gives an example call but does not state when to use this tool versus alternatives like bus_eta or bus_route_stops. Usage is only implied by the phrase 'right now' and the route-based scope.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description usefully adds that matching is substring-based across three fields and enumerates the returned data (endpoints, operators, fare), which matters because there is no output schema. It does not mention result ordering or how the limit interacts with matching, so not a 5.

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?

Three short sentences: what it matches, why to use it, and worked examples. The purpose and the disambiguating guidance are front-loaded, and nothing is repeated from the schema.

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 read-only two-required-parameter search with no output schema, the description covers matching behavior, return contents and its place in the tool chain. Only minor gaps remain, such as result ordering or what happens when nothing matches.

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%, with city, keyword and limit all documented including the InterCity special case and the default limit of 20. The description's example city/keyword pairs reinforce usage but add no semantics beyond the schema, so the baseline of 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?

States a specific verb and resource plus the matching semantics (name, first or last stop contains keyword) and what the results carry (endpoints, operators, fare). It also positions itself relative to the other bus tools, so an agent can tell it apart from bus_route_stops, bus_eta and bus_positions without opening their schemas.

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?

'Use it to find the exact route name the other bus tools need' gives clear, actionable when-to-use guidance and explains the downstream role in a workflow. Two concrete example invocations (Taipei/307, InterCity/1610) make the call pattern obvious. No explicit exclusions or named alternatives are given, which keeps it below a 5.

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

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

With readOnlyHint=true and openWorldHint=true already set, the annotation covers safety and openness. The description adds useful behavioral context by saying results are ordered and cover each direction and sub-route, but it does not discuss error cases, rate limits, or authentication.

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 two tight sentences: one front-loads the purpose and return scope, and the second gives a concrete example. There is no redundant or wasted content.

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 read-only lookup with 100% schema coverage and no output schema, the description is mostly complete: it states what is returned, the ordering, and the direction/sub-route scope. Minor gaps remain around missing-route behavior and explicit relationship to bus_route_search.

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 the schema already documents all three parameters in detail. The description reinforces usage with an example for city, routeName, and direction, but adds little semantic detail beyond the schema.

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 clearly states that the tool returns the stops of a bus route in order, including per direction and sub-route. It is specific enough to distinguish this from route search or ETA tools, though it does not explicitly name a sibling alternative.

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 provides an example invocation but does not explain when to use this tool versus alternatives such as bus_route_search or bus_eta. It implies usage for a known route but gives no explicit prerequisites, exclusions, or routing guidance.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the main behavioral burden is lighter. The description adds useful beyond-annotation context: results are ordered soonest first, include minutes to arrival, destination/heading, and subsequent buses, and cover all routes at one stop.

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 definition is front-loaded with the core behavior and then immediately gives the input pattern and examples. Both sentences earn their place, and there is no redundant or vague filler.

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 read-only, open-world live-arrival tool with no output schema, the description does a good job explaining the main return contents and ordering. It is not fully complete about edge cases such as empty results or ambiguity handling, but the schema covers all parameters thoroughly.

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 all four parameters already have clear schema-level documentation. The description reinforces the stationUID source and gives examples, but it does not add much beyond the schema and does not mention the limit parameter.

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 gives a specific verb-and-resource picture: it returns every bus due at one stop across all routes, ordered soonest first, with arrival minutes and destinations. It clearly separates itself from bus_stops_nearby by explaining that stationUID comes from that sibling, but it does not explicitly distinguish itself from other bus-related siblings such as bus_eta or bus_timetable.

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?

It tells the agent to supply either a stationUID from bus_stops_nearby or a stop name and provides concrete examples, which implies the likely workflow. However, it does not state when to use this tool instead of bus_eta, bus_timetable, bus_positions, or other bus siblings, nor does it give exclusions.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the bar is lower; the description adds real value by disclosing result ordering (nearest first), what each result contains, and the useful quirk that InterCity coach stops are always included. It doesn't cover behavior at radius/limit boundaries or whether an empty result is possible.

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?

Three compact sentences with the core purpose front-loaded, followed by the handoff tool and a concrete example. No redundant restatement of the title.

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?

With no output schema, the description does the right thing by sketching the return shape (stops with heading and routes, ordered nearest first). The remaining gap — no mention of limit/radius defaults or result truncation — is covered by the schema, so nothing critical 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 description coverage is 100% and every parameter is documented with ranges, defaults and a city-code enumeration, so the schema carries the load. The description only restates the coordinate idea and adds an example lat/lon pair, which the schema already supplies as examples.

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?

States a specific verb/resource ('Bus stops nearest to a coordinate') plus the payload contents (heading, city bus and InterCity coach routes), which cleanly separates it from geo-siblings like parking_nearby, youbike_nearby and ev_charger_nearby. Nearest-first ordering is also declared.

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?

Gives an explicit follow-on path — pass a stop and route to bus_eta for live arrivals — which tells the agent where this tool sits in a workflow. It does not state when to prefer a sibling like bus_route_stops or bus_stop_arrivals instead, so it stops short of full routing guidance.

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

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

Annotations only cover readOnly and openWorld, so the description earns credit for disclosing that frequency-based routes return a headway rather than a departure list, and that some cities have no timetable data at all. It does not say what happens when the route has no service on the requested date or how large a result set typically is, leaving a small gap.

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?

Two tight sentences plus a worked example, with the core capability and the sibling routing front-loaded. The Kaohsiung note is a useful fragment rather than filler, though the sentence packing several clauses makes it slightly dense on first read.

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?

With seven parameters, an enum, and no output schema, the definition covers mode, scope, the live-vs-scheduled split, data-availability caveats, and a sample invocation — enough to call it correctly. The shape of the frequency-mode response is only implied, which is the remaining shortfall for a tool lacking an output schema.

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 100%, so the baseline is 3; the description lifts it by clarifying that departures are taken from the first stop unless a stop is supplied, and by giving a concrete cross-parameter example (city "InterCity", routeName "1610", stop "臺北轉運站") that demonstrates the intercity mode and Chinese stop names in one call.

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?

States a specific verb and resource — scheduled departures of a bus route on a given day — plus two output modes (departure list from a stop, or frequency/headway for frequency-based routes). It explicitly separates itself from the live-arrivals sibling, so an agent can pick it without opening the schema.

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?

Gives positive guidance (planning ahead, coaches and rural routes) and names the alternative with its selection condition ('use bus_eta for live arrivals'). It also supplies a negative constraint — Kaohsiung publishes no timetables — which prevents a guaranteed-empty call.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data reach are covered. The description adds genuinely useful behavior beyond that: results include real-time free/in-use/out-of-order counts, opening hours and prices, which tells the agent the payload is live and includes operational status. It still says nothing about result limits semantics, empty results, or staleness of the real-time data.

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?

Two sentences: the first front-loads what the tool returns, the second carries the special case and a worked example. No filler, nothing repeated from the schema verbatim.

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?

With eight parameters, no output schema and a rich live payload, the description does the important extra work of naming the returned fields (connectors, availability, hours, prices). Reasonably complete; a note on default result size behavior or the real-time refresh cadence would close the remaining gap.

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 baseline is 3; the description goes further by supplying a concrete full example that shows realistic lat/lon values and a connector enum value in context, and by flagging the "freeway" city sentinel as a distinct lookup mode. It does not add detail on radiusMeters, limit or want beyond the schema.

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?

States a specific verb and resource ('EV charging stations nearest to a coordinate') and enumerates what comes back: connectors with type/AC-DC/power, live availability counts, opening hours and prices. An agent can distinguish this from parking_nearby or youbike_nearby purely from the text.

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?

Gives a concrete usage context (a coordinate plus a city) and a worked example with lat/lon/city/connector, plus the special-case instruction that city "freeway" targets freeway service areas. It does not explicitly say when to prefer another nearby-search sibling, so it stops short of full alternative routing.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the description need not restate safety. It adds domain context about what alerts include and how filtering works, though it does not discuss update frequency or result ordering.

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 compact and front-loaded: it states the alert scope first, then gives the optional-input behavior and a keyword example. Every sentence contributes directly to use of the tool.

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 read-only, two-optional-parameter alert lookup with no output schema, the description supplies enough context: what is returned (affected routes and ports), how filtering works, and what happens with no input. No critical calling detail 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 100%, so both parameters are already documented in detail, including city codes and keyword matching behavior. The description reinforces the optional filter behavior with "no input for every alert", but largely duplicates the schema's keyword example rather than adding new parameter semantics.

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 names the specific resource and content type: current ferry service alerts covering suspensions, cancelled/changed sailings, and the affected routes and ports. This clearly distinguishes it from sibling timetable, live-board, and fare tools. An agent can identify the tool's function without inspecting the schema.

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?

It gives concrete usage guidance: filter with a keyword such as "綠島", or omit input to retrieve every alert. It does not explicitly contrast this tool with ferry_timetable or ferry_live_board, but the alert-specific scope is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data behavior are covered. The description adds useful fare-specific context by specifying NT$ currency and fare granularity by route, ticket, cabin, and passenger type, but it does not discuss missing-route behavior, availability, or response shape beyond pricing dimensions.

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 two short sentences, front-loads the core purpose, and uses the example efficiently to illustrate valid port values. There is no wasted text.

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?

The schema fully covers the three inputs, and annotations cover read-only/open-world behavior. Because there is no output schema, the description responsibly states the fare unit and breakdown dimensions, though it could be slightly more explicit about what a typical response contains when no fares exist.

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 from, to, and city are already well documented. The description contributes only an example using from="基隆" and to="南竿" and does not add semantics beyond the schema, so the baseline score of 3 is appropriate.

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 resource and result: ferry fares in NT$ between two ports, with fare breakdowns by route, ticket, cabin, and passenger type. It is clear enough to distinguish a fare lookup from ferry timetable, live board, alerts, or positions tools, though it does not explicitly name those siblings.

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?

Usage is implied by the name and description: use this to look up ferry fares once departure and arrival ports are known. There is no explicit when-to-use guidance, no exclusions, and no named alternative such as ferry_timetable for schedules.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description usefully adds that the board is for today only, that statuses include cancellation with a reason, and that coverage is limited to roughly 25 ports. It does not discuss rate limits or auth, but those are lower-priority for this read-only tool.

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 what the board returns, then coverage limits, then the concrete example. It is efficient, though the parenthetical port list and example are somewhat verbose for an agent that already receives rich schema descriptions.

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 read-only, two-parameter tool with no output schema, the description explains what data comes back, the temporal scope, status semantics, and the key coverage caveat that routes agents to ferry_timetable. Nothing essential is missing for correct invocation.

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 100% and already documents both port and limit, including examples and the default limit of 40. The description adds a usage example for port but does not add meaningfully new semantics beyond the schema, so the baseline of 3 is appropriate.

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?

States a specific verb and resource (live departures and arrivals for a ferry port today) and enumerates the returned fields: scheduled, estimated and actual times, vessel, and status including cancellation reason. It explicitly distinguishes itself from ferry_timetable for ports without a live board.

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?

Provides an explicit when-to-use boundary: about 25 ports have a board, and ferry_timetable should be used for the others. It also gives a concrete example (port "小琉球"), leaving little ambiguity for an agent selecting between the two ferry tools.

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

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

Annotations already cover read-only and open-world safety, and the description adds real value beyond them: the data source (AIS), the caveat that names are as broadcast and often English (which explains failed keyword searches), and that positions are not route-bound. It does not mention freshness/update cadence, which matters for a 'right now' claim.

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?

A compact, front-loaded paragraph: capability first, then the caveats, then examples. Every sentence carries information, though the closing example sentence largely duplicates schema examples and could be trimmed.

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?

With seven optional parameters and no output schema, the description usefully enumerates the returned fields and pins the geographic scope (Taiwan). The main remaining gap is the no-argument behavior — it never says what an unfiltered call returns beyond the schema default limit of 20 — and that lat/lon must be supplied together.

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 every parameter is already documented with ranges, defaults and examples; the baseline is 3. The description restates the three search modes and repeats example values (小琉球, TAIMA) already present in the schema, without explaining whether port/keyword/lat-lon are mutually exclusive or how radiusKm applies to each.

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?

States a specific resource and scope: live AIS positions of ferries/passenger vessels around Taiwan, with the returned fields enumerated (position, speed, course, status, nearest port). It implicitly separates itself from ferry_timetable/ferry_live_board by noting positions are not tied to routes, but it never names the sibling it should be preferred over.

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?

"Search by vessel name, near a port, or near a point" conveys the three invocation modes, but gives no explicit when-to-use/when-not guidance and never points to ferry_live_board or ferry_timetable as the alternative for schedules or arrivals. The agent must infer the routing decision from the field list.

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

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

Annotations already declare readOnly and open-world, so the safety profile is covered. The description adds genuinely useful context beyond that: live status fields only apply to today, and service alerts such as typhoon suspensions may appear — behavior an agent would not learn from annotations alone.

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?

Two tightly packed sentences: capability first, examples last. Every clause carries information. Slightly dense with the embedded example list, but nothing 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?

There is no output schema, so the description must convey what comes back — and it does (sailing times, today-only live status, service alerts). Combined with fully documented parameters, an agent has enough to call it correctly; only the sibling-routing guidance is thin.

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 100%, so the baseline is 3. The description reinforces parameter meaning with a worked example (from 富岡 to 綠島, city PenghuCounty), which clarifies how city interacts with port names, but it adds no syntax or constraint detail beyond the schema.

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 gives a specific verb and resource — ferry sailings from one port to another on a given day — and names the return content (times, live status, service alerts). The concrete port examples make the scope unambiguous. It does not, however, distinguish itself from siblings like ferry_live_board or ferry_alerts, which cover overlapping live/alerts territory.

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?

Usage is only implied: an agent can infer this is for planning a crossing on a date. There is no explicit statement of when to choose this over ferry_live_board (today's departures board) or ferry_alerts (dedicated alerts), even though the description mentions both live status and alerts as included features.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds useful behavior: it is live, covers today from an hour ago onward, and includes current weather. It does not discuss rate limits or auth, but those are less central for this read-only public-data tool.

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 in one sentence and followed by a compact example. It avoids restating schema details and has no wasted text.

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 7-parameter read-only tool with no output schema, the description lists the returned board fields and time window, which is sufficient to call it correctly. It could more explicitly route the agent away from flight_status or flight_schedule, so it is strong but not fully complete.

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 every parameter is already documented in the schema. The description's example reinforces how airport, direction, and otherAirport combine, but it adds little semantic detail beyond the structured fields.

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?

It names the specific resource (an airport's live departure or arrival board), the passenger-flight scope, and the fields returned (times, delay, status, terminal, gate). This is enough to separate it from specific-flight tools such as flight_status and schedule-oriented tools.

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?

It gives clear usage context: Taiwan airports, today's board starting an hour ago, passenger flights, and a concrete example. It does not explicitly name alternatives or exclusions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description's job is smaller, and it still adds real behavioral detail beyond them: domestic results include cancellations and fares in NT$, while international results fold code-share numbers into one flight. That code-share grouping and fare/cancellation disclosure materially changes how an agent should interpret results.

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?

Purpose is front-loaded in the first clause, with data-source nuance and alternatives following. Slightly dense with carrier names, but each sentence contributes distinct information and there is no filler.

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 read-only, no-output-schema tool, it covers scope, data sources, currency, code-share handling, and the alternative for live data. Only minor gaps remain, such as return volume behavior beyond the schema's limit default.

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 the schema already carries all parameter semantics, giving a baseline of 3. The worked example (from "松山" to "金門" on a date, or TPE to NRT) illustrates mixing local names with IATA codes but adds no format or constraint detail not already in the schema.

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?

States a specific verb and resource (scheduled flights between two airports on a day) and immediately qualifies the two data regimes: Taiwan domestic carriers vs. the published international timetable. An agent can distinguish it from flight_status and flight_board without opening any schema.

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?

Explicitly routes live-status queries to flight_status or flight_board, which is the key disambiguation for this cluster. It does not address adjacent timetable siblings such as flight_seats, but the primary when-not guidance is present.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing that TDX queries the airline live, that calls can take up to 30 s, and that UNI Air has request limits — operationally critical for an agent. It stops short of saying what happens on timeout or unsupported airline/date, which would complete the picture.

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?

Every clause carries information — scope, output tiers, latency, rate limit, batching rule, example. The opening sentence is somewhat convoluted ('per cabin when the airline says'), which costs a bit of front-loaded clarity, but nothing is padded.

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?

With no output schema, the description correctly compensates by enumerating the three availability levels and their per-cabin granularity. Combined with the latency and rate-limit warnings, an agent has enough to invoke it correctly; only error/failure behavior is unaddressed.

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 already 100%, so the baseline is 3; the description lifts this by giving a concrete worked example ('AE1273', '2026-11-02') and noting the airline-code requirement. It doesn't elaborate on the 'default: today' timezone beyond what the schema already states.

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?

States a specific resource (seat availability per cabin) with scope qualifiers (only domestic AE/B7/DA flights) and names the exact output categories (available, fewer than 5 left, sold out). An agent can immediately distinguish it from siblings like thsr_seats or flight_status.

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?

Explicitly says to call it for one flight at a time and warns that UNI Air permits few requests, which shapes how an agent should batch. It does not, however, contrast the tool with flight_status or flight_schedule, so the routing guidance is conditional rather than complete.

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

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

Annotations already declare readOnly and openWorld, so the bar is lower. The description still adds useful context by disclosing the temporal coverage ('flights around today') and the shape of returned data, which helps an agent know results are live and date-limited.

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?

Two compact sentences front-loaded with the core purpose, followed by the field list and a concrete example. The trailing example slightly duplicates the schema but is cheap and useful for recognition.

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?

No output schema exists, yet the description enumerates the returned fields (scheduled/estimated/actual times, delay, terminal, gate, status), which compensates well. The only gap is not clarifying how it differs from flight_board when a user asks for a board-style listing.

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 with patterns and examples. The description's 'CI100'/'B7 8751' example duplicates what the schema already shows, adding no syntax detail beyond it — 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?

States a specific verb+resource: 'Live status of a flight to or from Taiwan' and enumerates the returned fields (times, delay, terminal, gate, status). This separates it from flight_schedule/flight_board in spirit, though it never names those siblings 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?

Implies usage via 'TDX lists flights around today', telling the agent the data is near-real-time and date-bounded. However, it gives no explicit when-to-use vs. the many flight_* and other transport siblings, leaving the agent to infer that a timetable request belongs to flight_schedule.

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

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

Annotations only say read-only and open-world; the description adds what comes back (fare in NT$, broken out by passenger type, plus distance), which is meaningful since no output schema exists. It stops short of naming the passenger types or stating whether cross-system trips are supported.

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?

One compact sentence followed by a concrete example, front-loaded with the core purpose. 'with the distance' is slightly tacked on but nothing 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 3-parameter, read-only fare lookup with no output schema, the description covers purpose, currency, and the shape of the result. The remaining gap is which passenger types are returned and whether an unsupported station pair errors or returns null.

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 100% and already documents station name/ID formats and every system enum value. The description's example adds a concrete TRTC/台北車站/淡水 call pattern, which is mildly useful but largely restates schema conventions.

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?

States a specific verb+resource: single-journey metro fares between two stations, with currency and per-passenger-type dimension. The 'metro' scope implicitly separates it from thsr_fare/tra_fare siblings, though it never names them.

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?

Usage is only implied by the worked example (system TRTC, from 台北車站, to 淡水). There is no explicit statement of when to choose this over thsr_fare or tra_fare, or any prerequisite such as both stations needing to be on the same system.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results are grouped per line and direction, which helps interpret the response, but says nothing about schedule coverage (weekday/weekend/holiday) or data freshness.

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?

Two sentences, purpose first, example second. Nothing is wasted and the key scope (per line and direction) is front-loaded. The example earns its place by showing accepted argument formats.

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?

With only two fully documented parameters, read-only annotations, and no output schema, the definition is largely sufficient for correct invocation. The only material gap is not stating whether 'first and last' covers weekdays, weekends, or holidays — minor for a schedule lookup.

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%: the enum lists all seven systems and the station field documents name-or-ID forms. The description's example (system "TRTC", station "台北車站") only restates what the schema already provides, so 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+resource plus scope: first and last train times at a station, broken out per line and direction. This is clearly distinguishable from metro_live_board (current departures) and metro_fare, though it never names those siblings 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 intended use (looking up the first/last departure at a station) is implied by the purpose statement and illustrated by the example. However, there is no explicit when-to-use/when-not guidance, and no pointer that live departures belong to metro_live_board instead.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: coverage of the Wenhu line despite it having no timetable, and that results vary by day of week. It does not discuss caching, update cadence, or what happens for lines without frequency data.

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?

Two dense sentences plus a one-line example, with the core measurement front-loaded before the coverage caveat and the sample invocation. Nothing is redundant with the title or schema.

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?

There is no output schema, so the description carries the return-value burden and does so by naming the payload fields (minutes between trains, peak vs off-peak, operating hours). With three fully documented parameters and read-only annotations, an agent has everything needed 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 coverage is 100%, with each parameter described and an enum for system, so the baseline is 3. The description reinforces the semantics with the TRTC/BR example and the day-of-week meaning of date, but adds no format or constraint detail beyond the schema.

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?

States a specific resource and measurement: headway in minutes between trains by line, split into peak and off-peak, plus operating hours for a given day of the week. The note that it covers the Wenhu line 'which has no timetable' implicitly separates it from timetable-style siblings like bus_timetable or thsr_timetable, so an agent can pick it without opening the schema.

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 'for a day of the week' framing plus the worked example (system "TRTC", line "BR") gives clear invocation context. It stops short of naming alternatives or exclusions, e.g. that first/last train times belong to metro_first_last_train even though operating hours are mentioned here.

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

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

Annotations cover read-only and open-world safety, so the bar is lower, and the description adds real value on top: the per-system result semantics and the warning that an empty TRTC response is normal behaviour rather than failure. It does not discuss rate limits, caching, or coverage gaps for stations without service.

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?

Three tight sentences, front-loaded with the return content, then the caveat that prevents misreading empty results, then an example. Nothing is redundant and nothing is buried.

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?

With no output schema, the description must convey what comes back, and it does: minutes until next trains, per line and destination, plus the system-dependent variance. Minor gaps remain around whether multiple upcoming trains are returned per destination and how stations without service appear.

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 100% and the enum already spells out all four system codes with Chinese and English names, so the schema carries the parameter burden. The worked example (system "KRTC", station "美麗島") usefully signals that station values are local-language names, but that is the only addition beyond structured fields. 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?

Opens with a specific verb+resource: minutes until the next metro trains, broken down per line and destination. That is clearly distinct from timetable/fare siblings in the list, but the near-neighbour metro_first_last_train is never named or contrasted, so the differentiation is left implicit.

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?

Explains the operational condition that matters most: which systems return full station lists and that TRTC returns only imminent arrivals, so an empty Taipei board is expected, not an error. It also gives a concrete call example. It stops short of naming alternatives such as metro_first_last_train for first/last departure queries.

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

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

With readOnlyHint and openWorldHint annotations already covering the safety profile, the description still adds real substance by describing the shape of the answer, including the walking time at each change and the wait implied by current service frequency. It does not mention data recency or fallback behavior for cross-system itineraries, which keeps it from being fully transparent.

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 output content is front-loaded in the first sentence and the coverage/example follow, with no wasted clauses. It is dense for a single sentence, but every clause carries information an agent needs.

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?

With no output schema, the description takes on the job of explaining what comes back, and it does so thoroughly (legs, direction, stops, transfer walking, frequency, wait). Remaining gaps are minor: nothing on cross-system journeys or whether frequency is real-time for a future date.

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 100%: the schema already documents station names/IDs, the system enum, and the date format and default. The description's example values ('TRTC', '台北車站', '台北101/世貿') illustrate acceptable input but add little meaning beyond those schema descriptions, so the baseline of 3 is right.

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?

Names the exact resource (a metro journey's duration between two named stations) and the scope of what is returned: legs, lines, direction, stops, walking transfers, service frequency and expected wait. That combination clearly separates it from sibling tools such as metro_frequency (headways only), metro_fare and metro_first_last_train without needing to name them.

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 covered systems and the example pair of stations give an agent enough context to know when this tool applies, and the example is directly callable. It stops short of stating exclusions or naming an alternative for fare-only or timetable-only questions, so the routing guidance is implied rather than explicit.

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

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

Annotations already establish read-only and open-world behavior. Beyond that, the description discloses live-space filtering, fare and opening-status fields, nearest-first ordering, and city-specific coverage differences, which helps an agent understand what results mean. It does not discuss rate limits or response shape.

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?

Three tight sentences front-load the purpose, then add a coverage caveat and a concrete coordinate/city example without repetition. Each sentence contributes operational information.

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 an eight-parameter read-only search with no output schema, the description supplies the missing return-value context (live spaces, fare, opening status, nearest-first) and a coverage caveat. It stops short of describing the exact response structure, but the schema and annotations cover the rest adequately.

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 lat, lon, city, kind, want, vehicle, limit, and radiusMeters are already well documented. The description adds only an example and a city-coverage caveat, not additional parameter meanings beyond the schema.

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 names a specific resource (car parks and on-street parking), the spatial operation (nearest to a coordinate), and returned live attributes (free spaces, fare, opening status), so the tool's job is unambiguous. It does not explicitly differentiate this proximity search from sibling parking_search, which keeps it at 4 rather than 5.

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?

It gives a clear use context—nearest parking to lat/lon with live availability for cars or scooters—and warns that coverage differs by city, including NewTaipei's on-street-only limitation. It offers no explicit when-not guidance or alternative tool routing, so it is strong context but not full usage guidance.

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

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

Annotations already state readOnlyHint and openWorldHint, so the safety profile is covered. The description adds a behavioral claim that results come "with free spaces right now," but the schema's default want="any" returns every place and only want="space" filters out full/closed locations; this makes the description's availability statement misleading.

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 short, front-loaded, and uses compact examples that help clarify the keyword search. The only weakness is that the "with free spaces right now" clause is not just extra detail but potentially misleading.

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?

Given rich schema coverage and annotations covering read-only/open-world behavior, the description is mostly sufficient for calling the tool. It omits sibling differentiation and overstates availability, but the required parameters and keyword-search purpose are clear.

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 the schema already documents city, keyword, want, limit, and vehicle. The description only adds examples for city and keyword and does not clarify want, limit, or vehicle semantics beyond the schema, so baseline 3 is appropriate.

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 resource and filter: car parks and on-street parking matched by keyword in name, address, or road. The examples make the keyword-search intent clear, though it does not explicitly differentiate this from the sibling parking_nearby tool.

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?

Usage is implied by the required city and keyword parameters and the examples, so an agent can infer this is for name/road keyword lookups. However, there is no explicit guidance on when to use this instead of parking_nearby or other nearby-search tools.

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

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

The annotations already establish that this is a read-only, open-world query. The description adds useful behavioral context by explaining that “normal” is returned when everything runs, which clarifies the output when there is no disruption.

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 two compact sentences with the core purpose front-loaded. The parenthetical and example both add useful context without wasted wording.

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 one-parameter, read-only alert lookup, the description gives enough context to call the tool and interpret a “normal” result. It does not describe the structure of disruption alerts, but no output schema exists and the tool’s scope is narrow.

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%, and the enum values are fully documented in the schema. The description adds only an example value, “TRA,” so it does not materially extend parameter semantics beyond the schema.

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 clearly states that the tool returns current service status and disruption alerts for named rail systems, with a useful example. It is distinguishable from timetable and fare siblings, though it does not explicitly contrast itself with them.

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?

Usage is implied by “current service status and disruption alerts,” which suggests checking live conditions rather than schedules or fares. There is no explicit guidance on when to use this instead of related rail tools or when not to use it.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description only has to add behavioral texture, which it does: it discloses that results derive from the timetable rather than a live board, and that Taipei Metro's live board is arrivals-only, explaining why towers that system differently. It does not describe result shape or how sparse timetables (e.g. metro off-hours) behave.

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?

Two tight sentences plus an example block, with the core purpose and the alternative routing front-loaded. The embedded parenthetical about Taipei Metro arrivals-only is slightly awkward but carries real information, so it earns its place.

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 read-only, six-parameter query tool with no output schema, the definition covers purpose, system coverage, alternative tools, and worked examples. What remains unstated — result ordering and how empty/unsupported timetable cases surface — is minor but non-zero.

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 100%, so the baseline is 3, and the description goes beyond it by demonstrating concrete system/station/toward combinations (including mixed Chinese/English station naming) that show how the parameters compose in practice. It does not add anything about date/after/limit interplay, which the schema already covers.

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?

States a specific verb+resource ('A station's departures on a day') plus the source (timetable) and the scope of systems (TRA, THSR, metrocodes). It also names the sibling tools (tra_timetable, thsr_timetable) it is not, so an agent can distinguish it without opening the schema.

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?

Explicitly routes the agent away from this tool for between-two-stations queries ('Use tra_timetable or thsr_timetable for trains between two stations') and supplies two concrete call examples. It stops short of naming the live-board siblings (metro_live_board, tra_live_board) as alternatives, leaving that inference to the agent.

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

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

Annotations already cover safety (readOnlyHint, openWorldHint), and the description adds genuinely non-obvious behavior: passing coordinates changes the ordering of results by distance. It also enumerates what the records contain. It does not mention truncation behavior beyond the schema default or what an empty/unknown station yields.

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?

Two sentences plus a compact example, front-loaded with what is returned and followed by the optional-parameter behavior. The first sentence is long and dense but every clause carries content; nothing is filler.

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?

With no output schema, the description takes on the return-shape burden and does so by listing exits, accessibility modes, and facility locations. Combined with a fully documented 5-parameter schema and read-only annotations, an agent has enough to call it correctly; only error/empty cases are unaddressed.

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 100%, so the baseline is 3; the description goes beyond it by explaining that lat/lon are the destination coordinates used for distance ranking, not a station filter — a semantic the schema does not convey. It also demonstrates valid system/station value shapes with a concrete example.

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 names the concrete resources returned — station exits with stair/escalator/lift status, plus lifts, toilets and information desks — for TRA, THSR and metro systems. It is clearly distinguishable from timetable/live-board siblings, though it never states that it is a single-station lookup rather than a search.

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?

Usage is only implied: the reader infers 'call this when you need to know how to get out of a station and what facilities it has'. The one explicit guidance is to supply lat/lon so exits are sorted by distance, with a worked example. No alternatives (e.g. rail_station_search) are named or excluded.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results carry IDs and that names may be ambiguous, but says nothing about what happens when keyword and coordinates are supplied together, how limit interacts with distance sorting, or whether a bad system code errors out. With annotations doing the heavy lifting, this is adequate but not rich.

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?

Two sentences plus a dual example, front-loaded with the capability, then the routing rule, then concrete invocations. Every clause carries information; nothing is repeated from the title or schema.

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?

With no output schema, the description usefully notes that station IDs are returned, and the schema documents all five parameters including defaults and limits. The only real gap is precedence/combination behavior between keyword and coordinate inputs, which an agent must guess.

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%, including a fully enumerated system field with bilingual expansion, so the schema carries parameter meaning on its own. The examples do show how system combines with lat/lon versus keyword, which adds a little value beyond per-parameter docs, but not enough to exceed the baseline by much.

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?

States a specific resource (rail stations), two lookup modes (by name in Chinese/English, or nearest to a coordinate) and a key output detail (station IDs). It also distinguishes itself from the surrounding rail tools by noting those accept names directly, so an agent can tell this is the lookup/exploration primitive.

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?

Explicitly gives the when-to-use conditions: explore, find the nearest station, or resolve an ambiguous name — and implicitly gives when-not-to-use by saying other rail tools take names directly. The two worked examples (TRTC with lat/lon, TRA with a Chinese keyword) anchor each mode concretely.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds useful behavioral context: no caching, null/empty fields dropped, and TDX field names required in query options. It does not cover auth or rate limits, but it adds meaningful details beyond the annotations without contradicting them.

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, compact, and efficient. It covers purpose, fallback usage, field-name semantics, caching behavior, and an example without wasted text.

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 generic open-world query tool with six fully documented parameters and no output schema, the description provides enough context to call it correctly. The Swagger link and example compensate for the inherently open-ended response shape.

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 100%, so the schema already documents all six parameters. The description adds semantic value by explaining that filter/select/orderBy use TDX field names and by providing a concrete example.

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: GET any TDX API path with OData options. It clearly positions the tool as a generic fallback, which distinguishes it from the many specific sibling tools.

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?

It gives an explicit routing rule: use this tool only when no specific tool covers the data. This tells the agent both when to use it and when to prefer the specialized siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and data-source openness are covered. The description's added value is the response content dimensions (car class, passenger type, NT$ currency), but it says nothing about live vs. static pricing, caching, or whether both directions return differently-priced results.

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?

One front-loaded sentence carrying purpose, currency, and response dimensions, followed by a short concrete example. No filler, nothing buried.

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?

With no output schema, the description must convey the return shape; it names the fare dimensions (standard/business/non-reserved, adult/child/senior) but not the container structure or whether results are a flat list. Adequate to call correctly, but thin for interpreting the response.

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 100% — both 'from' and 'to' are documented with name-or-ID formats and examples in the schema itself. The description's example ('台北' to '台南') reinforces usage but adds no syntax or constraint information beyond the schema. 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?

States a specific verb+resource: single-journey fares between two stations, in NT$, broken out by car class and passenger type. This is clearly a fare-lookup tool, distinguishable in kind from thsr_timetable or thsr_seats, though it never explicitly names those siblings.

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?

Usage is only implied by the phrase 'single-journey fares between two stations'. There is no statement of when to pick this over tra_fare or metro_fare, nor any note that it returns fares without schedules or availability. The agent must infer scope from the domain.

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

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

Adds real context beyond annotations: data freshness ('updated about every 10 minutes') and the closed vocabulary of availability values. It does not clarify scope limits (e.g., whether non-reserved/free seats are excluded) or behavior for past dates, but readOnlyHint already covers the safety profile.

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?

Two sentences, front-loaded with the returned resource before the freshness note and example. The trailing example slightly duplicates the schema's own station examples but costs little.

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 read-only, no-output-schema query, the description says what comes back (availability state per class with times), which is the key missing piece. Minor gaps remain around coverage of seat types and empty-result behavior.

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 100% and every parameter is documented there, including station name/ID forms and defaults. The description's example merely restates accepted input syntax already given by the schema, so it adds no new semantics.

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?

States a specific resource (reserved-seat availability) with the exact return values (available, limited, sold out), both classes, and station pair plus times. An agent can distinguish it from timetable/fare tools, though it never names a sibling 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?

Usage is only implied by the example ('from 台北, to 台中'); there is no statement of when to prefer this over thsr_timetable or thsr_train, nor any precondition such as requiring a travel date.

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

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

Annotations already cover the read-only and open-world aspects, and the description adds real value on top: the four-week data horizon and the 'from now on for today' default scoping behavior. It also enumerates the returned fields, though it says nothing about result ordering, pagination, or empty-result behavior.

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?

Three short sentences, front-loaded with the core capability, then the coverage constraint, then a compact example. No sentence is redundant and nothing buries the key information.

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?

With no output schema, the description usefully names the returned attributes and the data horizon, which is what an agent needs to interpret results. It could still say what happens when a date is beyond the four-week window or when no trains remain after the given time.

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 the schema already documents every parameter including station name/ID alternates and defaults. The worked example (台北/左營/2026-10-23/08:00) illustrates valid value forms, but that is reinforcement rather than new semantic detail, so the 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 gives a specific verb and resource: THSR trains between two stations on a given day, and names the fields returned (departure, arrival, travel time). It is clearly distinct from fare or live-board siblings, though it never explicitly contrasts itself with thsr_train or rail_station_departures, which sound adjacent.

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?

It states the usable time window precisely: 'from now on for today' and 'TDX covers about four weeks ahead', so an agent knows the valid date range and the default starting point. It does not name an alternative tool for out-of-range dates or for seat availability, so the guidance stops short of explicit when-not/alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and data-source nature are covered. The description adds that the result is the full stop sequence with times, but says nothing about ordering, transfer notes, or data freshness.

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?

Two short sentences, front-loaded with the core behavior and followed by a concrete input example. Nothing redundant.

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 read tool with no output schema, the description conveys what comes back (all stops plus times) adequately. Minor gaps remain around ordering and date defaults, but those are largely covered by the schema.

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 100%, so baseline is 3, but the description earns extra credit by showing that trainNo tolerates leading zeros ("0803" or "803"), a behavioral detail the bare pattern ^\d{1,4}$ does not make obvious.

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?

States a specific verb and resource: 'Every stop of one THSR train on a day' with the returned fields (arrival/departure times). It is clearly a per-train stop list, distinguishable from thsr_timetable or thsr_seats, though it does not name those siblings 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 example trainNo values give practical guidance on input format, but there is no statement of when to use this versus thsr_timetable (schedules) or thsr_seats. Usage is implied by the purpose rather than spelled out.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds valuable behavioral context by specifying that fares are returned per train type and passenger type, along with distance—information not present in annotations. No rate limits or error behavior are described, but that is less critical here.

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, front-loaded sentence with an example, containing no redundant or filler content. Every part earns its place.

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?

Given the tool's simplicity, rich parameter schema, and the absence of an output schema, the description is complete enough: it clarifies the return content (fares per train type/passenger type, distance) and provides a usage example. Nothing essential for correct invocation 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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description provides an example (from '臺北' to '高雄') that illustrates station name usage, but it adds little beyond what the schema already conveys. Baseline 3 is appropriate.

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 (fares) and resource (TRA single-journey between two stations), and distinguishes itself from timetable/train siblings by focusing on fares. It also details the output breakdown by train type, passenger type, and distance.

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 context implies usage (when you need TRA fares between two stations), but there is no explicit guidance on when to choose this over alternatives like thsr_fare or tra_timetable. No exclusions or prerequisites are mentioned.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description is not responsible for safety signaling. It adds important behavioral context: results contain live-stream links rather than still images, and the user must open the link to watch, which prevents a common misuse.

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 compact and front-loads the resource and scope, with examples at the end. It is somewhat dense in a single sentence, but every clause carries useful information.

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 read-only lookup with a fully documented 7-parameter schema and no output schema, the description covers the essential scope, query modes, return nature (live-stream links), and practical examples. It could mention field-level return contents, but the critical behavioral caveat is present.

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 100%, so the baseline is 3; the description earns extra credit by showing how key parameters pair in practice (network+keyword, network+lat/lon). It does not explain direction, radiusMeters, or limit, but the schema already documents those fully.

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?

States a specific resource (live traffic cameras) and scope (national freeways, provincial highways, or city roads), which distinguishes it from siblings such as traffic_live or traffic_events. The verb/resource pairing is obvious and immediately actionable.

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?

Explains the supported query modes (by road, place, or distance) and gives concrete examples for freeway+keyword and city+lat/lon usage. It does not explicitly compare against sibling tools, but the camera-specific scope and live-stream caveat provide clear context for when to use it.

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

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

Annotations already declare readOnlyHint and openWorldHint so the safety profile is covered. The description adds genuine context beyond that: results are 'current' plus forward-looking announced events, each carries location and severity ('how much they block'), and coverage spans both cities and provincial highways. It omits pagination/rate behavior, but the extra coverage-and-severity context earns a 4.

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?

Two sentences, front-loaded with the resource catalogue before the examples. Slightly wasteful that the example clause is vaguely worded ('or network "Taipei", lat 25.0478, lon 121.517'), but nothing is padded.

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?

There is no output schema, so the description must convey return content, and it does at a high level: each event has a location and a blocking/severity measure. The absence of any mention of result ordering, limit behavior, or the shape of the severity value is a modest gap for a 7-parameter query tool.

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 every parameter including enum values and defaults is already documented in the schema; baseline is 3. The description's examples do add a little by showing that network accepts city names alongside a coordinate pair, but no additional syntax or constraint detail is supplied.

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?

States a concrete resource set — accidents, roadworks, congestion, traffic control, weather closures plus announced events — and the geographic scope (cities and provincial highways). That is far more specific than the title 'Road incidents and closures'. It does not, however, distinguish itself from siblings like traffic_live or traffic_signs, which also deal with road conditions.

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?

Usage is only implied through two worked examples (network "freeway" + type "accident"; network "Taipei" with lat/lon), which show how to combine parameters but never say when to pick this tool over traffic_live, traffic_cameras, or traffic_signs. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds behavior beyond that: results are sorted most-congested-first, include a count of sections per congestion level, and freeway sections follow an interchange naming convention that affects how queries must be built.

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?

Three sentences, front-loaded with what the tool returns, then search approach, then a concrete example. Dense with useful content and no filler, though the example sentence is somewhat long.

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?

There is no output schema, and the description compensates by describing the return shape (speed/congestion values, ordering, per-level counts). It stops short of naming the exact fields, but 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 coverage is 100%, so baseline is 3; the description goes further by explaining the cross-parameter relationship between network and keyword/lat-lon, which the schema documents only in isolation. It also reinforces the accepted network values with an example.

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?

States a specific resource (live speed and congestion of road sections) plus scope (national freeways, provincial highways, or a city's roads) and the ordering rule (most congested first). It is clearly distinguishable from siblings like traffic_events, traffic_cameras, and traffic_travel_time.

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?

Gives concrete usage context: freeway sections are named after interchanges so search by keyword, while city sections can be searched by lat/lon, with a worked example. It does not explicitly say when to prefer this over traffic_travel_time or traffic_events, but the guidance is actionable.

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

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

Annotations already establish that this is a read-only, open-world lookup. The description adds useful context about what the signs display and that the data is current, but it does not discuss output shape, pagination behavior, or any operational limits beyond what the schema and annotations provide.

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 two tight sentences with the core concept front-loaded and a concrete example following immediately. There is no redundant restatement of the tool name or title.

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?

Given seven parameters, full schema coverage, and annotations covering read-only/open-world behavior, the description provides enough context to understand what the tool returns and how to start using it. It could be slightly stronger by clarifying the return format or distinguishing it from nearby traffic data tools, but it is broadly complete.

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 parameter meanings are already well documented in the input schema. The description's example adds a small amount of practical context for network, keyword, and direction, but it does not meaningfully extend understanding of the other parameters.

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 clearly identifies the resource: live messages displayed on changeable road signs, including travel times, congestion, incidents, and roadworks. It is distinguishable from generic traffic tools, but it does not explicitly name or contrast with siblings such as traffic_live or traffic_events.

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?

Usage is implied by phrases like "show right now" and the example invocation with network, keyword, and direction. However, there is no explicit guidance on when to choose this over traffic_live, traffic_events, or traffic_cameras, nor any when-not-to-use condition.

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

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

With readOnlyHint and openWorldHint already provided, the description adds meaningful behavioral context: the values are live/right-now, derived from eTag gantry times, and the response includes route, distance, average speed, and per-segment metrics. It does not cover failure modes or data freshness limits, but it goes well beyond the annotations.

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, then compactly enumerates return contents and ends with a concrete example. Every clause contributes useful information without repetition.

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 read-only two-parameter traffic tool with no output schema, the description supplies the necessary return-value context and data source. An agent has enough information to know what the tool will produce and when it is appropriate.

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 the schema already defines both parameters with examples of Chinese interchange names. The description's example reinforces the naming convention but adds no syntax or semantic detail beyond the schema, making the baseline 3 appropriate.

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 query (current car travel time) over a specific resource (national freeway interchanges), and it distinguishes itself from siblings like metro_travel_time by naming the freeway/eTag-gantry context. It also summarizes exactly what is returned: fastest route, distance, average speed, and per-segment time/speed.

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?

It clearly implies the use case (real-time freeway driving between named interchanges) and gives an example, but it does not explicitly state when not to use it or name alternatives such as metro_travel_time for non-freeway trips. The context is clear without explicit exclusions.

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

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

Annotations already declare a safe read-only and open-world operation. The description adds useful behavioral context by disclosing that only imminent trains are returned and that delay and platform are included.

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 short, front-loaded with the core purpose, and every sentence contributes either scope clarification or sibling routing. The example is compact and directly relevant.

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 one-parameter read tool with a fully documented schema and clear annotations, the description supplies enough detail about scope and returned fields. No output schema is needed, and the key limitation is stated.

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 schema already provides 100% coverage for the single station parameter, including name/ID examples. The description's example station adds little beyond what the schema already documents, so the baseline 3 is appropriate.

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: trains about to arrive at or leave a TRA station now, with delay and platform. It also distinguishes this live-board tool from the sibling tra_timetable, which covers later trains.

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?

It explicitly limits scope to imminent trains and directs agents to tra_timetable for later ones. The station example further clarifies intended use without leaving the now-vs-later distinction ambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds a genuine behavioral trait: the upstream data horizon of about two months ahead, and the fact that today's results start from now. It does not mention the default result cap or what happens when no trains match.

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?

Three short sentences, front-loaded with the resource and return fields, then the coverage caveat, then a concrete example. Slightly telegraphic ("from now on for today") but no sentence 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?

With no output schema, the description usefully enumerates the returned fields and states the data horizon, which is enough for an agent to call it correctly. Remaining gaps are minor: result-count default is only in the schema, and directionality/empty-result behavior is unstated.

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 the schema already documents station name/ID formats, date pattern, HH:mm for after, and limit bounds. The description's example (from "臺北", to "花蓮", date "2026-10-23") reinforces format but adds no semantics the schema lacks, and it says nothing about `limit` or the `after` cutoff beyond the default.

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?

States a specific resource and scope: TRA trains between two stations on a given day, plus exactly what each row contains (train type, departure, arrival, travel time). Naming TRA (臺鐵) implicitly separates it from thsr_timetable/thsr_train and the bus/ferry timetable siblings, but it never explicitly contrasts with tra_live_board or tra_train, so sibling disambiguation is left to inference.

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?

"TDX covers about two months ahead" is a real usage constraint and "from now on for today" signals the default behavior for same-day queries. However, no alternative is named — an agent must guess whether live departures belong to tra_live_board or whether a single train's details belong to tra_train.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds that the response includes live position and delay, which is genuinely useful context. It does not cover staleness, missing delay data, or behavior for out-of-service train numbers, so the addition is modest.

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?

Two tight sentences, front-loaded with the resource and payload. The trailing example duplicates the schema's own example, which is the only wasted clause.

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?

With one required parameter, no output schema, and annotations covering the read-only safety profile, the description gives enough about the return contents (stops, times, live position, delay) for an agent to call it correctly. Edge-case behavior is the only omission.

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 100% and the single parameter already carries a pattern and an example, so the description's "Example: trainNo \"123\"" largely restates structured data. Baseline 3 applies since the schema does the semantic work.

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?

States a specific resource (one TRA train, today) and enumerates the payload: stops with times, live position, delay. That clearly separates it from tra_timetable and tra_live_board in spirit, though no sibling is 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?

"Today" implies this is the real-time lookup rather than the schedule lookup, so the usage window is inferable. But there is no explicit statement of when to prefer it over tra_timetable or tra_live_board, and no note about what happens for trains not running today.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description still adds real value beyond them by disclosing that results are live availability data, that only operating stations are eligible by default, and that output is sorted nearest-first. It omits any note on rate limits or freshness/latency of the live counts, which would complete the picture for an open-world network call.

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?

Two sentences, front-loaded with the core purpose and result shape, followed by a single compact example; nothing is redundant or padded.

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?

With no output schema, the description does the necessary work of naming the return fields (regular bikes, e-bikes, empty docks) and the sort order. With all six parameters fully described in schema, the only remaining gap is failure behavior — e.g. empty result when no station falls inside the radius — and the distinction from `youbike_station`.

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 `lat`, `lon`, `city`, `want`, `limit`, and `radiusMeters` are all fully documented in structured fields, and the description's example coordinate largely duplicates the schema's own examples. The description adds only the intent-level framing of 'with live bikes and empty docks' rather than any parameter syntax or default detail, so the 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 states a specific verb+resource (find YouBike/Moovo stations nearest a coordinate) and specifies the returned payload (live bike counts, e-bike counts, empty docks) and ordering (nearest first). It does not, however, distinguish itself from the sibling tool `youbike_station`, which an agent would also plausibly pick for station lookups.

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 'nearest to a coordinate' plus the worked lat/lon/city example implies the use case (proximity search around a point), but there is no explicit when-to-use or when-not guidance and no mention of the sibling `youbike_station` as the alternative for single-station or by-ID lookups.

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

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

The annotations already establish that this is a read-only, open-world search. The description adds useful context that results include live bikes and empty docks and that keywords may be Chinese or English, but it does not describe return structure, pagination, or other behavioral details.

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 two tightly written sentences with the core purpose front-loaded and a concrete example attached. There is no wasted language.

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?

Given full schema descriptions, annotations, and the absence of an output schema, the description supplies enough context to invoke the tool correctly. Minor gaps like return shape or pagination behavior are acceptable because the schema and annotations carry most of the burden.

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 the city, keyword, want, and limit parameters are already well documented in the schema. The description reinforces the keyword example but adds no meaningful semantics beyond what the schema provides.

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 clearly states that this tool finds YouBike/Moovo stations by name or address keyword and includes live bike/dock availability. It is specific about the resource and search dimension, but it does not explicitly distinguish itself from the sibling tool youbike_nearby.

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?

Usage is implied: search by station name or address keyword when the user knows a textual identifier, as shown by the Taipei/臺北車站 example. However, there is no explicit guidance on when to use this versus youbike_nearby or other alternatives.

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