onebusaway-mcp-server
Server Details
Real-time transit stops, routes, arrivals, vehicle positions, and schedules via OneBusAway APIs.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/onebusaway-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 13 of 13 tools scored.
Every tool has a clearly defined and distinct purpose: agencies, routes, stops, arrivals, schedules, trips, and vehicles. Descriptions explicitly mention when to use which tool and cross-reference others. There is no functional overlap.
All tools follow a uniform 'onebusaway_verb_noun' pattern with consistent verbs: list, get, find, search. The naming is predictable and maintains the same convention throughout the set.
13 tools cover the full scope of a transit data API: listing, fetching details, schedules, real-time arrivals, vehicle tracking, and searching. The count is well-proportioned for the domain without being overwhelming or insufficient.
The tool surface covers major transit workflows: discovery (list agencies/routes, find stops/routes), retrieval (get details, arrivals, schedules), and real-time tracking (vehicles, trips). No obvious gaps for a read-only transit information system.
Available Tools
13 toolsonebusaway_find_routesFind Routes Near LocationARead-onlyInspect
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. | |
| lon | Yes | Longitude of the search center. | |
| query | No | Filter by route name or number (e.g. "44" or "Link Light Rail"). | |
| radius | No | Search radius in meters. Defaults to 500m. |
Output Schema
| Name | Required | Description |
|---|---|---|
| routes | Yes | Routes found near the specified location. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that it returns routes with IDs, short names, and descriptions, confirming a read-only query. No contradictions, and no additional behavioral details are needed.
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 concise sentences: purpose+filter, output, next steps. No fluff, front-loaded with main action. Every sentence adds 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?
Given the output schema exists (mentioned implicitly) and annotations cover safety, the description explains output content and follow-up actions. It is complete for a straightforward search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for each parameter. The description adds no new semantic information about parameters beyond restating the optional filter. 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 explicitly states the tool's purpose: find transit routes near a location, with optional filtering. It distinguishes from siblings by specifying location-based search, which contrasts with onebusaway_search_routes (which likely lacks location context).
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 suggests using routeId values with other tools but does not explicitly contrast with siblings like onebusaway_get_route or onebusaway_find_stops. More direct guidance on when to use this tool versus alternatives would improve score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_find_stopsFind Stops Near LocationARead-onlyInspect
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. | |
| lon | Yes | Longitude of the search center. | |
| 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. Defaults to 300m. Max ~1600m before results degrade. |
Output Schema
| Name | Required | Description |
|---|---|---|
| stops | Yes | Stops within the search radius. |
| limitExceeded | Yes | True if more stops exist beyond the returned set; narrow the radius to see all. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with read operation. Description adds radius limits (max ~1600m before degradation) and what results include (wheelchair boarding status), going beyond 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?
Two clear, front-loaded sentences. First sentence covers purpose and returns. Second provides usage guidance and optional filter. No wasted 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?
Given 4 parameters, output schema existence, and sibling context, description fully covers what tool does, what it returns, and how to use results. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have descriptions in schema (100% coverage). Description supplements by clarifying radius default (300m), max limit, and that query filters by printed stop code. Adds meaning beyond 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?
Description clearly states this tool finds bus stops near a location and lists returned fields (ID, name, direction, routes, wheelchair boarding). It distinguishes from siblings by mentioning using stopId for arrivals via onebusaway_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?
Explicitly links to onebusaway_get_arrivals for real-time arrivals and explains optional stop code filter. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_get_arrivalsGet Real-Time ArrivalsARead-onlyInspect
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. Defaults to 35. | |
| minutesBefore | No | Include arrivals that departed up to this many minutes ago. Defaults to 5. |
Output Schema
| Name | Required | Description |
|---|---|---|
| stopId | Yes | The queried stop ID. |
| arrivals | Yes | Arrivals and departures at this stop within the requested time window. |
| stopName | Yes | Stop name. |
| situations | Yes | Active service alerts referenced by arrivals at this stop. |
| currentTime | Yes | Server time as Unix milliseconds, for computing countdown timers. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, which is consistent. The description adds valuable context: the meaning of the 'predicted' boolean, stop ID format, and that results include schedule deviation, vehicle positions, and alerts. This goes well beyond what annotations provide.
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 four sentences, each adding distinct value. It is front-loaded with the main purpose and efficiently communicates all essential details 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?
Given the tool's read-only nature, full parameter coverage, and presence of an output schema, the description is complete. It explains return data, usage hints, and typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds extra meaning: stopId format with example and how to discover IDs, minutesAfter and minutesBefore defaults. It enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns real-time arrivals and departures at a stop, listing specific data types (predicted times, schedule deviation, vehicle positions, alerts). It distinguishes from sibling tools like onebusaway_get_schedule_for_stop by emphasizing real-time vs. schedule.
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 explains the tool's purpose for real-time data and suggests using tripId for follow-up calls. It implicitly contrasts with schedule-based tools, but doesn't explicitly list when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_get_routeGet Route DetailsARead-onlyInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Agency-prefixed route ID. |
| url | Yes | Agency schedule page URL, or null. |
| type | Yes | GTFS route type: 0=tram, 1=subway, 2=rail, 3=bus, 4=ferry, 5=cable_car. |
| color | Yes | Route brand color hex (without #), or null. |
| agencyId | Yes | Agency ID that operates this route. |
| longName | Yes | Full route name. |
| shortName | Yes | The number or short name displayed on vehicles (e.g. "44"). |
| agencyName | Yes | Agency name that operates this route. |
| description | Yes | Route description. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds value by specifying return fields (short name, description, agency, route type, schedule URL) and ID format, enhancing behavioral understanding beyond 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 concise sentences: first states purpose and returns, second explains ID format. Front-loaded, no extraneous 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 simple single-ID fetch tool with output schema, the description covers purpose, parameter format, return fields, and discovery alternatives. Complete given low complexity and good annotations.
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% with description for routeId. The tool description adds the ID format and example, but the schema already includes similar info. Minimal additional meaning for the parameter beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch details for a specific route by ID' and lists return fields. The ID format ties to routes, distinguishing from sibling tools like get_stop or get_trip.
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 mentions using onebusaway_find_routes or onebusaway_search_routes for discovering IDs, implying when to use this tool. No explicit exclusions but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_get_schedule_for_routeGet Route ScheduleARead-onlyInspect
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 | ISO 8601 date (e.g. "2026-05-23"). Defaults to today. | |
| routeId | Yes | Agency-prefixed route ID (e.g. "1_100259"). Use onebusaway_find_routes or onebusaway_search_routes to discover IDs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| trips | Yes | All trips for this route on this date, with their stop sequences. |
| routeId | Yes | The queried route ID. |
| serviceDateMs | Yes | Service date as Unix milliseconds. |
| routeShortName | Yes | Route short name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds behavioral context: 'Returns up to all trips for the route', clarifying scope. 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?
Two sentences: first states core function, second provides alternative. No redundant words; 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?
Given output schema exists and descriptions for both parameters are in schema, the description fully covers purpose, usage, and behavioral context for a schedule tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage. Description adds value by noting date defaults to today and suggesting discovery of routeId via other tools, enhancing understanding beyond 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 uses specific verbs and resources: 'Full-day schedule for a route — all trips, stop sequences, and departure times', and distinguishes from siblings by directing to onebusaway_get_arrivals for live predictions.
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 states when not to use: 'For live predictions, use onebusaway_get_arrivals at specific stops instead.' Provides clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_get_schedule_for_stopGet Stop ScheduleARead-onlyInspect
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 | ISO 8601 date (e.g. "2026-05-23"). Defaults to 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| routes | Yes | All routes with departures from this stop on this date. |
| stopId | Yes | The queried stop ID. |
| stopName | Yes | Stop name. |
| serviceDateMs | Yes | Service date as Unix milliseconds (start of service day). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it returns a full-day schedule and defaults to today, which is helpful but not extensive. 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?
Three concise sentences: core purpose, detail, and usage guidance. No unnecessary words; every sentence adds 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?
Given the presence of output schema and clear annotations, the description adequately covers purpose, parameters, and usage context. Lacks mention of output format but schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds that date defaults to today and stopId can be discovered via other tools, marginally enhancing 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?
Description clearly states 'Full-day departure schedule for a stop' and specifies it lists departures by route and direction. It distinguishes from sibling tool onebusaway_get_arrivals by contrasting with real-time data.
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 says 'Useful for planning or when real-time data isn't needed' and 'For live predictions, use onebusaway_get_arrivals instead', providing clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_get_stopGet Stop DetailsARead-onlyInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Agency-prefixed stop ID. |
| lat | Yes | Latitude of the stop. |
| lon | Yes | Longitude of the stop. |
| code | Yes | The stop code printed on the sign. |
| name | Yes | Stop name. |
| routeIds | Yes | IDs of routes that serve this stop. Use with onebusaway_get_arrivals or onebusaway_get_schedule_for_stop. |
| direction | Yes | Compass direction of travel at this stop (e.g. "NW"). |
| wheelchairBoarding | Yes | Wheelchair boarding status. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description lists what data is returned (name, coordinates, etc.), adding helpful behavioral context beyond annotations. 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?
Two sentences with no redundant information. The main action and key details (what's returned, ID format) are front-loaded and efficiently communicated.
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 exists, the description adequately covers all needed context: purpose, input format, and output contents. No gaps for a straight-forward single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the stopId parameter with a description and example, and the description adds the format {agencyId}_{localId} and references discovery tools, enhancing understanding beyond the schema alone.
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 stop by ID, listing returned fields (name, coordinates, direction, routes, accessibility). This distinctive purpose is well-separated from sibling tools for finding stops, routes, or 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 the stop ID format and references using onebusaway_find_stops or onebusaway_search_stops to discover IDs, giving clear guidance on how to obtain required input. It lacks explicit when-not-to-use guidance, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_get_tripGet Trip StatusARead-onlyInspect
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). 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | Real-time status of the trip. |
| tripId | Yes | The queried trip ID. |
| schedule | Yes | Full stop sequence with times, or null if includeSchedule=false. |
| situations | Yes | Active situation IDs affecting this trip. |
| tripHeadsign | Yes | Destination sign text. |
| routeShortName | Yes | Route short name (e.g. "44"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral details: returns vehicle position, schedule deviation, current phase, and remaining stops. 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?
Two sentences with no waste. First sentence gives purpose and output, second provides usage guidance. Front-loaded and efficient.
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 exists and annotations are present, the description covers purpose, input suggestions, and return value summary. Complete for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minor context (e.g., 'Only needed for trips from a previous service day' for serviceDateMs) but does not significantly extend schema details.
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 'Real-time status and stop sequence for a trip,' specifying the verb (get) and resource (trip status). It distinguishes from sibling tools like onebusaway_get_arrivals by mentioning using tripId from that tool, clarifying scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to 'Use tripId from onebusaway_get_arrivals to look up a specific vehicle's progress,' providing clear context. It does not explicitly list when not to use it, but the guidance is sufficient for a narrow tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_get_vehiclesGet Real-Time Vehicle PositionsARead-onlyInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| vehicles | Yes | Active vehicles for the agency, optionally filtered by route. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that routeId filtering is client-side, meaning all vehicles are fetched first. This is a behavioral trait not covered by the readOnlyHint annotation. No contradiction exists between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a use case quote, no redundant words. It is front-loaded with the core purpose and efficiently conveys key 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?
Given the presence of an output schema (not shown), the description adequately covers purpose, parameters, and usage. It could mention rate limits or result limits, but for a read-only tool with clear schema, it is sufficiently 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?
Schema coverage is 100% and the description adds value: it provides example agencyId values ('1', '40') and clarifies that the routeId filter is client-side. This goes beyond the schema's own parameter descriptions.
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 returns real-time positions of all active vehicles for an agency, and optionally filters to a single route. It lists return fields (GPS, heading, deviation, trip) and provides an explicit use case, distinguishing it from sibling tools like get_arrivals or get_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 gives a concrete use case ('where are all the buses on route X?') and directs the user to get agencyId from onebusaway_list_agencies. It does not explicitly state when not to use it or compare to siblings, but the context is sufficient for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_list_agenciesList Transit AgenciesARead-onlyInspect
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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| agencies | Yes | All agencies served by this OneBusAway instance. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true. Description adds detail about return content (IDs, contact, etc.), consistent with read-only behavior. 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?
Two sentences: first states purpose, second adds value. No redundant 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 parameterless list tool, description fully covers purpose, return fields, and dependencies. Output schema exists, but description already sufficient.
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?
Input schema has 0 parameters, so no parameter description needed. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'list', resource 'transit agencies', and scope 'all agencies served by this OneBusAway instance'. It also lists return fields and links to dependent tools, clearly distinguishing from 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?
States tool returns agency IDs needed for other tools, implying usage before those tools. No explicit when-not or alternatives, but given no other listing tool, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_list_routes_for_agencyList Routes for AgencyARead-onlyInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| routes | Yes | All routes operated by this agency. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior. Description adds no extra behavioral traits, but given the annotation coverage, the transparency is sufficient.
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 concise sentences with no wasted words, front-loaded with the core purpose.
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?
Description provides enough for a list tool with output schema present. Could mention pagination or response format, but not essential given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter completely, but description adds meaningful context with example values (e.g., '1' for Metro Transit) and links to the ID discovery 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?
Description clearly states the tool lists all routes for an agency, specifies returned fields (IDs, names, descriptions), and distinguishes from siblings like onebusaway_find_routes by mentioning enumeration before searching.
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 when to use: to enumerate an agency's full service before searching for a specific route. Also explains how to obtain the required agencyId from another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_search_routesSearch Routes by Name or NumberARead-onlyInspect
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. Defaults to 10. |
Output Schema
| Name | Required | Description |
|---|---|---|
| routes | Yes | Routes matching the search query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only behavior is clear. The description adds that the tool returns IDs, which is helpful context. No contradictions, and behavioral traits beyond annotations are adequately disclosed given the tool's simplicity.
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 deliver the essential purpose and usage guidance. Efficiently structured with front-loaded action and result. Could be slightly more concise but no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but noted), the description adequately covers input, operation, and result. Missing details like case sensitivity or wildcards, but for a typical search tool this is sufficient.
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?
Input schema has 100% description coverage for both parameters (query and maxCount). The description adds context about the return value (IDs) but does not significantly enhance parameter understanding beyond what the schema provides. 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?
Description clearly states the tool searches for routes by name or number and returns matching routes with IDs. It uses specific verbs and resources, and distinguishes its purpose from sibling tools like onebusaway_get_route.
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 states the primary use case: resolving a route short name to a route ID for use with other tools (onebusaway_get_vehicles, onebusaway_get_schedule_for_route). Provides clear context, but does not explicitly exclude alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onebusaway_search_stopsSearch Stops by Name or CodeARead-onlyInspect
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. Defaults to 10. |
Output Schema
| Name | Required | Description |
|---|---|---|
| stops | Yes | Stops matching the search query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the behavioral detail that it returns matching stops with IDs and coordinates. There is no contradiction, and the description provides extra context beyond the annotation about what the output contains.
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, front-loads the action ('Search for stops by name or code'), and each sentence adds meaningful value. No redundant or extraneous 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?
Given that an output schema exists (not shown but indicated), the description need not detail return format. It mentions IDs and coordinates, covers the primary use case, and references a sibling tool. It could optionally mention pagination or the maxCount parameter, but given schema coverage, this is sufficient.
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% (both parameters have descriptions). The description adds no additional parameter-level details beyond what the schema already provides. Thus, it meets the baseline for high coverage but does not exceed it.
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 searches for stops by name or code, returns IDs and coordinates, and explicitly ties the output to feeding subsequent arrivals lookups. This distinguishes it from sibling tools like onebusaway_get_stop or onebusaway_find_stops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use to resolve a human-readable stop name or number to a stop ID for arrivals lookups with onebusaway_get_arrivals.' It clearly indicates when this tool is appropriate (before arrivals) but does not explicitly state alternative tools or when not to use it, though the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!