openbusdata

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation3/5
Several tools have overlapping scopes, like multiple dataset listing tools (Data_set_api_v1_fares_dataset and timetables_api_v1_dataset) and real-time feed tools (get_live_buses_on_route and SIRI_VM_Data_feed_api_v1_datafeed). While they target different data types (fares vs timetables, route-level vs feed-level), the names are similar and could confuse an agent.
Naming Consistency2/5
Naming is highly inconsistent: some tools use snake_case (find_buses_by_arrival_time), some use camelCase (Data_set_api_v1_fares_dataset), and others use a mix (GTFS_RT_Data_feed_api_v1_gtfsrtdatafeed). There is no consistent pattern, making it hard to predict tool names.
Tool Count4/5
16 tools is reasonable for a comprehensive bus data API covering fares, timetables, real-time, disruptions, and planning. It is slightly on the high side but still well-scoped for the domain.
Completeness4/5
The tool set covers core bus data operations: dataset discovery, stop search, route lookup, timetables, real-time positions, cancellations, disruptions, and journey planning. Minor gaps exist (e.g., no fare calculation), but the overall coverage is good.
Average 3.1/5 across 16 of 16 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on June 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies filtering capabilities but schema only accepts a single 'kwargs' string, creating a behavioral inconsistency. No mention of side effects, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose with parameter details that contradict the schema. The structure is unclear and wastes space on parameters that may not exist.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mismatch between description and schema, and lack of annotations, the description is incomplete. It does not explain the actual behavior or how the 'kwargs' parameter should be formatted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema lists only 'kwargs' as a required string, while description describes four separate parameters (boundingBox, routeId, etc.) not present in the schema. This contradiction misleads the user about how to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Returns all published datafeeds' but then focuses on filtering bus location data, which is contradictory. It does not clearly distinguish from sibling tools like SIRI_VM_Data_feed_api_v1_datafeed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Missing context about prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only repeats the tool name. It omits behavioral traits like side effects, authentication needs, or data scope beyond 'all cancellations'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but incomplete; it says 'Parameters:' with nothing following. This is under-specification, not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single opaque parameter and no output schema description, the description fails to provide enough context for correct invocation. It is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'kwargs' has no description in the schema (0% coverage) and the tool description adds no meaning. The agent has no clue what to pass as kwargs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns all cancellations, which is a clear verb+resource. However, it lacks specificity about scope (e.g., time range, system range) and only barely distinguishes from sibling tools like SIRI_SX_Disruptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context about prerequisites, filtering, or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It implies a read operation ('Returns') but fails to disclose any behavioral traits like idempotency, auth requirements, or rate limits, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short with one sentence and an empty 'Parameters:' section. It is under-specified, lacking any structure like bullet points or examples that would help the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter and the presence of an output schema, the description is incomplete. It does not differentiate from siblings, explain the 'kwargs' parameter, or describe the context of disruptions (e.g., transport mode, region).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'kwargs' is a string, but the description does not explain its purpose or expected value. With 0% schema description coverage, the agent has no guidance on how to populate this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns all disruptions', which provides a verb and resource but is vague. It does not differentiate from sibling tool SIRI_SX_Cancellations_siri_sx_cancellations, leaving the agent uncertain about the scope or type of disruptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as SIRI_SX_Cancellations. The description lacks any context about prerequisites, filtering, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'Returns a single datafeed' without disclosing read-only nature, error handling, authentication, or rate limits. Minimal transparency for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with a header and parameter explanation. It is concise but the parameter section is misplaced and inaccurate. No extraneous content, but structure could be improved by aligning with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex tool name and sibling context, the description lacks completeness. It does not distinguish from similar tools (list vs. single), does not address error conditions, and the parameter mismatch leaves gaps. An output schema exists but is not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'datafeedID' as a required parameter, but the input schema only has 'kwargs' with no description. This mismatch misleads the agent about how to invoke the tool. Schema coverage is 0%, and the description fails to accurately map to the actual parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns a single datafeed', which is a clear verb+resource. However, the parameter naming mismatch (datafeedID vs kwargs) undermines clarity. The sibling tool SIRI_VM_Data_feed_api_v1_datafeed likely lists all, so specifying 'single' helps, but the discrepancy reduces score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs. alternatives like the list datafeed tool. Does not mention that it requires a specific datafeedID or that it's for retrieving a single item by ID. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. While it implies a read operation, it does not explicitly state that it is read-only, safe, or idempotent. It also omits details like rate limits, authentication needs, pagination behavior, or response format beyond the output schema existence. The description is insufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with a clear one-line purpose followed by parameter descriptions. However, the parameter section is somewhat lengthy and contains formatting issues (e.g., line breaks). The overall structure is acceptable but not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (five described parameters but only one in schema) and the presence of an output schema, the description should explain the purpose of each parameter and how they are used together. It fails to address the schema mismatch, lacks pagination or result limit behavior, and does not cover edge cases or default values beyond the defaults mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only a single 'kwargs' string parameter, but the description lists five distinct parameters (noc, status, boundingBox, limit, offset). This mismatch is misleading and contradicts the schema. The description does not clarify how the parameters map to the actual API, leading to confusion and poor guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns all fares datasets' which is a specific verb and resource, clearly indicating the tool lists all fares datasets. It implicitly distinguishes from sibling 'Data_set_api_v1_fares_dataset_by_datasetID' which presumably returns one dataset. However, it does not explicitly state the distinction, so a perfect 5 is not warranted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter details but gives no guidance on when to use this tool versus alternatives (e.g., when to use the dataset-by-ID sibling). It does not mention when-not to use or prerequisites. Usage context is only implied by the parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits such as idempotency, authentication, or rate limits. The burden falls entirely on the description, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with one sentence and a parameter list. It is concise but lacks structure and clarity due to the discrepancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, return value explanation is not needed. However, the description fails to explain how the parameter (datasetID) relates to the actual schema (kwargs), leaving critical context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It describes a 'datasetID' parameter, but the actual schema contains 'kwargs' instead, leading to a mismatch. This confuses rather than clarifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns a single dataset' clearly indicates the verb and resource, and the name distinguishes it from the sibling 'timetables_api_v1_dataset' which likely returns all datasets. However, confusion arises from the parameter mismatch with the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'timetables_api_v1_dataset'. The description lacks context for selecting the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It does not mention that the operation is read-only, any authentication needs, rate limits, or whether the result is paginated. The presence of 'limit' and 'offset' hints at pagination but is not explicitly stated. Side effects and error behavior are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-line purpose, then lists parameters in a readable format. It could be more concise by grouping related parameters or removing redundancy. The structure is functional but not optimized for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention what the tool returns (e.g., list of timetable dataset objects). It lacks details on how to use 'kwargs' correctly, pagination behavior, error handling, or prerequisites. For a tool with a complex single-parameter input, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter 'kwargs' with 0% coverage, but the description lists many parameters (adminArea, noc, etc.) with brief explanations. This adds meaning but is misleading because it does not explain how these parameters relate to the single 'kwargs' string—whether they should be concatenated, passed as JSON, etc. The gap between schema and description creates confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Returns all timetables', which clearly states the action and resource. It then lists numerous filter parameters, making it obvious what the tool does. However, it does not differentiate from the sibling tool 'timetables_api_v1_dataset_by_datasetID', so some ambiguity remains about when to use this vs that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like 'Data_set_api_v1_fares_dataset' or 'timetables_api_v1_dataset_by_datasetID'. The parameter list implies usage for listing filtered datasets, but no when-to-use or when-not-to-use advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only says 'Returns a single dataset' without disclosing whether it's read-only, auth requirements, side effects, or response format. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines plus parameter docs), but the parameter section improves structure. Could be more concise by integrating the parameter info into the return statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema (not shown), the description lacks information about required authorization, the format of the dataset ID, the exact nature of the dataset, and why 'kwargs' appears in the schema. The mismatch between description and schema undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents a 'datasetID' parameter and marks it required, adding meaning beyond the schema which only has an undocumented 'kwargs' property. This compensates for the schema's low coverage (0%) by clarifying the intended input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns a single dataset', which is clear about the action and resource. The tool name includes 'by_datasetID' distinguishing it from sibling 'Data_set_api_v1_fares_dataset' (likely returns multiple datasets). However, 'dataset' remains somewhat vague without domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'Data_set_api_v1_fares_dataset' (for multiple datasets). No prerequisites or context for appropriate usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Get real-time bus locations' without mentioning rate limits, data freshness, access requirements, or the read-only nature. The description fails to add meaningful behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a clear first sentence followed by two parameter explanations. No unnecessary words or repetition. It is front-loaded with the purpose and then lists parameters efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and an output schema, so the description covers the basics. However, it could be more complete by mentioning that results are real-time (so may change rapidly) or what the output contains (e.g., bus IDs, locations). The sibling tools suggest more specialized queries, but the description does not help the agent decide when this is the best tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds value by explaining operator_ref as 'Operator NOC code' with examples (ARBB, SCCM, CBBH) and line_ref as 'Route number' with examples (12, MK1, 100). This provides clarity that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves real-time bus locations for a specific operator and route. The verb 'Get' and resource 'real-time bus locations' are specific, and it distinguishes from siblings like 'find_buses_by_arrival_time' or 'plan_journey' by focusing on live data by operator and route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to use 'find_buses_by_arrival_time' or 'plan_journey'. There is no mention of context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states 'returns' but doesn't disclose potential side effects, rate limits, pagination, or max result limits. Only implies read-only behavior through 'Returns'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with the main purpose front-loaded. Parameter explanations are dense but necessary. Minor redundancy in repeating 'Limit results to bus location data' for each parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, return format details are not required. However, the description lacks context on result structure (e.g., is it a list?), and doesn't explain the scope beyond 'bus location data' in parameters. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only a generic 'kwargs' string with no description. The description compensates fully by detailing each possible filter parameter (boundingBox, operatorRef, etc.), providing essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns all published datafeeds' with specific verb and resource. It distinguishes from the sibling 'by_datafeedID' tool by indicating it returns all datafeeds without a specific ID filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like the per-ID version or GTFS_RT feed. The parameter descriptions imply filtering but no when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that the tool returns a 'full ordered list of stops', but does not mention it is read-only, whether it requires authentication, data freshness, or any side effects. The behavioral disclosure is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence for the main purpose followed by a bullet list of parameters. It is front-loaded with the core function and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description does not need to detail return values. It covers the main input parameters and the output concept ('full ordered list'). However, it does not address edge cases like missing routes or invalid operator names, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the parameter descriptions add vital meaning. The description explains that 'operator' supports exact or partial match, 'route' is a number/identifier, and 'direction' accepts specific values ('inbound', 'outbound') or null for all. This exceeds the schema's basic type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full ordered list of stops for a specific bus route'. It distinguishes itself from sibling tools like 'find_buses_by_arrival_time' and 'get_live_buses_on_route' by focusing on stops along a route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get stops for a route) but provides no explicit guidance on when not to use it or alternatives. It mentions optional direction filtering but no context about when to prefer this over other similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that it finds scheduled (not live) buses and specifies time format. However, it does not describe behavior on errors, missing stops, or invalid input. It adds some value but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence stating purpose followed by a clear bullet list of parameters. It is front-loaded and every sentence adds value. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, no need to explain return values. The description covers all parameters and notes that it finds scheduled (not live) buses. It does not mention prerequisites or error handling, but for a simple query tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It does so effectively: stop_a is 'Boarding stop (NaPTAN code or name)', stop_b is 'Alighting stop', arrive_by is 'Target arrival time (HH:MM, 24h format)', and day is optional with specific day abbreviations. This significantly clarifies parameter meaning beyond the schema's minimal titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find scheduled buses that board at stop_a and arrive at stop_b by the given time.' This uses a specific verb ('find'), a defined resource ('scheduled buses'), and specific constraints (boarding and alighting stops, arrival time). It distinguishes from siblings like 'find_routes_between_stops' and 'get_live_buses_on_route'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters and implies usage for scheduled bus lookup, but it does not explicitly state when to use this tool versus alternatives. It mentions a default for 'day' but lacks guidance on exclusions or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It adds behavioral context: stops can be specified by NaPTAN code or name substring. It does not detail error handling or return format, but for a query tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: one sentence for purpose followed by a clear parameter list. No unnecessary words, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 required parameters, no annotations, and an output schema exists, the description is largely complete. It covers purpose and parameter semantics. Minor lack of info on output or error handling, but not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful parameter descriptions: 'Stop A' and 'Stop B' with format details (NaPTAN code or name substring). This compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find all bus routes that serve BOTH of the given stops.' The verb 'find' and resource 'bus routes' are specific, and the condition 'BOTH' distinguishes it from sibling tools like find_buses_by_arrival_time or get_route_stops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (when needing routes serving both stops). However, it does not explicitly mention when not to use it or suggest alternatives like plan_journey or get_route_stops.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the action (download and index) and the cache behavior via force_refresh. However, it does not disclose potential side effects like network usage, duration, or whether it clears existing data. Minimal but acceptable for a simple initialization tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences for purpose/usage and one line per parameter. No wasted words, front-loaded with the main action. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no nested objects), the description covers the core purpose, usage context, and parameter semantics. It could mention potential time cost or that it prepares data for other tools, but the existing context (output schema exists) reduces the need for return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. For the only parameter 'force_refresh', it explains exactly what true/false does ('re-download all data instead of using cache'), adding essential meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool downloads and indexes all accessible timetable datasets, with a specific verb and resource. It distinguishes itself from siblings by being a preparatory step, and the instruction 'Call this first if stop/route search tools return no results' further clarifies its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('if stop/route search tools return no results') and implies it as a prerequisite. However, it does not explicitly state when not to use or mention alternatives, but the guidance is clear enough for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must provide transparency. It explains basic behavior (plans journey with changes) but does not disclose what happens if no journey found, or if multiple options exist. Output schema exists but not detailed in description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose, then a clear parameter list. No redundancy, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: purpose, parameters, constraints. Lacks details on error handling or output format, but output schema exists. Adequate for a tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description provides full parameter explanations, including formats (HH:MM), possible values (day filter), and defaults. Adds significant value beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (plan), resource (journey), and scope (from stop_a to stop_b with arrival time). Distinguishes from sibling tools like find_routes_between_stops which lists routes, or find_buses_by_arrival_time which finds buses, not plans a journey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for journey planning with arrival time constraint. Supports direct routes and single changes, but doesn't explicitly say when not to use or provide alternatives. However, it's clear enough for an agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states that the tool searches across all loaded timetable data and performs a case-insensitive substring match, which is relevant. However, it does not disclose whether the operation is read-only, any rate limits, or authentication requirements. For a simple search, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences that cover purpose, scope, return, and parameter meaning. Every sentence contributes value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (as indicated by context signals), the description does not need to detail return values. It fully covers the tool's functionality and parameter semantics, making it complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a 'query' parameter with no description, so the description compensates by explaining it is a case-insensitive substring search against stop names. This adds crucial semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'search', the resource 'bus stops', and the scope 'across all loaded timetable data'. It also mentions the return of NaPTAN codes, distinguishing it from sibling tools like 'get_route_stops' or 'find_buses_by_arrival_time'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool's function (searching bus stops by name) and returns matching stops. While it does not explicitly state when not to use it or mention alternative tools, the sibling list provides context, and the description is sufficient for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openbusdata-mcp MCP server](https://glama.ai/mcp/servers/AndrewAubury/openbusdata-mcp/badges/card.svg)](https://glama.ai/mcp/servers/AndrewAubury/openbusdata-mcp)

Score Badge

Copy to your README.md:

[![openbusdata-mcp MCP server](https://glama.ai/mcp/servers/AndrewAubury/openbusdata-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AndrewAubury/openbusdata-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AndrewAubury/openbusdata-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server