Lviv Public Transport
Server Details
Lviv public transport MCP: stops, timetables, routes, and live vehicle positions. No API key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- vbhjckfd/timetable-api-node
- GitHub Stars
- 2
- Server Listing
- mcp-lad-lviv-ua
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.2/5 across 5 of 5 tools scored.
Each tool targets a distinct entity and data mode (route vs stop, realtime vs static), with explicit cross-references in descriptions that tell the agent which tool to prefer or avoid, eliminating ambiguity.
All tool names follow the consistent pattern `get_<entity>_<descriptor>` (e.g., get_route_realtime, get_stop_geometry), using snake_case and clear, predictable vocabulary throughout.
With 5 tools covering core transit operations (stop discovery, stop/route static info, stop/route live data), the scope is well-focused and avoids bloat or inadequacy.
The tools cover the main use cases for transit information, but a tool to list or search routes by name or number is missing, which could be needed when the user doesn't know the exact route short name.
Available Tools
5 toolsget_route_realtimeGet Route RealtimeARead-onlyIdempotentInspect
Returns live positions for all vehicles currently running on a route, optimised for map rendering. Use when the user asks "where is my tram/bus right now?" or wants to see all active vehicles on a specific route on a map. Prefer get_stop_realtime when the user is at a stop and wants to know arrival times rather than vehicle positions. Prefer get_route_static when only the route shape or stop list is needed without live data. Requires a route short name (e.g. "T30", "32A") or numeric external ID.
| Name | Required | Description | Default |
|---|---|---|---|
| route_name | Yes | Route short name (e.g. "T30", "32A") or numeric external ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds context about the output (live positions for map rendering). No contradictions. Adequate additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then usage guidelines. Every sentence is informative with no 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 no output schema, the description still gives a clear picture of what the tool returns (live positions for map rendering) and when to use it. Combined with clear annotations, it is complete for the tool's complexity.
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 provides examples of valid route names ('T30', '32A') and clarifies the parameter is a short name or numeric ID, adding value 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?
Description clearly states the tool returns live positions for vehicles on a route, optimized for map rendering. It distinguishes itself from siblings by specifying alternatives for different user needs.
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 when to use (user asks 'where is my tram/bus?') and when not to use, with clear references to sibling tools get_stop_realtime and get_route_static.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_route_staticGet Route StaticARead-onlyIdempotentInspect
Returns static route metadata: short and long name, vehicle type, brand colour, ordered stop lists for both directions, and route polylines (shapes) for map rendering. Use when the user asks which stops a route serves, what a route looks like on a map, or what the scheduled departure times are. Do NOT use this when live vehicle positions are needed — use get_route_realtime instead. Requires a route short name (e.g. "T30", "32A") or numeric external ID; call get_stops_around_location first if you only know a location and need to discover which routes serve it.
| Name | Required | Description | Default |
|---|---|---|---|
| route_name | Yes | Route short name (e.g. "T30", "32A") or numeric external ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true; description adds that it returns static metadata, reinforcing safety. Does not mention rate limits or side effects, but 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?
Concise multi-sentence structure: first sentence states output, then usage guidance, then caveat and prerequisite. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-param tool with no output schema, the description is largely sufficient. It explains what the tool returns and when to use it. Lacks specifics on return format (e.g., whether coordinates are lat/lng) but that does not hinder selection.
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?
Description adds examples ("T30", "32A") and explains how to obtain the route_name via get_stops_around_location, going beyond the schema description which only states the type and format.
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 it returns static route metadata and lists specific data elements (short/long name, vehicle type, stop lists, polylines). Explicitly distinguishes from sibling tool get_route_realtime by contrasting static vs. live 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?
Provides explicit when-to-use scenarios (route stops, map, schedule) and when-not-to (live positions) with sibling tool reference. Also gives prerequisite for obtaining route_name and suggests get_stops_around_location if only location is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stop_geometryGet Stop GeometryARead-onlyIdempotentInspect
Returns static map context for a stop: its marker and polylines for every route that serves it. No live data is fetched. Use this when you need to enrich an existing map with route shapes (e.g. overlay polylines alongside a get_stop_realtime map block) or when the user asks to visualise which routes pass a stop without needing live arrivals. Do NOT use this when live arrival times or vehicle positions are needed — use get_stop_realtime instead. Requires a numeric stop ID; call get_stops_around_location first if you only have coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| stop_id | Yes | Municipal stop code shown on stop signage (e.g. 707). Accepts a positive integer or an equivalent digit-only string. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds 'static map geometry' and mentions 'linked routes', providing 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?
Single sentence, front-loaded with verb and object. No unnecessary words. Concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple parameter and annotations, the description sufficiently covers purpose. Could mention return format but not necessary for this simple query tool. No output schema, but for a static geometry fetch, the description is adequate.
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?
Tool description does not mention the parameter. However, the input schema already provides descriptions for stop_id (integral or string with examples). Since schema coverage is effectively high due to schema descriptions, baseline of 3 is appropriate; no additional value from tool description.
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 'Returns static map geometry for a stop and linked routes.' Verb 'returns' and resource 'static map geometry' are specific. Distinguishes from siblings: get_stop_realtime (realtime), get_stops_around_location (location-based), get_vehicles_by_stop (vehicles).
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?
Description implies usage for static geometry but does not explicitly state when to use vs alternatives. No mention of when not to use or which sibling to choose. Context from sibling names helps but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stop_realtimeGet Stop RealtimeARead-onlyIdempotentInspect
Returns live arrivals and vehicle positions for a stop, producing both a map UI block and a structured arrival list. Use this as the default tool when the user asks about arrivals, departures, or vehicles at a specific stop. Prefer get_stop_geometry when only static route polylines are needed and live data is irrelevant. Requires a numeric stop ID (shown on stop signage); use get_stops_around_location first if you only have an address or coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| stop_id | Yes | Municipal stop code shown on stop signage (e.g. 707). Accepts a positive integer or an equivalent digit-only string. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent behavior. Description adds 'live arrivals' but doesn't disclose data freshness, rate limits, or behavior for missing data. Adequate but not enhanced.
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?
Single sentence, front-loaded with main action and resource. No 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?
With no output schema, description could explain return format more. Current description is minimal but sufficient for a simple real-time data tool with 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?
Only one parameter (stop_id) with detailed schema descriptions. Tool description adds no extra meaning, but schema covers both numeric and string formats sufficiently.
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 that the tool returns live arrivals and vehicle positions for a stop. This verb+resource+scope is distinct from siblings like get_stop_geometry and get_stops_around_location.
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?
No guidance on when to use this tool versus alternatives such as get_stop_geometry or get_vehicles_by_stop. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stops_around_locationGet Stops Around LocationARead-onlyIdempotentInspect
Discovers transit stops near a geographic point, returning each stop's numeric code, name, coordinates, and walking distance. Also emits a map UI block with multiple markers for map-capable clients (e.g. ChatGPT). Use this as the first step whenever the user provides an address, place name, or coordinates and you need stop IDs before calling get_stop_realtime or get_stop_geometry. Do NOT use this to fetch arrivals or live vehicle data — it returns stop metadata only. Default radius is 1 000 m; narrow it (e.g. 300 m) for dense urban areas or widen it (up to 3 000 m) for rural locations.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Decimal latitude of the search centre, WGS84 (e.g. 49.842 for central Lviv). | |
| longitude | Yes | Decimal longitude of the search centre, WGS84 (e.g. 24.031 for central Lviv). | |
| radius_meters | No | Search radius in metres (50–3000, default 1000). Use ~300 for dense urban intersections, up to 3000 for suburban or rural areas. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent; description adds valuable context about returning a map UI block for capable clients, which is 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 concise sentences that front-load the main action and output format; 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?
Covers purpose, key returned fields, and special output (map UI); lacks details on pagination or empty results, but acceptable for a simple read 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 with clear parameter descriptions; description does not add new meaning to parameters, only mentions returned fields.
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 it lists transit stops with key fields (code, name, coordinates, distance) and distinguishes from sibling tools like get_stop_geometry or get_stop_realtime.
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?
Implicitly suggests use when stops near a point are needed, but no explicit when-to-use or when-not-to-use guidance nor mention of alternatives.
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!
Your Connectors
Sign in to create a connector for this server.