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 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 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 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?

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=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?

Annotations already declare readOnlyHint and openWorldHint, and the description adds useful behavioral context: the tool covers reserved seats only, reports availability as available/limited/sold out, and refreshes about every 10 minutes. It does not explain rate limits or full response structure, but it meaningfully complements 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 short, front-loaded with the core purpose, and includes a useful example without unnecessary detail. Every sentence contributes to understanding the tool’s scope.

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 availability lookup with complete parameter descriptions and no output schema, the description is nearly sufficient: it names the statuses, classes, and train times returned, plus update frequency. It could more explicitly describe result ordering or structure, but the remaining gap is minor.

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, date, after, and limit are already documented. The description adds a helpful example for from/to, but does not provide additional semantics for date, after, or limit 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-like capability and resource: reserved-seat availability for THSR trains between two stations, including standard and business class and train times. This distinguishes it from sibling tools such as thsr_timetable and thsr_fare without needing to open 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 description clearly implies the tool is used to check seat availability between stations, but it does not explicitly state when to use it versus thsr_timetable or thsr_fare, nor does it provide exclusions. Usage is inferable but not guided.

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 behavior, and the description adds real value beyond them: the roughly four-week data coverage window and the default that results start from the current time today. This is meaningful scope context an agent could not infer 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?

Three compact sentences, front-loaded with the core operation, followed by coverage limits and a concrete example. The phrasing "from now on for today" is slightly awkward 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?

With no output schema, the description usefully names the returned fields (departure, arrival, travel time) and the data coverage window. It is complete enough to call correctly; only the limit/pagination behavior is left entirely to 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 description coverage is 100%, so the schema already documents from/to (names or IDs), date format, after time, and limit defaults. The example restates those formats rather than adding new semantics, 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: THSR trains from one station to another on a day, returning departure, arrival, and travel time. It is clearly distinguishable from siblings like thsr_train or thsr_seats, though it does not name any alternative 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?

"From now on for today" and "TDX covers about four weeks ahead" give useful temporal context for when this tool applies. However, it never says when to use thsr_train (single train lookup) or other siblings instead, and gives no exclusion 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 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 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 cover the safety profile (readOnly, openWorld), but the description adds genuinely new behavioral facts: the ~2-month forward data horizon and that today's results start from now rather than midnight. It omits how the default limit of 10 affects result truncation, which matters for a trip with many departures.

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: what it returns first, followed by the data horizon and a 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 compensates by naming the returned fields, and it covers the data availability window and today's filtering behavior. The only gap is result-count behavior (default limit 10) for a tool that can return many departures per day.

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 five parameters are already documented, including the name-or-station-ID flexibility and the `after` default. The description's example ('臺北', '花蓮', '2026-10-23') largely restates examples the schema already supplies, so the added value is marginal and 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: TRA trains between two stations on a given day, and even enumerates the returned fields (train type, departure, arrival, travel time). It does not explicitly name a sibling to differentiate from (tra_live_board, thsr_timetable), though 'on a day' plus the TDX horizon implicitly marks it as a scheduled timetable rather than 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?

The 'TDX covers about two months ahead' note and 'from now on for today' behavior give useful context for choosing this tool over a live board, and the worked example shows valid inputs. There is no explicit when-to-use / when-not-to-use statement or named alternative, so routing is inferred rather than stated.

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.