ttc-mcp

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

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses how alerts are joined to pathway nodes, that unmatched codes are reported with `node_match false`, that uncoded node counts are included, that upcoming outages are listed separately and do not affect units or the verdict, and that platform/entrance queries answer for their station via `queried_platform` or `queried_entrance`.

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 dense and front-loads the core purpose before detailing return semantics. It is longer than typical, but nearly every clause carries useful behavioral or parameter context, with only mild run-on density that could be improved with clearer separation.

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 a one-parameter tool with an output schema, the description is largely complete: it explains what the query accepts and what kinds of accessibility information are returned. It does not cover error handling or explicitly route the agent away from sibling tools, 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?

The input schema has zero description coverage for the single `query` parameter, so the description must compensate. It does by explaining that the query accepts a station id, name, or alias, or a stop, and that platform or entrance ids are also valid and answered at station level. It could still be stronger with format examples, but it adds substantial meaning beyond the bare 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 identifies the resource as station/stop accessibility data and enumerates the specific contents: wheelchair flags, station summary, elevator/escalator units, node matching, and step-free verdict. It is more specific than the generic `station` or `stop` siblings, though it does not explicitly name those alternatives.

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 purpose: call this when accessibility details are needed for a station or stop. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no direct comparison to sibling tools such as `station`, `stop`, or `alerts`.

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 no annotations, the description carries the full burden and does meaningful work: it discloses the data source ('the TTC's own site endpoints'), flags reliability as 'best effort', specifies the timezone (America/Toronto), and notes that stations/stops are resolved to objects and that nightly windows and shuttle info are included. It omits failure modes, rate limits or freshness/caching behaviour.

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: what it returns, how to filter, then operational caveats (resolution, timezone, best effort). Everything is front-loaded and the parenthetical asides are genuinely informative rather than 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?

An output schema exists, so return-value shape need not be restated, and the description covers scope, filters, timezone and reliability. The remaining gap is combinability of filters and the meaning of the unlisted 'type' enum members, which matters for a zero-coverage 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 0%, so the description must compensate, and it does partially: it names all four filters (route, station with 'id, name or alias', stop number, type). However, it never maps the 'type' parameter to its eight enum values, omits 'delay' and 'other' entirely, and says nothing about whether filters are optional or combined with AND.

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 ('Current TTC alerts') and enumerates the alert categories returned (subway closures, surface suspensions/detours, reduced speed zones, elevator/escalator outages), so an agent knows exactly what comes back. It never names the related siblings (detours, service_status, service_changes), so the differentiation is left to inference rather than stated.

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 alerts' and the filter list, but there is no explicit when-to-use guidance and no exclusion pointing at siblings like detours or service_status that cover overlapping ground. An agent must infer that this is the umbrella alerts feed rather than the narrower ones.

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?

Without annotations, the description discloses several behavioral traits: basis (realtime/schedule) with notes, closure handling, detour_id per row, disruption listing, best-effort sourcing from TTC endpoints, and that historical occupancy is out of scope. It does not cover auth or rate limits, but adds substantial context beyond schema.

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, well-structured paragraph with the core purpose front-loaded. Each sentence adds value (edge cases, data basis, detour info, limitations) without excessive verbosity.

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 no annotations, 0% schema coverage, and the presence of an output schema, the description covers behavioral aspects well but omits parameter semantics and explicit usage guidance, leaving gaps 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 description coverage is 0%, so the description must compensate, but it provides no explanation of the 'stop', 'limit', or 'route' parameters. No format, expected values, or effects are described.

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 the tool returns next vehicles at a bus/streetcar stop or next trains at a rail platform, with real-time or schedule basis. It distinguishes itself from general vehicle tracking but does not explicitly name alternatives like next_trains or scheduled_departures.

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 for arrivals at a stop/platform, but provides no explicit when-to-use or when-not-to-use guidance relative to siblings. No alternatives are named.

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 no annotations, the description carries the whole burden and does so: it discloses the sampling cadence (every five minutes, ten past a 30-minute window), the Pareto ranking over arrival and transfers, the basis taxonomy (realtime/schedule/estimate) and the one-hour realtime freshness bound. It also anticipates failure modes — closures masking a section, shuttle legs assumed rather than timed and ranked last with estimate: true, detours carrying published delays, and empty answers stating why — plus that live data is best effort.

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?

Dense but justified — the length is bought by eight undocumented parameters and rich behavioral caveats, and the purpose is stated in the first clause before detail. It loses a point for being a single run-on paragraph where parameter ranges are buried mid-prose, which makes scanning harder than it needs to be.

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 8-parameter tool with no annotations and no schema descriptions, this is complete: it covers valid inputs, defaults, mutual exclusion, ranking, live-data caveats and degradation paths. Return-value explanation is not needed because an output schema exists, yet it still tells the agent what each ride and option carries (basis, disruptions per leg, first-ride next departures).

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 carry everything, and it does: it documents the four accepted origin/destination forms (stop number, station id, alias, {"lat","lon"} from a geocoder), the ISO timezone fallback for depart_at, and explicit ranges for window_min (0-60), max_transfers (0-3), walk_m (1-2000 m) and limit (1-10). It also explains the semantic difference between depart_at and arrive_by rather than just their types.

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 and resource: 'Timetable-exact trips between two places on the TTC,' and immediately qualifies the output as real trips with departure/arrival, not schedules or stop lists. No sibling tool performs point-to-point journey planning, so an agent can distinguish it from find_stops, scheduled_departures or next_trains without opening a 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 an explicit either/or for the two mutually exclusive time modes ('give one or the other') and states what each returns, which is exactly the decision an agent has to make. It stops short of naming when to prefer a sibling (e.g. scheduled_departures for a single stop), so it is clear context without explicit sibling 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?

With no annotations, the description carries the burden and adds real signal: it discloses the upstream data source (TTC's own site endpoints), the 'best effort' reliability caveat, the grouping key, and null semantics for the reason field. It omits freshness/refresh expectations and whether results are cached, which keeps it short of 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?

Resource and scope are front-loaded in the first clause, and the second sentence delivers the data-quality caveat without padding. The middle enumeration is dense but every item maps to real returned 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?

The output schema exists, so return values need no prose explanation, and the data-source caveat is covered. However, for a tool with no annotations and a completely undocumented sole parameter, the description should say how 'route' filters results and when to prefer alerts/service_changes.

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% for the single 'route' parameter, and the description never mentions it — no explanation of accepted route identifier format, whether it narrows to one route, or what omitting it returns. That leaves the only input entirely undocumented across both prose and 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 (active surface detours from the TTC TripModifications feed) and enumerates the per-detour payload, so the agent knows exactly what comes back. It does not explicitly distinguish itself from siblings like alerts or service_changes, though the 'service change' mention gives a partial hint at the boundary.

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?

There is no statement of when to call this instead of alerts or service_changes, nor any prerequisites or exclusions. The phrase 'Active surface detours' implies the use case, but an agent comparing three similarly-themed siblings gets no 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?

With no annotations, the description carries the full burden and does reasonably well: it explains the tool reads process-cached state and, critically, discloses that probe=true triggers one live request per source (a network side effect with likely latency). It does not mention any cost/timeout of probing, and read-only nature is only implied, keeping it below 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?

Two compact sentences with no filler; the freshness scope is front-loaded and the probe rule is placed last as an actionable modifier. The dense parenthetical of internal fields is slightly hard to parse but every element is substantive, so no waste.

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?

An output schema exists, so return-value explanation is not required, and the description appropriately focuses on scope and the probe side effect. For a simple 1-parameter diagnostic tool this is nearly complete; the only missing piece is usage context, which is scored separately under guidelines.

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 explain the single parameter, and it does: 'probe=true makes one live request per source,' which conveys the difference between cached (default) and live behavior. It does not explicitly restate the false/default path, but the cached framing implies it, landing just short of full coverage.

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 specifies the resource precisely: freshness/health of the static feed plus every real-time source, with concrete reported fields (TTL state, age, feed timestamp, last error, NTAS coverage). It is clearly distinguishable from all transit-data siblings (stops, routes, arrivals, etc.). It loses a point only because it leads with a noun phrase rather than an explicit verb, and 'NTAS' is unexplained jargon.

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?

There is no statement of when to use this tool versus alternatives like service_status or service_changes, nor any condition such as 'call when data appears stale/before trusting cached results.' The probe=true note is invocation detail, not usage guidance. An agent must infer the when-to-use context.

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?

No annotations are provided, so the description carries the full burden. It does disclose a genuinely non-obvious domain trait — that stops are directional and the two sides of an intersection are separate stop numbers with different headsigns — which prevents a real class of errors, but says nothing about result volume, default limit behavior, or whether the search is fuzzy or exact.

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, both load-bearing: the first defines the operation and inputs, the second delivers the directionality caveat. Front-loaded with zero padding.

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?

Return values are covered by the output schema, and the query/direction concepts are addressed, but for a 5-parameter tool with no annotations and no schema descriptions, the filtering parameters (mode, route, limit) remain undefined in every layer an agent can see.

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% across 5 parameters. The description explains only `query` (accepted key types plus an alias example); `mode`, `limit`, `route` and `direction` are never mentioned, and the enum values '0'/'1' for direction are not connected to the headsign/directionality sentence.

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 ('Find') and resource ('TTC stops, platforms or stations') plus the lookup keys (name, stop number, station name, alias). An agent can infer this is a text-search over stops rather than a proximity lookup, but the description never names nearest_stops or stop to make the boundary explicit.

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 alias example ('Dundas' resolves to TMU) gives a usable hint about input expectations and implicitly distinguishes this from geographic search via nearest_stops, but there is no explicit when-to-use/when-not guidance or named alternative across the 18 sibling 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?

No annotations exist, so the description carries the full burden. It does usefully disclose the per-result payload (walk minutes, routes, directions, headsigns, active disruptions) and implies a proximity-ordered read, but says nothing about empty-result behavior, radius-outside behavior, rate limits, or auth, which matter for a live transit API.

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 dense sentence, front-loaded with the core action and with the geocoding caveat in parens where it's scannable. Slightly run-on at the tail enumerating return fields, but no dead weight.

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?

An output schema exists, so return values needn't be explained, and the description covers purpose plus ranking input. But for a five-parameter tool with zero schema documentation and no annotations, the absence of any mention of radius, limit, or kind filtering leaves the agent guessing how to tune the 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 0% across five parameters. The description only implies lat/lon and loosely gestures at `kind` via 'stops and stations'; it never explains `radius_m` (default 500), `limit` (default 10), or how `kind` filters results — the three parameters most likely to be mis-set.

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 with scope: stops and stations nearest a coordinate. That proximity framing is distinct from the name-oriented siblings (find_stops, stop, station) and lets an agent pick it without opening schemas, but 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?

Gives a real precondition — geocode addresses with a maps tool first — which prevents a whole class of failed calls. It stops short of stating exclusions or naming find_stops as the alternative for name-based lookup, so it's clear context rather than full when/when-not 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?

With no annotations, the description carries the full behavioral burden and does well by explaining the timetable fallback, that an empty NTAS answer does not mean no trains, and how active closures affect predictions. It does not discuss authentication, rate limits, or explicit read-only status, but it provides strong edge-case transparency.

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 and then explains relevant fallback and closure semantics. It is dense but mostly earns its length, though the parenthetical line breaks and nested caveats make it slightly harder to scan than ideal.

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 one-parameter read tool with an output schema, the description covers the important behavioral context: station versus platform queries, NTAS fallback, empty-response meaning, and closure semantics. An agent can invoke it correctly without additional explanation.

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 gives only a bare string for query, so the description adds necessary meaning by saying it accepts a station id, name, or alias such as "Dundas" or "Bloor", or a single platform id. It stops short of documenting platform-id format or validation rules, but it compensates well for the 0% schema description coverage.

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 next trains at every rail platform of a station or at a single platform id, sourced from TTC's NTAS. The verb and resource are specific, though it does not explicitly distinguish itself from nearby siblings such as arrivals or scheduled_departures.

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 explains the two main usage modes: querying by station id, name, or alias, or querying by a single platform id. It also clarifies fallback and closure behavior, but it does not explicitly say when to use this tool instead of sibling tools like arrivals or scheduled_departures.

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?

No annotations exist, so the description carries the full burden. It discloses the returned fields and the special overnight semantics, which is real context, but says nothing about result size, pagination, filter combination logic, or ordering for what is likely a large unfiltered list.

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 with no filler, and the enumeration of available data is front-loaded before the overnight special case. The parenthetical value lists make it dense but they earn their space given 0% schema coverage.

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?

An output schema exists, so return structure needn't be explained, and all three parameters receive semantic treatment. What remains missing is filter-interaction behavior and volume expectations for an unfiltered call, which matters for a catalog of this size.

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 0%, so the description must compensate — and it largely does, enumerating the accepted mode values (subway, lrt, streetcar, bus) and series values (rail, bus, express, blue-night, community, streetcar) and explaining overnight. The only gap is that it never states whether mode, series and overnight are AND-combined or independent.

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 ("All TTC routes") and enumerates the attributes returned (mode, series, service hours by day type, overnight share), so an agent knows this is the route catalog. It does not name any sibling (route_stops, service_hours, find_stops) to draw the boundary, but the resource is distinct enough to be 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?

"overnight=true lists the Blue Night network" is the only conditional guidance and it is genuinely useful. There is no statement of when to reach for this tool versus service_hours or route_stops, and no mention of whether filters combine or what happens with no filters at all.

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 no annotations, the description carries the behavioral burden and does well: it explains output formats, Douglas-Peucker simplification, pattern ranking, and span slicing semantics including first-visit behavior for repeated stops. It does not explicitly state read-only behavior or permission requirements, leaving a minor 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?

The description is dense but front-loaded around the core return value and then adds important optional behavior. The single long sentence is efficient, though the packed clause structure could be slightly harder to scan.

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?

An output schema exists, so return-value structure does not need full explanation. Still, for a complex 7-parameter tool with no annotations and 0% schema coverage, the description leaves required-parameter meaning and usage routing insufficiently covered.

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, and it does for most parameters: format, pattern rank, simplify_m, and from_stop/to_stop semantics are explained. However, it does not clarify the required route identifier format or what direction values '0' and '1' mean, leaving key required-parameter semantics implicit.

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 precisely what the tool returns: a route direction's most-used stop pattern geometry as polyline or GeoJSON, with stops and distance along the shape. It distinguishes itself from siblings like route_stops by describing the geometric shape plus stop distances rather than just an ordered list of 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?

Usage is implied by the geometry-focused description, but there is no explicit when-to-use or when-not-to-use guidance relative to siblings such as route_stops or stop. The agent can infer context but must decide on its own when this tool is preferable.

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?

No annotations exist, so the description carries the full burden. It does disclose the result shape and the meaning of the status values (open, closed due to station closure, skipped_by_detour), which is genuine behavioral context, but it says nothing about read-only nature, error behavior for unknown routes, or why branches are grouped separately.

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 single dense, front-loaded sentence with no filler; the returned fields are enumerated efficiently. It is slightly over-packed into one sentence, which makes the scoping and the output catalog harder to scan separately.

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?

An output schema exists, so the description needn't re-describe returns, yet it spends its words there while leaving the two required parameters and the optional pattern parameter undocumented. For a 3-parameter tool with zero schema descriptions, that leaves the caller guessing on direction encoding.

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 0%, so the description must compensate and it largely doesn't: it never explains the format of 'route', never states what direction value '0' versus '1' means, and never mentions the optional 'pattern' parameter at all despite pattern grouping being central to the output.

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 clearly what is returned: ordered stops for a given route and direction, grouped by stop pattern, with trip counts, headsigns, typical minutes, and per-stop status. This distinguishes it implicitly from find_stops/nearest_stops (name-based or proximity lookup) by its route+direction scoping, but it never names a sibling or explicitly contrasts the scope.

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?

There is no guidance on when to use this versus find_stops, nearest_stops, stop, or route_shape, nor on prerequisites such as needing a valid route identifier. The agent must infer the use case purely from the returned-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?

With no annotations, the description carries the burden and discloses the key behavioral traits: this is a scheduled/timetable view, not real-time, the time parameter defaults to now, and past-midnight previous-day trips are included. Auth, rate limits, and pagination behavior for limit are not covered, which keeps it from 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?

Two sentences, zero filler, with the core purpose and the schedule-vs-real-time distinction front-loaded before the edge case.

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?

An output schema exists, so return values need no explanation, and the description covers the nontrivial traps (real-time confusion, past-midnight trips, default time). The undocumented limit and route parameters are 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 0%, so the description must compensate for all four parameters. It explains stop and adds meaning beyond the schema for at ("default now" versus the schema's null), but route and limit are never mentioned even though both affect results.

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 (timetable departures at a stop) with scope (from a given time, default now) and an edge case (previous-service-day trips running past midnight). The contrast with arrivals makes it unmistakable among siblings such as next_trains or connections.

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?

"Schedule only; use arrivals for real time" gives an explicit when-not and names the alternative, which is exactly the confusion an agent would have in this sibling set. It stops short of routing among the other boarding-related siblings (next_trains, connections, service_hours).

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 no annotations, the description carries the transparency burden and usefully discloses merged upstream sources, conditional ttc.ca publication, and best-effort reliability. It still omits explicit read-only status, authentication/rate-limit expectations, and failure/empty-result behavior beyond 'best effort'.

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: source composition, filters, and reliability caveat appear in order. Every sentence 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?

An output schema exists, so return-value documentation is not required here. The description covers sources, merge behavior, filters, and best-effort caveats, but it could be more complete by specifying parameter formats and how this tool relates to nearby alert/detour tools.

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 explain both parameters. It does give meaning to both: route filtering and a date that the change must cover. It does not specify expected date or route formats, leaving some ambiguity.

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 and sources: board-period service changes built from GTFS-RT MODIFIED_SERVICE alerts and ttc.ca's service-changes list. It is specific about what the tool returns, but it does not explicitly distinguish itself from siblings such as alerts, detours, or service_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?

It explains the available filters (route and date coverage) and notes that results are best effort, which implies usage for board-period route changes. However, it gives no explicit when-to-use/when-not guidance or alternatives versus alerts, detours, or service_status.

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 no annotations, the description carries the full burden. It usefully discloses the GTFS-specific convention that times past 24:00 belong to the previous service day, which is non-obvious behavior. However, it does not explicitly state the operation is read-only, nor does it mention error conditions or permission requirements.

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 with zero waste. The core purpose is front-loaded, followed by the essential GTFS caveat. Every sentence 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?

The output schema exists, so return values need not be explained. However, for a two-parameter query with 0% schema coverage and no annotations, the description leaves gaps around parameter formats/defaults and read-only behavior. It is adequate but not complete for an agent to invoke correctly without inference.

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 0%, so the description must compensate. It implies the parameters 'route' and 'date' from context, but does not specify the date format, what a null date means (e.g., today?), or what form the route identifier takes. This leaves important parameter semantics undocumented.

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 purpose: whether a route runs on a date and its first/last trip times, including holiday exceptions. It is clear what resource and operation are involved, though it does not explicitly differentiate itself from siblings such as service_status or scheduled_departures.

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?

There is no explicit when-to-use guidance, no mention of alternatives, and no prerequisites. The description implies the tool is for checking service calendars, but offers no routing advice to help an agent choose it over 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?

With no annotations, the description carries the full burden and does meaningful work: it discloses the data provenance ("the TTC's own site endpoints"), an accuracy caveat ("best effort"), and a freshness field (as_of) that lets the agent judge staleness. It does not mention auth, rate limits, or caching, but for a zero-parameter read tool this is solid disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The usage guidance is front-loaded in the first clause, then the payload contents are listed in a scannable semicolon series with zero filler. It is a single long sentence and slightly run-on, which costs it a point, but every clause names a distinct returned artifact.

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?

An output schema exists, so the description need not explain return shapes, yet it still sketches the major sections so the agent knows what to expect. Combined with the best-effort caveat and freshness field, an agent has enough to call it and interpret results, with only minor gaps around data recency guarantees.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema is empty with additionalProperties false, consistent with the description implying a global, unfiltered snapshot.

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 enumerates concrete resources returned (subway closures as station spans, suspended/detoured surface routes with skipped-stop counts, reduced speed zones, elevator/escalator outages, counts and as_of), so an agent knows exactly what this returns. It positions itself as the entry point ahead of siblings like alerts, detours and service_changes, 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 first call for any trip or 'what's going on' question" gives an explicit trigger condition and tells the agent to prefer this over the narrower siblings. It stops short of stating when-not-to-use or naming which sibling to fall back on for a specific sub-question.

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?

No annotations are supplied, so the description carries the full burden. It discloses useful behavioral content — open/closed status, service level per line with the closure, and all disruptions touching the station — but says nothing about how `query` is matched (exact id vs fuzzy name/alias), whether multiple matches can occur, or what happens on a miss.

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 single sentence, front-loaded with the resource and accepted keys before the parenthetical detail. It is dense and parenthesis-heavy 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?

An output schema exists, so the long enumeration of returned fields is largely redundant, while genuinely missing information (station-vs-stop disambiguation, query matching semantics, not-found behavior) goes unaddressed. Complete enough to attempt a call, but not complete enough to call confidently.

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 0% — `query` is a bare string with no description — so the description must compensate. 'By id, name or alias' does add real meaning over the schema, but it gives no id format, no example, and no indication of whether ambiguity is tolerated, leaving the most-used parameter still underspecified.

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 resource (subway or LRT station), the accepted lookup keys (id, name or alias), and enumerates the payload (rail platforms, surface stops, entrances, accessibility, service per line, disruptions). That is a specific and distinguishable purpose, but it never contrasts itself with the sibling `stop` tool, which sounds near-identical to an agent scanning the tool list.

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 phrase 'by id, name or alias' signals a point lookup when you already have an identifier. There is no statement of when to prefer `find_stops` or `nearest_stops` for discovery, or `stop` for single surface stops, and no exclusions or prerequisites.

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 no annotations, the description carries the full burden. Enumerating the returned facets implicitly conveys that this is a pure read/lookup with no side effects, which is the key behavioral signal here. It does not state behavior on an invalid or unknown stop number, nor mention rate limits or data freshness for the live disruption data, so the transparency is adequate but not thorough.

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 dense sentence that front-loads the scope ('One stop... by public stop number') then lists the payload facets. Nothing is wasted, though the missing leading verb makes it read as a spec fragment rather than an instruction.

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?

An output schema exists, so restating the returned fields is largely redundant effort; the space would have been better spent on the input parameter and on error behavior. As a single-parameter lookup it is close to complete, but the unexplained input format and unstated not-found behavior leave real gaps.

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% on the single required parameter, so the description must compensate. It does partially: 'public stop number' distinguishes a rider-facing stop ID from an internal identifier, which the bare schema type 'string' does not convey. It still gives no format, example, or validation hint (e.g., numeric vs. alphanumeric).

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 scope: exactly one stop, looked up by public stop number, with the returned facets enumerated (name, coordinates, wheelchair flag, routes/headsigns, station membership, disruptions). The singular 'one stop' implicitly contrasts with the plural discovery siblings find_stops and nearest_stops, but it never names them explicitly and omits a leading verb, so differentiation must be inferred.

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?

'by public stop number' implies this is the lookup for agents that already hold a stop identifier, and the sibling set (find_stops for searching, nearest_stops for geolocation) makes the alternative paths guessable. However, there is no explicit when-to-use statement, no mention of what to do if the stop number is unknown, and no 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?

With no annotations, the description carries the full burden and does well: it names the upstream source (BusTime GTFS-Realtime), flags results as best effort, and declares historical occupancy out of scope. It does not state what happens when neither parameter is supplied, which matters for a tool with zero required parameters.

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 the capability, then the exclusion, then the caveat. The field list is dense but every element (bearing, speed, crowding) is a concrete selection signal for the agent.

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?

An output schema exists, so return shape need not be explained, yet the description still summarizes the key fields and adds the data-quality caveat. The only missing piece is the semantics of calling with no arguments, which the zero-required-parameter schema leaves live.

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 prose must supply meaning, and it does: `route` selects all vehicles on a route while `vehicle_id` is a fleet number for a single vehicle. It stops short of giving route format (number vs. name) or precedence when both are supplied, which is a real gap at 0% coverage.

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 ("Live positions of the buses and streetcars") and enumerates the returned fields, so an agent knows exactly what it gets. It also carves itself off from the sibling `next_trains` by naming the rail lines it cannot serve.

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 when-not (rail lines 1, 2, 4, 5, 6 publish no positions), the resulting behavior ("answer unavailable"), and the concrete alternative (`next_trains`). This is the strongest possible form for a retrieval tool.

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