Real-time transit stops, routes, arrivals, vehicle positions, and schedules via OneBusAway APIs.
Scored across 16 tools
Most tools target a distinct resource and operation, but the find_routes/search_routes and find_stops/search_stops pairs have overlapping purposes—proximity vs. name/code search—that could confuse an agent. get_stop_context also bundles several other tools' functionality, though its description clearly explains the composition.
All tools follow a consistent onebusaway_<verb>_<object> pattern in snake_case. Verbs like get, list, find, and search are used predictably, and multi-word targets like get_schedule_for_route and get_schedule_for_stop remain parallel and readable.
At 16 tools, the server is slightly above the ideal 3-15 range, but the breadth is justified by the transit domain covering agencies, routes, stops, trips, blocks, arrivals, alerts, and vehicles. Each tool earns its place, so the count feels reasonable rather than bloated.
The read-only OneBusAway surface is well covered: agency enumeration, route/stop search and details, real-time arrivals, trip status, vehicle positions, full schedules, blocks, and service alerts. There are no obvious dead ends for a transit-data consumer, and the cross-referenced IDs connect the tools into a complete workflow.
Find transit routes near a location, optionally filtered by name or number. Returns routes with IDs, short names, and descriptions. Use routeId values to fetch schedules, vehicles, or stop sequences.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude of the search center, in [-90, 90]. | |
| lon | Yes | Longitude of the search center, in [-180, 180]. | |
| query | No | Filter by route name or number (e.g. "44" or "Link Light Rail"). | |
| radius | No | Search radius in meters. Must be positive; capped at 1600m. Defaults to 500m. Ignored when latSpan and lonSpan are both set. | |
| latSpan | No | Optional bounding-box height in degrees, as an alternative to radius. Takes effect only when lonSpan is also set, in which case radius is ignored. | |
| lonSpan | No | Optional bounding-box width in degrees, as an alternative to radius. Takes effect only when latSpan is also set, in which case radius is ignored. |
| Name | Required | Description |
|---|---|---|
| count | No | Number of routes returned. |
| error | No | Present when the call failed. Absent on success. |
| query | No | Route name/number filter applied to the search, if any. |
| notice | No | Guidance when no routes matched — e.g. try a larger radius or different query. |
| routes | No | Routes found near the specified location. |
| limitExceeded | No | True if more routes exist beyond the returned set; narrow the radius or set latSpan/lonSpan to see all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds that routes can be filtered by name/number and returns IDs, short names, and descriptions, which is useful but not deeply behavioral. It does not discuss pagination, rate limits, or edge cases, but given the read-only annotation, the added context is acceptable.
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 primary purpose, and includes a concise follow-up hint. No wasted words or redundancy. The structure is efficient and scannable.
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 has 6 parameters (2 required) and a thorough schema, the description does not need to repeat parameter details. It states the return fields and hints at next steps. It does not mention the latSpan/lonSpan vs radius distinction, but the schema covers that. For a read-only search tool with a rich schema, this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented. The description's mention of 'optionally filtered by name or number' aligns with the query parameter but does not add new semantic depth beyond the schema. It also refers to routeId in output, not parameters. 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 clearly states the verb 'Find' and the resource 'transit routes' with a location context. It mentions optional filtering and return fields, making the purpose specific. However, it does not explicitly name sibling tools like search_routes or list_routes_for_agency to differentiate when to use this versus them, 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?
The description implies usage for location-based route discovery ('near a location') but does not explicitly state when not to use it or name alternative tools. It gives a follow-up hint to use routeId values, but that is about subsequent actions, not tool selection. No exclusions or alternative routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find bus stops near a location. Returns stops within a radius, each with ID, name, direction, served routes, and wheelchair boarding status. Use stopId values from results to fetch real-time arrivals with onebusaway_get_arrivals. Optionally filter by stop code (the number printed on the stop sign, e.g. "75403").
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude of the search center, in [-90, 90]. | |
| lon | Yes | Longitude of the search center, in [-180, 180]. | |
| query | No | Optional stop code filter (the number printed on the stop sign, e.g. "75403"). When provided, returns only stops matching this code within the radius. | |
| radius | No | Search radius in meters. Must be positive; capped at 1600m, beyond which results degrade. Defaults to 300m. |
| Name | Required | Description |
|---|---|---|
| count | No | Number of stops returned. |
| error | No | Present when the call failed. Absent on success. |
| query | No | Stop code filter applied to the search, if any. |
| stops | No | Stops within the search radius. |
| notice | No | Guidance when results are empty or truncated — e.g. how to narrow the radius or verify the stop code. |
| limitExceeded | No | True if more stops exist beyond the returned set; narrow the radius to see all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds useful behavioral context about what results contain and how stopId values feed into onebusaway_get_arrivals. It does not cover edge cases like empty results or radius degradation, but for a read-only lookup with an output schema this is adequate.
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 three short sentences with the core action front-loaded, followed by the return-value summary and a practical follow-up hint. Every sentence adds useful information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the readOnlyHint annotation, fully described parameters, and output schema, the description provides enough context for an agent to call the tool correctly. The only missing comparative context is how this tool relates to onebusaway_search_stops, but the tool is otherwise self-contained.
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 description does not need to compensate for undocumented parameters. The description restates the stop-code filter meaning but adds no parameter semantics beyond what the schema already provides, which matches the baseline of 3.
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 opens with 'Find bus stops near a location' and adds 'Returns stops within a radius, each with ID, name, direction, served routes, and wheelchair boarding status,' giving a specific verb, resource, and scope. It does not explicitly distinguish itself from the sibling onebusaway_search_stops, so it falls just 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?
The description clearly states the tool's purpose and gives an explicit downstream instruction: 'Use stopId values from results to fetch real-time arrivals with onebusaway_get_arrivals.' It does not explain when to prefer this tool over onebusaway_search_stops or list exclusions, so it is clear but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full detail for a service alert (situation) by ID. Returns the summary, description, reason (e.g. detour, construction), affected stops and routes, consequence description, and active time windows. Situation IDs appear in onebusaway_get_arrivals responses under situationIds and situations[].id.
| Name | Required | Description | Default |
|---|---|---|---|
| situationId | Yes | Situation/alert ID from onebusaway_get_arrivals (situations[].id or arrivals[].situationIds[]). |
| Name | Required | Description |
|---|---|---|
| id | No | Situation ID. |
| url | No | URL for more information about this alert, or null. |
| error | No | Present when the call failed. Absent on success. |
| reason | No | Reason code from TPEG: equipmentReason, environmentReason, personnelReason, miscellaneousReason, securityAlert. Null when not provided. |
| affects | No | Stops, routes, trips, or agencies affected by this alert. |
| summary | No | Short summary of the service alert. |
| severity | No | Severity level as reported by the agency, or null. |
| description | No | Longer description of the alert, or null. |
| consequences | No | Operational consequences of this alert. |
| activeWindows | No | Time windows when this alert is active. |
| consequenceMessage | No | Human-readable consequence description (e.g. "Detour in effect"), or null. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, covering the safety profile. The description adds beyond that by specifying the response contents and the upstream source of the ID, which helps the agent understand the tool's behavior without contradicting the annotation.
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 with no filler; the first front-loads the action and purpose, and the second is a brief, necessary provenance note for the input ID. 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?
For a single-parameter, read-only tool with an available output schema, the description fully covers what the agent needs: what the tool does, what it returns, and where the input ID originates. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter description already states the ID comes from onebusaway_get_arrivals under situations[].id or arrivals[].situationIds[]. The tool description repeats this same information, adding no new meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch full detail for a service alert (situation) by ID.' It then enumerates the returned fields (summary, description, reason, affected stops/routes, etc.), making it distinct from sibling tools that address routes, stops, or trips.
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 clear context by pointing out that situation IDs come from onebusaway_get_arrivals responses, which tells the agent exactly when to invoke this tool. It does not explicitly name exclusions or alternatives, but no competing sibling for alert details exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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").
| Name | Required | Description | Default |
|---|---|---|---|
| stopId | Yes | Agency-prefixed stop ID (e.g. "1_75403" for Metro Transit stop 75403). Use onebusaway_find_stops or onebusaway_search_stops to discover IDs. | |
| minutesAfter | No | Include arrivals expected within the next N minutes — an integer from 0 to 240. Defaults to 35. For a longer horizon, use onebusaway_get_schedule_for_stop. | |
| minutesBefore | No | Include arrivals that departed up to this many minutes ago — an integer from 0 to 60. Defaults to 5. |
| Name | Required | Description |
|---|---|---|
| count | No | Number of arrivals in the time window. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when no arrivals were found — widen minutesAfter, or check onebusaway_get_schedule_for_stop for scheduled service. |
| stopId | No | The queried stop ID. |
| arrivals | No | Arrivals and departures at this stop within the requested time window. |
| stopName | No | Stop name. |
| situations | No | Active service alerts at this stop — those attached to the stop itself and those referenced by its arrivals, each listed once. |
| currentTime | No | Server time as Unix milliseconds, for computing countdown timers. |
| queriedStop | No | Stop ID queried. |
| windowMinutes | No | Time window used for the arrivals query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, it discloses the predicted boolean semantics (predicted=false means schedule-only), what fields arrive with each result, and that service alerts are included. This materially helps the agent interpret responses.
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?
Four dense sentences with no filler; the core purpose is front-loaded and each additional sentence adds distinctive value.
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, single-required-parameter lookup with a full schema and output schema, the description covers return semantics, follow-up usage, and ID format. Nothing needed 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 coverage is 100%, so the schema already documents stopId, minutesAfter, and minutesBefore with types, defaults, ranges, and examples. The description adds only a repeated stop-ID format example, not new parameter meaning.
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: real-time arrivals and departures at a stop, and enumerates the data returned. The title and first sentence align, and it is clearly distinguishable from schedule-focused 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?
Explicitly tells the agent when to use it and when not: for real-time arrivals, and in minutesAfter it directs longer horizons to onebusaway_get_schedule_for_stop. It also routes tripId results to onebusaway_get_trip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full-day block schedule for a vehicle by block ID. A block is the ordered sequence of trips a single vehicle makes in one service day. Returns all trips in order with their stop times. Useful for 'when will this bus return?' and fleet tracking. Block IDs appear as blockId in onebusaway_get_trip responses; obtain a tripId from onebusaway_get_arrivals first.
| Name | Required | Description | Default |
|---|---|---|---|
| blockId | Yes | Block ID from a trip record. Obtain a tripId from onebusaway_get_arrivals, then call onebusaway_get_trip to get the blockId. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| trips | No | All trips in this block in order. |
| blockId | No | Block ID. |
| activeServiceIds | No | Service calendar IDs active for this block today. |
| inactiveServiceIds | No | Service calendar IDs not active for this block today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares safety, and the description adds behavioral context beyond that: full-day scope, guaranteed ordering of trips, and stop-time inclusion in the response. It does not discuss edge cases or errors, but for a simple read operation with an output schema this is reasonable coverage.
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?
Four sentences with no filler. The action is front-loaded, and each sentence earns its place: definition, return shape, use case, and blockId provenance.
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 output schema and readOnlyHint annotation, the description fully covers invocation: what the tool returns, why it is useful, and exactly how to obtain the required blockId. No essential information 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 blockId and its acquisition path. The description restates the same provenance workflow in prose, adding marginal value but not truly new semantic information.
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: 'Fetch the full-day block schedule for a vehicle by block ID.' It defines what a block is and what the response includes (ordered trips with stop times), clearly distinguishing it from route- or stop-based schedule tools among the 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?
Provides explicit use cases ('when will this bus return?' and fleet tracking) and a concrete input-obtaining workflow: get a tripId from onebusaway_get_arrivals, then call onebusaway_get_trip to get the blockId. It does not explicitly name alternative tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch details for a specific route by ID. Returns short name, description, agency, route type, and schedule URL. Route IDs use agency-prefixed format: {agencyId}_{localId} (e.g. "1_100259").
| Name | Required | Description | Default |
|---|---|---|---|
| routeId | Yes | Agency-prefixed route ID (e.g. "1_100259"). Use onebusaway_find_routes or onebusaway_search_routes to discover IDs. |
| Name | Required | Description |
|---|---|---|
| id | No | Agency-prefixed route ID. |
| url | No | Agency schedule page URL, or null. |
| type | No | GTFS route type: 0=tram, 1=subway, 2=rail, 3=bus, 4=ferry, 5=cable_car. |
| color | No | Route brand color hex (without #), or null. |
| error | No | Present when the call failed. Absent on success. |
| agencyId | No | Agency ID that operates this route. |
| longName | No | Full route name. |
| shortName | No | The number or short name displayed on vehicles (e.g. "44"). |
| agencyName | No | Agency name that operates this route. |
| description | No | Route description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the ID format requirement and the list of returned fields, which is useful context. However, it doesn't disclose behavior like error handling for invalid IDs, whether the response is paginated, or if the schedule URL is always present. With annotations covering the safety profile, a 3 is appropriate.
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 with zero waste. The core purpose is front-loaded, the returned fields are listed compactly, and the ID format example is placed at the end where it's most useful. 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?
Complete for a single-parameter read-only tool with an output schema present. The description covers what the tool does, what it returns, and how to get the ID. The only minor gap is not mentioning error behavior for invalid IDs, but given the output schema and annotations, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the routeId parameter with format and discovery hints. The description reinforces the format with an example but doesn't add meaning beyond what the schema provides. Baseline 3 is correct when schema does the heavy lifting.
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 fetches details for a specific route by ID, lists the exact fields returned (short name, description, agency, route type, schedule URL), and distinguishes it from sibling tools by emphasizing the route ID requirement. The verb 'Fetch' and resource 'route' are specific, and the ID format example removes ambiguity.
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 explicitly tells the agent to use onebusaway_find_routes or onebusaway_search_routes to discover IDs, which is clear usage guidance. It doesn't explicitly state when NOT to use this tool (e.g., when you need schedules, use onebusaway_get_schedule_for_route), but the context is sufficient for an agent to select it for route-detail lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-day schedule for a route — all trips, stop sequences, and departure times for the specified date (defaults to today). Returns up to all trips for the route. For live predictions, use onebusaway_get_arrivals at specific stops instead.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Service date as YYYY-MM-DD (e.g. "2026-05-23"). Must be a real calendar date. Omit or leave blank for today. | |
| routeId | Yes | Agency-prefixed route ID (e.g. "1_100259"). Use onebusaway_find_routes or onebusaway_search_routes to discover IDs. |
| Name | Required | Description |
|---|---|---|
| date | No | Date parameter used for the schedule request, if specified. |
| error | No | Present when the call failed. Absent on success. |
| trips | No | All trips for this route on this date, with their stop sequences. |
| notice | No | Guidance when no trips were found — e.g. no service on weekends or holiday schedule in effect. |
| routeId | No | The queried route ID. |
| tripCount | No | Number of trips for this route on this date. |
| queriedRoute | No | Route ID queried. |
| serviceDateMs | No | Service date as Unix milliseconds. |
| routeShortName | No | Route short name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds useful behavioral context: it returns a full-day schedule, includes all trips/stop sequences/departure times, defaults to today, and is not a live-prediction endpoint. It does not discuss result limits or edge cases, but the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the tool's main behavior, followed by the key alternative. There is no filler or redundant explanation; every sentence adds either scope, content, or routing guidance.
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?
Between the full parameter documentation, output schema, readOnlyHint, and the behavioral description, an agent has enough to select and call the tool correctly. It is slightly light on explicit disambiguation from stop-level schedules, but that does not block correct usage.
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 routeId and date thoroughly. The description contributes the 'defaults to today' nuance and implies date controls the service day, but these are mostly echoed in the schema. This is the appropriate baseline for full schema 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 is specific: 'Full-day schedule for a route — all trips, stop sequences, and departure times for the specified date.' It names the resource (route), the scope (full-day), and the return content, clearly separating it from live-prediction and stop-level siblings. The only slight omission is not explicitly contrasting with onebusaway_get_schedule_for_stop, but the route-level framing is unambiguous.
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 explicit routing rule: 'For live predictions, use onebusaway_get_arrivals at specific stops instead.' This tells an agent when not to use the tool and which sibling to choose. It does not exclude or contrast stop-level schedule retrieval, but the live-prediction distinction is the most important alternative condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-day departure schedule for a stop. Lists every departure by route and direction for the specified date (defaults to today). Useful for planning or when real-time data isn't needed. For live predictions, use onebusaway_get_arrivals instead.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Service date as YYYY-MM-DD (e.g. "2026-05-23"). Must be a real calendar date. Omit or leave blank for today in the agency's timezone. | |
| stopId | Yes | Agency-prefixed stop ID (e.g. "1_75403"). Use onebusaway_find_stops or onebusaway_search_stops to discover IDs. |
| Name | Required | Description |
|---|---|---|
| date | No | Date parameter used for the schedule request, if specified. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when no routes were found — e.g. no service on weekends or holiday schedule in effect. |
| routes | No | All routes with departures from this stop on this date. |
| stopId | No | The queried stop ID. |
| stopName | No | Stop name. |
| routeCount | No | Number of routes with departures from this stop on this date. |
| queriedStop | No | Stop ID queried. |
| serviceDateMs | No | Service date as Unix milliseconds (start of service day). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful behavioral context: the schedule defaults to today, lists all departures for the full day, and groups by route and direction. It does not disclose any other side effects, but none are expected for a read-only tool. It slightly goes beyond 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?
Three sentences with zero fluff. The core purpose is front-loaded, the usage guidance follows, and the alternative is mentioned last. Every sentence earns its place; no redundant or vague phrasing.
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 tool with 2 parameters and an output schema present, the description covers the essential operational details: what it returns, default behavior, and when to use an alternative. The output schema handles the return structure, so the description does not need to repeat it. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented in the schema (date format, stopId format, default behavior). The description does not add significant extra meaning to the parameters themselves; it only reiterates the default date behavior that is already in the schema. This meets the baseline for high 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 the verb and resource: 'Full-day departure schedule for a stop' with specific detail on what it lists (every departure by route and direction). It distinguishes from the sibling onebusaway_get_arrivals by explicitly noting that it is not for live predictions, so an agent can tell them apart without opening 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?
The description gives explicit when-to-use guidance ('Useful for planning or when real-time data isn't needed') and names the alternative tool (onebusaway_get_arrivals) for the opposite case. This directly answers the 'when vs alternatives' question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch details for a specific stop by ID. Returns the stop's name, coordinates, direction, served routes, and wheelchair accessibility. Stop IDs use agency-prefixed format: {agencyId}_{localId} (e.g. "1_75403" for Metro Transit stop 75403).
| Name | Required | Description | Default |
|---|---|---|---|
| stopId | Yes | Agency-prefixed stop ID (e.g. "1_75403" for Metro Transit stop 75403, "40_100239" for Sound Transit). Use onebusaway_find_stops or onebusaway_search_stops to discover IDs. |
| Name | Required | Description |
|---|---|---|
| id | No | Agency-prefixed stop ID. |
| lat | No | Latitude of the stop. |
| lon | No | Longitude of the stop. |
| code | No | The stop code printed on the sign. |
| name | No | Stop name. |
| error | No | Present when the call failed. Absent on success. |
| routeIds | No | IDs of routes that serve this stop. Use with onebusaway_get_arrivals or onebusaway_get_schedule_for_stop. |
| direction | No | Compass direction of travel at this stop (e.g. "NW"). |
| wheelchairBoarding | No | Wheelchair boarding status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read, and the description adds meaningful behavioral context by listing the returned attributes (name, coordinates, direction, served routes, wheelchair accessibility) and explaining the agency-prefixed ID format. No contradictions with annotations are present.
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, no filler, with the main action first and the most important ID-format detail immediately after the return values. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read operation, the description plus the fully documented schema and readOnlyHint annotation are sufficient for correct selection and invocation. The output schema also exists, so the description does not need to cover every return detail.
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 schema already provides examples and discovery guidance for stopId. The tool description adds a general ID format pattern, which is modestly helpful, but most parameter meaning is already carried by 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 states a specific verb ('Fetch') and resource ('details for a specific stop by ID') and enumerates the exact fields returned. This clearly distinguishes it from sibling tools like onebusaway_get_arrivals or onebusaway_get_schedule_for_stop, which serve different data for a stop.
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 makes clear this tool is for fetching a single stop's details when a stop ID is already known. The schema's parameter description further directs users to discover IDs via onebusaway_find_stops or onebusaway_search_stops, though the tool description itself does not mention exclusions or alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything happening at a stop in one call: the stop's details, its real-time arrivals, and full detail for every service alert on the stop or on any arrival in the window. Returns what onebusaway_get_stop, onebusaway_get_arrivals, and one onebusaway_get_alert call per alert would, from a single upstream request — arrivals in the onebusaway_get_arrivals shape, alerts in the onebusaway_get_alert shape. The stop omits its served-route list; use onebusaway_get_stop for routeIds. Stop IDs use agency-prefixed format: {agencyId}_{localId} (e.g. "1_75403").
| Name | Required | Description | Default |
|---|---|---|---|
| stopId | Yes | Agency-prefixed stop ID (e.g. "1_75403" for Metro Transit stop 75403). Use onebusaway_find_stops or onebusaway_search_stops to discover IDs. | |
| minutesAfter | No | Include arrivals expected within the next N minutes — an integer from 0 to 240. Defaults to 35. For a longer horizon, use onebusaway_get_schedule_for_stop. | |
| minutesBefore | No | Include arrivals that departed up to this many minutes ago — an integer from 0 to 60. Defaults to 5. |
| Name | Required | Description |
|---|---|---|
| stop | No | The queried stop, without its served-route list (use onebusaway_get_stop for routeIds). Null when the upstream response omitted the stop. |
| error | No | Present when the call failed. Absent on success. |
| alerts | No | Service alerts on this stop or on any arrival in the window, each listed once — including alerts whose affected arrivals fall outside the window. |
| notice | No | What the response is missing and where to get it — no arrivals in the window, stop details absent, or referenced alerts absent. |
| arrivals | No | Arrivals and departures at this stop within the requested time window. |
| currentTime | No | Server time as Unix milliseconds, for computing countdown timers. |
| queriedStop | No | Stop ID queried. |
| windowMinutes | No | Time window used for the arrivals query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, so the description correctly focuses on additional behavioral context: the single upstream request, the response shapes matching get_arrivals and get_alert, and the deliberate omission of routeIds. This goes beyond the annotation without contradicting it.
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 but information-dense: the main promise is front-loaded, then response shapes and exclusions follow in three purposeful sentences. No sentence is redundant or 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 multi-purpose aggregate tool, the definition covers what it returns, how results are shaped, what it omits, ID format, and relevant alternatives. Output schema and readOnlyHint fill the remaining context, and required parameter handling is fully specified.
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 clear descriptions, defaults, ranges, and discovery hints already on stopId, minutesAfter, and minutesBefore. The description adds an ID format reminder and points to sibling tools, but most parameter meaning is already carried by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource and operation: a single call that returns stop details, real-time arrivals, and full service alerts. It explicitly contrasts itself with onebusaway_get_stop, onebusaway_get_arrivals, and onebusaway_get_alert, so an agent can distinguish this aggregate from its 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?
The description states the intended use case ('Everything happening at a stop in one call') and gives an explicit exclusion: the stop omits routeIds, so use onebusaway_get_stop for that. The minutesAfter parameter schema additionally routes longer-horizon needs to onebusaway_get_schedule_for_stop, making alternatives and conditions clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real-time status and stop sequence for a trip. Returns vehicle position, schedule deviation, current phase, and remaining stops. Use tripId from onebusaway_get_arrivals to look up a specific vehicle's progress.
| Name | Required | Description | Default |
|---|---|---|---|
| tripId | Yes | Trip ID from an arrivals response or schedule lookup. | |
| serviceDateMs | No | Service date as Unix milliseconds (midnight local time) — a non-negative integer. Only needed for trips from a previous service day. Omit to use today. | |
| includeSchedule | No | Whether to include the full stop sequence with times. Defaults to true. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| status | No | Real-time status of the trip. |
| tripId | No | The queried trip ID. |
| blockId | No | Block ID grouping this trip with the others the same vehicle runs back-to-back. Pass to onebusaway_get_block for the full block schedule. Null when the trip has no block. |
| schedule | No | Full stop sequence with times, or null if includeSchedule=false. |
| situations | No | Active situation IDs affecting this trip. |
| tripHeadsign | No | Destination sign text. |
| routeShortName | No | Route short name (e.g. "44"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, which covers the read-only nature. The description adds that it returns real-time data and includes serviceDateMs for previous service day, a behavioral nuance. No contradictions.
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, front-loads the main purpose and outputs, and the usage hint is concise. No unnecessary words.
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 trip lookup with 3 parameters and an output schema, the description is fairly complete. It states the key outputs, the source of tripId, and the serviceDateMs caveat. It doesn't detail includeSchedule, but that is in the schema. Overall, it covers the essential information an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra semantics beyond the schema, such as reiterating that tripId comes from onebusaway_get_arrivals, which is already in the schema. It does not explain includeSchedule beyond what the schema says.
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 it retrieves real-time status and stop sequence for a trip, listing specific outputs (vehicle position, schedule deviation, current phase, remaining stops). It references the source of tripId from onebusaway_get_arrivals, which differentiates it from sibling tools like get_vehicles or get_arrivals.
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 a usage hint: 'Use tripId from onebusaway_get_arrivals to look up a specific vehicle's progress,' indicating when to use it after obtaining a tripId. However, it doesn't explicitly state when not to use it or mention alternative tools for similar purposes, so it's not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real-time positions of all active vehicles for an agency. Optionally filter to a single route (client-side). Returns GPS coordinates, heading, schedule deviation, and current trip. Useful for "where are all the buses on route X right now?" Use agencyId values from onebusaway_list_agencies.
| Name | Required | Description | Default |
|---|---|---|---|
| routeId | No | Optional agency-prefixed route ID to filter results to one route. Filtering is client-side — all agency vehicles are fetched first. | |
| agencyId | Yes | Agency ID (e.g. "1" for Metro Transit, "40" for Sound Transit). Use onebusaway_list_agencies to discover IDs. |
| Name | Required | Description |
|---|---|---|
| count | No | Number of vehicles returned after any route filter. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when no vehicles were found — e.g. the route may not be currently active, or the agency may not have real-time data. |
| routeId | No | Route ID filter applied client-side, if any. |
| agencyId | No | Agency ID queried. |
| vehicles | No | Active vehicles for the agency, optionally filtered by route. |
| limitExceeded | No | True if the upstream capped the vehicle list — some vehicles were omitted. This endpoint has no pagination to retrieve them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safe-read nature is already captured. The description adds meaningful behavior beyond that: filtering is client-side (all agency vehicles are fetched first), and the tool returns GPS coordinates, heading, schedule deviation, and current trip. This gives the agent expectations about data volume and output content without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the core function, filter option, return content, a typical use case, and where to find agency IDs. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return structure does not need to be fully explained in the description. The description covers the required agencyId source, optional route filtering, and the nature of the data. Minor gaps such as pagination or data freshness are not critical because the output schema provides response detail and the tool is read-only.
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 describes both parameters. The description adds value by giving example agency IDs ('1' for Metro Transit, '40' for Sound Transit) and by explicitly stating the route filter is client-side, meaning all vehicles are fetched before filtering. This helps an agent understand practical implications beyond the schema's basic field definitions.
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: 'Real-time positions of all active vehicles for an agency.' It clearly distinguishes itself from siblings by focusing on live vehicle positions, and lists concrete output fields (GPS coordinates, heading, schedule deviation, current trip). This is unique among the sibling tools, none of which cover real-time vehicle tracking.
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 clear context by framing the tool as useful for 'where are all the buses on route X right now?' and explicitly directs the agent to get agencyId values from onebusaway_list_agencies. It also explains the optional route filter, including the client-side behavior. It does not explicitly name alternative tools or exclusions, but no sibling offers the same real-time vehicle capability, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all transit agencies served by this OneBusAway instance. Returns agency IDs, names, contact info, timezone, and geographic coverage center. Agency IDs are needed for onebusaway_list_routes_for_agency and onebusaway_get_vehicles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | Number of transit agencies returned. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when no agencies were returned. |
| agencies | No | All agencies served by this OneBusAway instance. |
| limitExceeded | No | True if the upstream capped the agency list — some agencies were omitted. This endpoint has no pagination to retrieve them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, and the description adds useful scope and result details: it enumerates all agencies served by the instance and lists the specific returned fields. No hidden mutation or external-world behavior is suggested, and there is no contradiction with 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?
Three compact, front-loaded sentences: purpose, returned data, and downstream usage. Each sentence adds information without redundancy.
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 no-argument, read-only listing tool with an output schema, the description fully covers what an agent needs: what is listed, which fields are returned, and how the IDs feed into sibling tools. Nothing essential 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 tool has zero parameters, so the description has nothing to document beyond what the empty schema shows. This matches the baseline of 4 for a no-parameter tool.
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 opens with a specific verb and resource ('List all transit agencies served by this OneBusAway instance') and enumerates the returned fields (IDs, names, contact info, timezone, coverage center). This clearly distinguishes it from the sibling find/get/search 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 provides a clear usage context: agency IDs from this call are needed before calling onebusaway_list_routes_for_agency and onebusaway_get_vehicles. It does not explicitly state when not to use it or mention alternatives, but the no-argument list-all purpose is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all routes operated by an agency. Returns route IDs, short names, and descriptions. Use to enumerate an agency's full service before searching for a specific route. Get agencyId values from onebusaway_list_agencies.
| Name | Required | Description | Default |
|---|---|---|---|
| agencyId | Yes | Agency ID (e.g. "1" for Metro Transit, "40" for Sound Transit). Use onebusaway_list_agencies to discover IDs. |
| Name | Required | Description |
|---|---|---|
| count | No | Number of routes returned for this agency. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when no routes were found — verify the agency ID with onebusaway_list_agencies. |
| routes | No | All routes operated by this agency. |
| agencyId | No | Agency ID queried. |
| limitExceeded | No | True if the upstream capped the route list — some routes were omitted. This endpoint has no pagination to retrieve them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. It adds behavioral context by stating it returns all routes ('full service') and specifying the return fields (route IDs, short names, descriptions). This goes beyond annotations by clarifying the scope and output shape, which helps the agent understand what to expect. No contradictions.
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 three sentences with no wasted words. It front-loads the core action, then states return fields, then gives usage context and a cross-reference. Each sentence serves a distinct purpose, and the structure is logical and easy 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?
For a simple tool with one parameter and an output schema, the description covers all essential aspects: what it does, what it returns, and how to obtain the required input. It is sufficiently complete for an agent to decide when to use it and how to invoke it correctly. The presence of an output schema means the description doesn't need to explain return details.
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 description for agencyId is fully descriptive (100% coverage), including examples and a pointer to onebusaway_list_agencies. The description repeats the cross-reference but does not add any new meaning beyond the schema. Since schema already covers the parameter, the description adds minimal value here, matching the baseline of 3 for high schema 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 the verb (list), the resource (routes), and the scope (per agency). It explicitly says 'List all routes operated by an agency' and distinguishes itself from searching tools by framing it as 'enumerate an agency's full service before searching for a specific route.' This differentiates it from siblings like onebusaway_find_routes and onebusaway_search_routes.
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 clear guidance on when to use the tool: to enumerate an agency's full service before searching for a specific route. It also gives an explicit cross-reference for obtaining the required parameter via onebusaway_list_agencies. However, it does not explicitly name the alternative search tools (e.g., onebusaway_search_routes), leaving some inference for the agent about which sibling to use for targeted searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for routes by name or number. Returns matching routes with IDs. Use to resolve a route short name (e.g. "44") to a route ID for schedule or vehicle lookups with onebusaway_get_vehicles or onebusaway_get_schedule_for_route.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Route name or number (e.g. "44", "Link", or "RapidRide"). | |
| maxCount | No | Maximum number of results to return. A positive integer, at most 100. Defaults to 10. |
| Name | Required | Description |
|---|---|---|
| cap | No | The maxCount limit applied to truncated results. |
| count | No | Number of routes returned. |
| error | No | Present when the call failed. Absent on success. |
| query | No | Route name/number query sent to the API. |
| shown | No | Number of routes returned when results were truncated. |
| notice | No | Guidance when no routes matched — e.g. try onebusaway_find_routes with coordinates, or onebusaway_list_routes_for_agency. |
| routes | No | Routes matching the search query. |
| truncated | No | True when matching routes exceeded maxCount. |
| limitExceeded | No | True if more routes match than were returned; raise maxCount or refine the query to see all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds a useful context point about returning route IDs for follow-up lookups, but it does not disclose any additional behavioral details such as pagination, fuzzy matching, sorting, or case sensitivity. This is acceptable 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?
The description is two sentences with no filler. The core action and output are front-loaded, and the use case is stated efficiently. 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?
For a simple search tool with a read-only annotation, a complete output schema, and fully documented parameters, the description is nearly sufficient. It clearly connects the tool to a practical workflow. The only notable gap is the lack of guidance on how this tool relates to onebusaway_find_routes.
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 schema already documents 'query' and 'maxCount' with examples and constraints. The description echoes the query concept but does not add meaning beyond the schema. Baseline 3 is appropriate because the schema carries the parameter documentation burden.
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 clear action ('Search for routes by name or number') and resource, and clarifies the output ('matching routes with IDs'). It differentiates from get_route and schedule/vehicle tools, but does not distinguish itself from the sibling onebusaway_find_routes, which appears to be a very similar operation.
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 explicitly says when to use the tool: to resolve a route short name like '44' to a route ID for downstream schedule or vehicle lookups. It names the intended follow-on tools, but it does not provide exclusions or explain when to prefer onebusaway_find_routes instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for stops by name or code. Returns matching stops with IDs and coordinates. Use to resolve a human-readable stop name or number to a stop ID for arrivals lookups with onebusaway_get_arrivals.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Stop name fragment or stop code (e.g. "University Way" or "75403"). | |
| maxCount | No | Maximum number of results to return. A positive integer, at most 100. Defaults to 10. |
| Name | Required | Description |
|---|---|---|
| cap | No | The maxCount limit applied to truncated results. |
| count | No | Number of stops returned. |
| error | No | Present when the call failed. Absent on success. |
| query | No | Search query sent to the API. |
| shown | No | Number of stops returned when results were truncated. |
| stops | No | Stops matching the search query. |
| notice | No | Guidance when no stops matched — e.g. try a different name fragment or use onebusaway_find_stops with coordinates. |
| truncated | No | True when matching stops exceeded maxCount. |
| limitExceeded | No | True if more stops match than were returned; raise maxCount or refine the query to see all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read nature is externally known. The description adds useful behavioral detail by noting the return contains IDs and coordinateschers. It does not cover edge cases like ambiguous matches or pagination behavior, but given the annotation coverage this is acceptable.
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, each earning its place: what it searches, what it returns, and why you would use it. The main action is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with a complete input schema, an output schema, and readOnly annotations, this description covers the essentials: matching criteria, return contents, and the typical call flow. It could add a hint about what happens when no matches are found, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'query' and 'maxCount' are fully documented in the schema. The description adds the semantic context that the query can be a stop name fragment or stop code, but the schema already conveys this. 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 uses a specific verb ('search') targeting a clear resource ('stops') and specifies the matching criteria ('by name or code'). It further states the output ('IDs and coordinates') and the intended downstream use, making the tool's purpose unambiguous and distinguishable from the broader sibling set.
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 explicitly states when to use the tool: to resolve a human-readable stop name or number to a stop ID for arrivals lookups with onebusaway_get_arrivals. This gives clear usage context, though it does not explicitly exclude siblings like onebusaway_find_stops.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
onebusaway_get_arrivals10 fields changedInput schema / properties / minutesAfter / descriptionPrevious value: -"Include arrivals expected within the next N minutes. Defaults to 35."New value: +"Include arrivals expected within the next N minutes — an integer from 0 to 240. Defaults to 35. For a longer horizon, use onebusaway_get_schedule_for_stop."Input schema / properties / minutesAfter / maximumAdded value: +240Input schema / properties / minutesAfter / minimumAdded value: +0Input schema / properties / minutesAfter / typePrevious value: -"number"New value: +"integer"Input schema / properties / minutesBefore / descriptionPrevious value: -"Include arrivals that departed up to this many minutes ago. Defaults to 5."New value: +"Include arrivals that departed up to this many minutes ago — an integer from 0 to 60. Defaults to 5."Input schema / properties / minutesBefore / maximumAdded value: +60Input schema / properties / minutesBefore / minimumAdded value: +0Input schema / properties / minutesBefore / typePrevious value: -"number"New value: +"integer"Output schema / properties / notice / descriptionPrevious value: -"Guidance when no arrivals were found — e.g. try expanding the time window or check for service alerts."New value: +"Guidance when no arrivals were found — widen minutesAfter, or check onebusaway_get_schedule_for_stop for scheduled service."Output schema / properties / situations / descriptionPrevious value: -"Active service alerts referenced by arrivals at this stop."New value: +"Active service alerts at this stop — those attached to the stop itself and those referenced by its arrivals, each listed once."onebusaway_get_schedule_for_route3 fields changedInput schema / properties / date / anyOfAdded value: +[
+ {
+ "const": "",
+ "type": "string"
+ },
+ {
+ "description": "A real calendar date in YYYY-MM-DD form (e.g. \"2026-05-23\").",
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+ }
+]Input schema / properties / date / descriptionPrevious value: -"ISO 8601 date (e.g. \"2026-05-23\"). Defaults to today."New value: +"Service date as YYYY-MM-DD (e.g. \"2026-05-23\"). Must be a real calendar date. Omit or leave blank for today."Input schema / properties / date / typeRemoved value: -"string"onebusaway_get_schedule_for_stop3 fields changedInput schema / properties / date / anyOfAdded value: +[
+ {
+ "const": "",
+ "type": "string"
+ },
+ {
+ "description": "A real calendar date in YYYY-MM-DD form (e.g. \"2026-05-23\").",
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+ }
+]Input schema / properties / date / descriptionPrevious value: -"ISO 8601 date (e.g. \"2026-05-23\"). Defaults to today in the agency's timezone."New value: +"Service date as YYYY-MM-DD (e.g. \"2026-05-23\"). Must be a real calendar date. Omit or leave blank for today in the agency's timezone."Input schema / properties / date / typeRemoved value: -"string"onebusaway_get_stop_contextonebusaway_get_trip4 fields changedInput schema / properties / serviceDateMs / descriptionPrevious value: -"Service date as Unix milliseconds (midnight local time). Only needed for trips from a previous service day. Omit to use today."New value: +"Service date as Unix milliseconds (midnight local time) — a non-negative integer. Only needed for trips from a previous service day. Omit to use today."Input schema / properties / serviceDateMs / maximumAdded value: +9007199254740991Input schema / properties / serviceDateMs / minimumAdded value: +0Input schema / properties / serviceDateMs / typePrevious value: -"number"New value: +"integer"onebusaway_find_routes6 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode."New value: +"Machine-readable failure mode. Declared by this tool: `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesAdded value: +[
+ "rate_limited"
+]Output schema / properties / routes / items / properties / color / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / routes / items / properties / color / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / routes / items / properties / url / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / routes / items / properties / url / typeAdded value: +[
+ "string",
+ "null"
+]onebusaway_find_stops2 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode."New value: +"Machine-readable failure mode. Declared by this tool: `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesAdded value: +[
+ "rate_limited"
+]onebusaway_get_alert12 fields changedOutput schema / properties / consequenceMessage / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / consequenceMessage / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / description / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / description / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `situation_not_found`: Situation ID does not exist on this instance. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `situation_not_found`: Situation ID does not exist on this instance. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "situation_not_found"
-]New value: +[
+ "situation_not_found",
+ "rate_limited"
+]Output schema / properties / reason / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / reason / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / severity / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / severity / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / url / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / url / typeAdded value: +[
+ "string",
+ "null"
+]onebusaway_get_arrivals9 fields changedOutput schema / properties / arrivals / items / properties / predictedArrivalTime / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "null"
- }
-]Output schema / properties / arrivals / items / properties / predictedArrivalTime / typeAdded value: +[
+ "number",
+ "null"
+]Output schema / properties / arrivals / items / properties / stopsAway / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "null"
- }
-]Output schema / properties / arrivals / items / properties / stopsAway / typeAdded value: +[
+ "number",
+ "null"
+]Output schema / properties / arrivals / items / properties / vehicleId / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / arrivals / items / properties / vehicleId / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `stop_not_found`: Stop ID does not exist on this instance. `rate_limited`: API returned a rate limit response. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `stop_not_found`: Stop ID does not exist on this instance. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / situations / items / properties / description / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / situations / items / properties / description / typeAdded value: +[
+ "string",
+ "null"
+]onebusaway_get_block2 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `block_not_found`: Block ID does not exist on this instance. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `block_not_found`: Block ID does not exist on this instance. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "block_not_found"
-]New value: +[
+ "block_not_found",
+ "rate_limited"
+]onebusaway_get_route6 fields changedOutput schema / properties / color / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / color / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `route_not_found`: Route ID does not exist on this instance. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `route_not_found`: Route ID does not exist on this instance. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "route_not_found"
-]New value: +[
+ "route_not_found",
+ "rate_limited"
+]Output schema / properties / url / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / url / typeAdded value: +[
+ "string",
+ "null"
+]onebusaway_get_schedule_for_route2 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `route_not_found`: Route ID does not exist on this instance. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `route_not_found`: Route ID does not exist on this instance. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "route_not_found"
-]New value: +[
+ "route_not_found",
+ "rate_limited"
+]onebusaway_get_schedule_for_stop2 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `stop_not_found`: Stop ID does not exist on this instance. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `stop_not_found`: Stop ID does not exist on this instance. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "stop_not_found"
-]New value: +[
+ "stop_not_found",
+ "rate_limited"
+]onebusaway_get_stop2 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `stop_not_found`: Stop ID does not exist on this instance. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `stop_not_found`: Stop ID does not exist on this instance. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "stop_not_found"
-]New value: +[
+ "stop_not_found",
+ "rate_limited"
+]onebusaway_get_trip10 fields changedOutput schema / properties / blockId / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / blockId / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `trip_not_found`: Trip ID not found or not active for the service date. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `trip_not_found`: Trip ID not found or not active for the service date. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "trip_not_found"
-]New value: +[
+ "trip_not_found",
+ "rate_limited"
+]Output schema / properties / status / properties / closestStop / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / status / properties / closestStop / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / status / properties / nextStop / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / status / properties / nextStop / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / status / properties / vehicleId / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / status / properties / vehicleId / typeAdded value: +[
+ "string",
+ "null"
+]onebusaway_get_vehicles16 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `agency_not_found`: Agency ID does not exist on this instance. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `agency_not_found`: Agency ID does not exist on this instance. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "agency_not_found"
-]New value: +[
+ "agency_not_found",
+ "rate_limited"
+]Output schema / properties / vehicles / items / properties / nextStop / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vehicles / items / properties / nextStop / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / vehicles / items / properties / orientation / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vehicles / items / properties / orientation / typeAdded value: +[
+ "number",
+ "null"
+]Output schema / properties / vehicles / items / properties / routeId / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vehicles / items / properties / routeId / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / vehicles / items / properties / routeShortName / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vehicles / items / properties / routeShortName / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / vehicles / items / properties / scheduleDeviation / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vehicles / items / properties / scheduleDeviation / typeAdded value: +[
+ "number",
+ "null"
+]Output schema / properties / vehicles / items / properties / tripHeadsign / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vehicles / items / properties / tripHeadsign / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / vehicles / items / properties / tripId / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vehicles / items / properties / tripId / typeAdded value: +[
+ "string",
+ "null"
+]onebusaway_list_agencies4 fields changedOutput schema / properties / agencies / items / properties / phone / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / agencies / items / properties / phone / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode."New value: +"Machine-readable failure mode. Declared by this tool: `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesAdded value: +[
+ "rate_limited"
+]onebusaway_list_routes_for_agency6 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `agency_not_found`: Agency ID does not exist on this instance. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `agency_not_found`: Agency ID does not exist on this instance. `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "agency_not_found"
-]New value: +[
+ "agency_not_found",
+ "rate_limited"
+]Output schema / properties / routes / items / properties / color / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / routes / items / properties / color / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / routes / items / properties / url / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / routes / items / properties / url / typeAdded value: +[
+ "string",
+ "null"
+]onebusaway_search_routes2 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `endpoint_unavailable`: The search/route endpoint returns 404 on this OBA instance (e.g. Puget Sound). Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `endpoint_unavailable`: The search/route endpoint returns 404 on this OBA instance (e.g. Puget Sound). `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "endpoint_unavailable"
-]New value: +[
+ "endpoint_unavailable",
+ "rate_limited"
+]onebusaway_search_stops2 fields changedOutput schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode."New value: +"Machine-readable failure mode. Declared by this tool: `rate_limited`: No upstream request slot opened within the queue wait cap, or OneBusAway returned a rate limit response. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesAdded value: +[
+ "rate_limited"
+]onebusaway_find_routes6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "routes",
+ "limitExceeded",
+ "count"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "routes",
- "limitExceeded",
- "count"
-]onebusaway_find_stops6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "stops",
+ "limitExceeded",
+ "count"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "stops",
- "limitExceeded",
- "count"
-]onebusaway_get_alert6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "id",
+ "summary",
+ "description",
+ "reason",
+ "severity",
+ "consequenceMessage",
+ "affects",
+ "consequences",
+ "activeWindows",
+ "url"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `situation_not_found`: Situation ID does not exist on this instance. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "situation_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "id",
- "summary",
- "description",
- "reason",
- "severity",
- "consequenceMessage",
- "affects",
- "consequences",
- "activeWindows",
- "url"
-]onebusaway_get_arrivals6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "stopId",
+ "stopName",
+ "currentTime",
+ "arrivals",
+ "situations",
+ "queriedStop",
+ "count",
+ "windowMinutes"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `stop_not_found`: Stop ID does not exist on this instance. `rate_limited`: API returned a rate limit response. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "stop_not_found",
+ "rate_limited"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "stopId",
- "stopName",
- "currentTime",
- "arrivals",
- "situations",
- "queriedStop",
- "count",
- "windowMinutes"
-]onebusaway_get_block6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "blockId",
+ "activeServiceIds",
+ "inactiveServiceIds",
+ "trips"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `block_not_found`: Block ID does not exist on this instance. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "block_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "blockId",
- "activeServiceIds",
- "inactiveServiceIds",
- "trips"
-]onebusaway_get_route6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "id",
+ "shortName",
+ "longName",
+ "description",
+ "agencyId",
+ "agencyName",
+ "type",
+ "color",
+ "url"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `route_not_found`: Route ID does not exist on this instance. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "route_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "id",
- "shortName",
- "longName",
- "description",
- "agencyId",
- "agencyName",
- "type",
- "color",
- "url"
-]onebusaway_get_schedule_for_route6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "routeId",
+ "routeShortName",
+ "serviceDateMs",
+ "trips",
+ "queriedRoute",
+ "tripCount"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `route_not_found`: Route ID does not exist on this instance. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "route_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "routeId",
- "routeShortName",
- "serviceDateMs",
- "trips",
- "queriedRoute",
- "tripCount"
-]onebusaway_get_schedule_for_stop6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "stopId",
+ "stopName",
+ "serviceDateMs",
+ "routes",
+ "queriedStop",
+ "routeCount"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `stop_not_found`: Stop ID does not exist on this instance. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "stop_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "stopId",
- "stopName",
- "serviceDateMs",
- "routes",
- "queriedStop",
- "routeCount"
-]onebusaway_get_stop6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "id",
+ "code",
+ "name",
+ "lat",
+ "lon",
+ "direction",
+ "routeIds",
+ "wheelchairBoarding"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `stop_not_found`: Stop ID does not exist on this instance. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "stop_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "id",
- "code",
- "name",
- "lat",
- "lon",
- "direction",
- "routeIds",
- "wheelchairBoarding"
-]onebusaway_get_trip6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "tripId",
+ "routeShortName",
+ "tripHeadsign",
+ "blockId",
+ "status",
+ "schedule",
+ "situations"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `trip_not_found`: Trip ID not found or not active for the service date. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "trip_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "tripId",
- "routeShortName",
- "tripHeadsign",
- "blockId",
- "status",
- "schedule",
- "situations"
-]onebusaway_get_vehicles6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "vehicles",
+ "limitExceeded",
+ "agencyId",
+ "count"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `agency_not_found`: Agency ID does not exist on this instance. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "agency_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "vehicles",
- "limitExceeded",
- "agencyId",
- "count"
-]onebusaway_list_agencies6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "agencies",
+ "limitExceeded",
+ "count"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "agencies",
- "limitExceeded",
- "count"
-]onebusaway_list_routes_for_agency6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "routes",
+ "limitExceeded",
+ "agencyId",
+ "count"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `agency_not_found`: Agency ID does not exist on this instance. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "agency_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "routes",
- "limitExceeded",
- "agencyId",
- "count"
-]onebusaway_search_routes9 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "routes",
+ "limitExceeded",
+ "query",
+ "count"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / capAdded value: +{
+ "description": "The maxCount limit applied to truncated results.",
+ "type": "number"
+}Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `endpoint_unavailable`: The search/route endpoint returns 404 on this OBA instance (e.g. Puget Sound). Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "endpoint_unavailable"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / properties / shownAdded value: +{
+ "description": "Number of routes returned when results were truncated.",
+ "type": "number"
+}Output schema / properties / truncatedAdded value: +{
+ "description": "True when matching routes exceeded maxCount.",
+ "type": "boolean"
+}Output schema / requiredRemoved value: -[
- "routes",
- "limitExceeded",
- "query",
- "count"
-]onebusaway_search_stops9 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "stops",
+ "limitExceeded",
+ "query",
+ "count"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / capAdded value: +{
+ "description": "The maxCount limit applied to truncated results.",
+ "type": "number"
+}Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / properties / shownAdded value: +{
+ "description": "Number of stops returned when results were truncated.",
+ "type": "number"
+}Output schema / properties / truncatedAdded value: +{
+ "description": "True when matching stops exceeded maxCount.",
+ "type": "boolean"
+}Output schema / requiredRemoved value: -[
- "stops",
- "limitExceeded",
- "query",
- "count"
-]onebusaway_find_routes13 fields changedInput schema / properties / lat / descriptionPrevious value: -"Latitude of the search center."New value: +"Latitude of the search center, in [-90, 90]."Input schema / properties / lat / maximumAdded value: +90Input schema / properties / lat / minimumAdded value: +-90Input schema / properties / latSpanAdded value: +{
+ "description": "Optional bounding-box height in degrees, as an alternative to radius. Takes effect only when lonSpan is also set, in which case radius is ignored.",
+ "exclusiveMinimum": 0,
+ "type": "number"
+}Input schema / properties / lon / descriptionPrevious value: -"Longitude of the search center."New value: +"Longitude of the search center, in [-180, 180]."Input schema / properties / lon / maximumAdded value: +180Input schema / properties / lon / minimumAdded value: +-180Input schema / properties / lonSpanAdded value: +{
+ "description": "Optional bounding-box width in degrees, as an alternative to radius. Takes effect only when latSpan is also set, in which case radius is ignored.",
+ "exclusiveMinimum": 0,
+ "type": "number"
+}Input schema / properties / radius / descriptionPrevious value: -"Search radius in meters. Defaults to 500m."New value: +"Search radius in meters. Must be positive; capped at 1600m. Defaults to 500m. Ignored when latSpan and lonSpan are both set."Input schema / properties / radius / exclusiveMinimumAdded value: +0Input schema / properties / radius / maximumAdded value: +1600Output schema / properties / limitExceededAdded value: +{
+ "description": "True if more routes exist beyond the returned set; narrow the radius or set latSpan/lonSpan to see all.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "routes",
- "count"
-]New value: +[
+ "routes",
+ "limitExceeded",
+ "count"
+]onebusaway_find_stops9 fields changedInput schema / properties / lat / descriptionPrevious value: -"Latitude of the search center."New value: +"Latitude of the search center, in [-90, 90]."Input schema / properties / lat / maximumAdded value: +90Input schema / properties / lat / minimumAdded value: +-90Input schema / properties / lon / descriptionPrevious value: -"Longitude of the search center."New value: +"Longitude of the search center, in [-180, 180]."Input schema / properties / lon / maximumAdded value: +180Input schema / properties / lon / minimumAdded value: +-180Input schema / properties / radius / descriptionPrevious value: -"Search radius in meters. Defaults to 300m. Max ~1600m before results degrade."New value: +"Search radius in meters. Must be positive; capped at 1600m, beyond which results degrade. Defaults to 300m."Input schema / properties / radius / exclusiveMinimumAdded value: +0Input schema / properties / radius / maximumAdded value: +1600onebusaway_get_vehicles2 fields changedOutput schema / properties / limitExceededAdded value: +{
+ "description": "True if the upstream capped the vehicle list — some vehicles were omitted. This endpoint has no pagination to retrieve them.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "vehicles",
- "agencyId",
- "count"
-]New value: +[
+ "vehicles",
+ "limitExceeded",
+ "agencyId",
+ "count"
+]onebusaway_list_agencies2 fields changedOutput schema / properties / limitExceededAdded value: +{
+ "description": "True if the upstream capped the agency list — some agencies were omitted. This endpoint has no pagination to retrieve them.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "agencies",
- "count"
-]New value: +[
+ "agencies",
+ "limitExceeded",
+ "count"
+]onebusaway_list_routes_for_agency2 fields changedOutput schema / properties / limitExceededAdded value: +{
+ "description": "True if the upstream capped the route list — some routes were omitted. This endpoint has no pagination to retrieve them.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "routes",
- "agencyId",
- "count"
-]New value: +[
+ "routes",
+ "limitExceeded",
+ "agencyId",
+ "count"
+]onebusaway_search_routes6 fields changedInput schema / properties / maxCount / descriptionPrevious value: -"Maximum number of results to return. Defaults to 10."New value: +"Maximum number of results to return. A positive integer, at most 100. Defaults to 10."Input schema / properties / maxCount / exclusiveMinimumAdded value: +0Input schema / properties / maxCount / maximumAdded value: +100Input schema / properties / maxCount / typePrevious value: -"number"New value: +"integer"Output schema / properties / limitExceededAdded value: +{
+ "description": "True if more routes match than were returned; raise maxCount or refine the query to see all.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "routes",
- "query",
- "count"
-]New value: +[
+ "routes",
+ "limitExceeded",
+ "query",
+ "count"
+]onebusaway_search_stops6 fields changedInput schema / properties / maxCount / descriptionPrevious value: -"Maximum number of results to return. Defaults to 10."New value: +"Maximum number of results to return. A positive integer, at most 100. Defaults to 10."Input schema / properties / maxCount / exclusiveMinimumAdded value: +0Input schema / properties / maxCount / maximumAdded value: +100Input schema / properties / maxCount / typePrevious value: -"number"New value: +"integer"Output schema / properties / limitExceededAdded value: +{
+ "description": "True if more stops match than were returned; raise maxCount or refine the query to see all.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "stops",
- "query",
- "count"
-]New value: +[
+ "stops",
+ "limitExceeded",
+ "query",
+ "count"
+]onebusaway_get_trip2 fields changedOutput schema / properties / blockIdAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Block ID grouping this trip with the others the same vehicle runs back-to-back. Pass to onebusaway_get_block for the full block schedule. Null when the trip has no block."
+}Output schema / requiredPrevious value: -[
- "tripId",
- "routeShortName",
- "tripHeadsign",
- "status",
- "schedule",
- "situations"
-]New value: +[
+ "tripId",
+ "routeShortName",
+ "tripHeadsign",
+ "blockId",
+ "status",
+ "schedule",
+ "situations"
+]onebusaway_get_alertonebusaway_get_blockonebusaway_list_routes_for_agency1 field changedOutput schema / properties / noticeAdded value: +{
+ "description": "Guidance when no routes were found — verify the agency ID with onebusaway_list_agencies.",
+ "type": "string"
+}onebusaway_find_routes4 fields changedOutput schema / properties / countAdded value: +{
+ "description": "Number of routes returned.",
+ "type": "number"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Guidance when no routes matched — e.g. try a larger radius or different query.",
+ "type": "string"
+}Output schema / properties / queryAdded value: +{
+ "description": "Route name/number filter applied to the search, if any.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "routes"
-]New value: +[
+ "routes",
+ "count"
+]onebusaway_find_stops4 fields changedOutput schema / properties / countAdded value: +{
+ "description": "Number of stops returned.",
+ "type": "number"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Guidance when results are empty or truncated — e.g. how to narrow the radius or verify the stop code.",
+ "type": "string"
+}Output schema / properties / queryAdded value: +{
+ "description": "Stop code filter applied to the search, if any.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "stops",
- "limitExceeded"
-]New value: +[
+ "stops",
+ "limitExceeded",
+ "count"
+]onebusaway_get_arrivals5 fields changedOutput schema / properties / countAdded value: +{
+ "description": "Number of arrivals in the time window.",
+ "type": "number"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Guidance when no arrivals were found — e.g. try expanding the time window or check for service alerts.",
+ "type": "string"
+}Output schema / properties / queriedStopAdded value: +{
+ "description": "Stop ID queried.",
+ "type": "string"
+}Output schema / properties / windowMinutesAdded value: +{
+ "additionalProperties": false,
+ "description": "Time window used for the arrivals query.",
+ "properties": {
+ "after": {
+ "description": "Minutes after current time included.",
+ "type": "number"
+ },
+ "before": {
+ "description": "Minutes before current time included.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "before",
+ "after"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "stopId",
- "stopName",
- "currentTime",
- "arrivals",
- "situations"
-]New value: +[
+ "stopId",
+ "stopName",
+ "currentTime",
+ "arrivals",
+ "situations",
+ "queriedStop",
+ "count",
+ "windowMinutes"
+]onebusaway_get_schedule_for_route5 fields changedOutput schema / properties / dateAdded value: +{
+ "description": "Date parameter used for the schedule request, if specified.",
+ "type": "string"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Guidance when no trips were found — e.g. no service on weekends or holiday schedule in effect.",
+ "type": "string"
+}Output schema / properties / queriedRouteAdded value: +{
+ "description": "Route ID queried.",
+ "type": "string"
+}Output schema / properties / tripCountAdded value: +{
+ "description": "Number of trips for this route on this date.",
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "routeId",
- "routeShortName",
- "serviceDateMs",
- "trips"
-]New value: +[
+ "routeId",
+ "routeShortName",
+ "serviceDateMs",
+ "trips",
+ "queriedRoute",
+ "tripCount"
+]onebusaway_get_schedule_for_stop5 fields changedOutput schema / properties / dateAdded value: +{
+ "description": "Date parameter used for the schedule request, if specified.",
+ "type": "string"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Guidance when no routes were found — e.g. no service on weekends or holiday schedule in effect.",
+ "type": "string"
+}Output schema / properties / queriedStopAdded value: +{
+ "description": "Stop ID queried.",
+ "type": "string"
+}Output schema / properties / routeCountAdded value: +{
+ "description": "Number of routes with departures from this stop on this date.",
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "stopId",
- "stopName",
- "serviceDateMs",
- "routes"
-]New value: +[
+ "stopId",
+ "stopName",
+ "serviceDateMs",
+ "routes",
+ "queriedStop",
+ "routeCount"
+]onebusaway_get_vehicles5 fields changedOutput schema / properties / agencyIdAdded value: +{
+ "description": "Agency ID queried.",
+ "type": "string"
+}Output schema / properties / countAdded value: +{
+ "description": "Number of vehicles returned after any route filter.",
+ "type": "number"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Guidance when no vehicles were found — e.g. the route may not be currently active, or the agency may not have real-time data.",
+ "type": "string"
+}Output schema / properties / routeIdAdded value: +{
+ "description": "Route ID filter applied client-side, if any.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "vehicles"
-]New value: +[
+ "vehicles",
+ "agencyId",
+ "count"
+]onebusaway_list_agencies3 fields changedOutput schema / properties / countAdded value: +{
+ "description": "Number of transit agencies returned.",
+ "type": "number"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Guidance when no agencies were returned.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "agencies"
-]New value: +[
+ "agencies",
+ "count"
+]onebusaway_list_routes_for_agency3 fields changedOutput schema / properties / agencyIdAdded value: +{
+ "description": "Agency ID queried.",
+ "type": "string"
+}Output schema / properties / countAdded value: +{
+ "description": "Number of routes returned for this agency.",
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "routes"
-]New value: +[
+ "routes",
+ "agencyId",
+ "count"
+]onebusaway_search_routes4 fields changedOutput schema / properties / countAdded value: +{
+ "description": "Number of routes returned.",
+ "type": "number"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Guidance when no routes matched — e.g. try onebusaway_find_routes with coordinates, or onebusaway_list_routes_for_agency.",
+ "type": "string"
+}Output schema / properties / queryAdded value: +{
+ "description": "Route name/number query sent to the API.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "routes"
-]New value: +[
+ "routes",
+ "query",
+ "count"
+]onebusaway_search_stops4 fields changedOutput schema / properties / countAdded value: +{
+ "description": "Number of stops returned.",
+ "type": "number"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Guidance when no stops matched — e.g. try a different name fragment or use onebusaway_find_stops with coordinates.",
+ "type": "string"
+}Output schema / properties / queryAdded value: +{
+ "description": "Search query sent to the API.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "stops"
-]New value: +[
+ "stops",
+ "query",
+ "count"
+]onebusaway_find_routesonebusaway_find_stopsonebusaway_get_arrivalsonebusaway_get_routeonebusaway_get_schedule_for_routeonebusaway_get_schedule_for_stoponebusaway_get_stoponebusaway_get_triponebusaway_get_vehiclesonebusaway_list_agenciesonebusaway_list_routes_for_agencyonebusaway_search_routesonebusaway_search_stopsRead-only public transit departures, stop search, and city coverage for bus and train users.
Real-time SF Muni departures, routes, alerts, vehicle positions, and schedules.
Get real-time NYC bus arrivals, live vehicle locations, and service alerts. Plan trips between any…
Real-time BART departures, trip planning, fares, stations, and advisories.
Add one secure layer between your agents and this server.