Skip to main content
Glama

onebusaway-mcp-server

by io.github.cyanheads

Get Real-Time Arrivals

onebusaway_get_arrivals
Read-only

Real-time arrivals and departures at a stop. Returns predicted arrival times, schedule deviation (how many seconds late/early), vehicle positions, and any active service alerts. The predicted boolean on each arrival indicates whether GPS tracking backs the estimate — predicted=false means schedule-only. Use tripId from results for follow-up onebusaway_get_trip calls. Stop IDs use agency-prefixed format: {agencyId}_{localId} (e.g. "1_75403").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stopIdYesAgency-prefixed stop ID (e.g. "1_75403" for Metro Transit stop 75403). Use onebusaway_find_stops or onebusaway_search_stops to discover IDs.
minutesAfterNoInclude arrivals expected within the next N minutes. Defaults to 35.
minutesBeforeNoInclude arrivals that departed up to this many minutes ago. Defaults to 5.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoNumber of arrivals in the time window.
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when no arrivals were found — e.g. try expanding the time window or check for service alerts.
stopIdNoThe queried stop ID.
arrivalsNoArrivals and departures at this stop within the requested time window.
stopNameNoStop name.
situationsNoActive service alerts referenced by arrivals at this stop.
currentTimeNoServer time as Unix milliseconds, for computing countdown timers.
queriedStopNoStop ID queried.
windowMinutesNoTime window used for the arrivals query.

TDQS

A4/5.0
Behavior4/5

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

Beyond the readOnlyHint annotation, the description explains the meaning of the 'predicted' boolean (GPS-backed vs schedule-only), the return of schedule deviation in seconds, and the presence of vehicle positions and alerts. It also notes that tripId is available for follow-up calls. This adds valuable behavioral context not captured in annotations or output schema.

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

Conciseness5/5

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

The description is four compact sentences with no filler. It front-loads the core purpose, then details the key behavioral nuance (predicted boolean), follow-up usage, and a critical formatting rule. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of a full output schema and rich parameter descriptions, the description covers the essential behavioral aspects: what real-time data is returned, how to interpret the predicted flag, and how to chain to trip details. It does not explicitly steer users away from schedule-based tools, but that is a minor omission given the clear real-time focus.

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

Parameters3/5

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

The input schema already provides complete descriptions for all parameters (100% coverage), including the stop ID format and default values for minutesAfter and minutesBefore. The description reiterates the stop ID format but adds no new parameter-specific meaning beyond what the schema already documents, so it meets the baseline for schema-covered tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: it returns real-time arrivals and departures for a stop, including predicted times, schedule deviation, vehicle positions, and alerts. This distinguishes it from siblings like onebusaway_get_schedule_for_stop (static schedule) and onebusaway_get_stop (stop details) by emphasizing the real-time and predictive nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies real-time usage through terms like 'real-time', 'predicted', and 'GPS tracking', but it does not explicitly state when to use this tool versus alternatives such as onebusaway_get_schedule_for_stop. It offers follow-up guidance (use tripId for onebusaway_get_trip) and stop ID format, but lacks direct exclusions or comparisons to sibling tools.

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

All onebusaway-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Every tool targets a distinct operation: find_* for location-based search, search_* for text-based search, get_* for fetching by ID, list_* for enumeration, and get_arrivals for real-time vs get_schedule_for_* for scheduled data. Even similar pairs like find_routes/search_routes are clearly differentiated by their search mode.

Naming Consistency5/5

All tools follow a uniform `onebusaway_` prefix followed by a consistent verb pattern: find (location search), search (text search), get (retrieve by ID), list (enumerate), plus specific get_schedule_for_route/stop. Naming is entirely snake_case and logically structured.

Tool Count5/5

15 tools cover the full scope of a transit API without bloat: discovery (find/search), details (get), enumeration (list), real-time (arrivals/vehicles/trip), schedules, and alerts. Each tool serves a distinct purpose and fits within a typical well-scoped server.

Completeness5/5

The surface covers the primary travel workflows: finding routes/stops by location or name, retrieving full details, real-time arrivals/trip/vehicle tracking, scheduled departures for both routes and stops, service alerts, and agency enumeration. There are no obvious dead ends; each lookup provides IDs for follow-up queries.

Resources