No user-submitted related servers found.
Scored across 19 tools
Most tools have distinct roles, but several clusters overlap: alerts, service_status, detours and service_changes all surface disruption data; arrivals and next_trains both return next trains at platforms; and stop, station, accessibility and nearest_stops/find_stops all resolve locations. The detailed descriptions do provide routing hints (e.g. 'Schedule only; use arrivals for real time', 'service_status is the first call'), which mitigates but does not eliminate misselection risk.
All names use snake_case, giving a consistent surface form. Most are noun-only (stop, station, routes, alerts, accessibility), with a minority using verb_noun (find_stops, nearest_stops), which is a minor stylistic deviation but still readable and predictable.
19 tools is at the heavy end but each maps to a distinct slice of a genuinely large transit domain (search, real-time, schedules, disruptions, accessibility, trip planning, geometry, feed health). It is slightly over the comfortable range, but no tool appears clearly redundant.
The surface covers the full rider lifecycle: discovery (find/nearest/stop/station), routing (routes/route_stops/route_shape), scheduling (service_hours/scheduled_departures), real-time (arrivals/next_trains/vehicles), disruptions (alerts/service_status/detours/service_changes), accessibility, and trip planning (connections), plus feed health. No obvious operational gaps remain for a TTC transit server.