Lviv public transport MCP: stops, timetables, routes, and live vehicle positions. No API key.
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.
Average 4.6/5 across 7 of 7 tools scored.
Each tool targets a distinct resource (route, stop, vehicle, nearby) and mode (static vs. realtime), with clear cross-references that prevent overlap. The descriptions explicitly state when to prefer one tool over another, eliminating ambiguity.
All tool names follow a strict get_<resource>_<modifier> pattern (e.g., get_route_realtime, get_stop_geometry), making the API predictable. Verb and noun usage is uniform throughout the set.
Seven tools is a well-scoped size for a transit data server, covering static and realtime data for routes, stops, and vehicles. Each tool serves a necessary purpose with no redundancy.
Core workflows (discover stops by location, get route and stop data, track vehicles) are well covered. The only notable gap is lack of stop search by name; get_stops_around_location requires coordinates, so a stop name alone cannot resolve without external geocoding.
get_nearby_vehiclesGet Nearby VehiclesAReturns live positions for all transit vehicles within 1 km of given coordinates. Use when the user asks 'what transport is near me?' or wants a live map of all vehicles around a location without knowing the route. Prefer get_route_realtime when a specific route is already known. Requires decimal latitude and longitude (WGS84); use get_stops_around_location first if you only have a stop name.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Decimal latitude of the centre point, WGS84 (e.g. 49.842). | |
| longitude | Yes | Decimal longitude of the centre point, WGS84 (e.g. 24.031). |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds behavioral context: 'live positions', 'within 1 km', and 'all transit vehicles' indicating no filtering, plus the WGS84 coordinate requirement. This is more than the minimum needed given the annotations, though no rate limits or error behavior are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then usage guidance and coordinate requirement. Every sentence earns its place with no filler or 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?
With an output schema present, the description does not need to explain return values. It covers purpose, intended use cases, alternatives, and a prerequisite for stop-name-only queries. It fully equips an agent to decide when and how to invoke the 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 schema already documents latitude/longitude with WGS84, ranges, and examples. The description repeats the WGS84 requirement and adds the 1 km radius constant, but does not add meaningful parameter-specific semantics 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?
The description opens with a specific verb+resource+scope: 'Returns live positions for all transit vehicles within 1 km of given coordinates.' This clearly distinguishes it from siblings like get_route_realtime, which is route-specific, and get_stops_around_location, which focuses on 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?
Explicit when-to-use guidance: 'Use when the user asks "what transport is near me?" or wants a live map of all vehicles around a location without knowing the route.' It also names an alternative: 'Prefer get_route_realtime when a specific route is already known' and suggests get_stops_around_location if only a stop name is available. This covers when, when-not, and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_route_realtimeGet Route RealtimeAReturns 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds context about the output being 'live positions' and 'optimised for map rendering', which is useful beyond the annotations. It doesn't contradict annotations, and the lack of extra detail (e.g., pagination) is acceptable given the simple, read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with the primary purpose first, followed by targeted usage guidance and a parameter requirement. No redundant information; each 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?
Simple tool with one parameter, output schema present, and strong annotations. The description covers purpose, use cases, alternatives, and a parameter hint, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description of route_name including examples. The description restates the requirement but adds no new parameter semantics beyond the schema. Baseline 3 applies because the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live positions for all vehicles on a route, with a specific verb ('returns') and resource ('live positions'). It differentiates from siblings by mentioning 'optimised for map rendering' and explicitly contrasting with get_stop_realtime and get_route_static.
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 guidance with a concrete user query example ('where is my tram/bus right now?') and names alternative tools for different scenarios (get_stop_realtime, get_route_static). This is exemplary usage guidance.
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 StaticAReturns 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 (workday and weekend schedules are included in each stop's schedule field). 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read. The description adds useful context beyond annotations by detailing the contents (e.g., 'ordered stop lists', 'route polylines', 'workday and weekend schedules are included in each stop's schedule field'). While it doesn't mention error cases or network behavior, the static read-only nature is well disclosed and non-contradictory.
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 that flow logically: first states what is returned, then defines when to use, and finally states exclusions and prerequisites. Every sentence contributes value with no filler or redundancy. It is 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?
Given the output schema exists (covering return values), the description fully covers the tool's purpose, usage context, parameter meaning, and relationship to sibling tools. It addresses the main use cases and explicitly points to alternatives where relevant. The tool is simple (one parameter) and the description is complete for an AI agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description ('Route short name (e.g. "T30", "32A") or numeric external ID.'). The tool description repeats this and adds a discovery hint, but that hint is more of a usage guideline than new parameter semantics. Since the schema already covers the parameter completely, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: '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.' This precisely defines the tool's output and clearly distinguishes it from sibling tools like get_route_realtime, which is explicitly named as the alternative for live positions.
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 when-to-use guidance: '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.' It also gives a clear exclusion: 'Do NOT use this when live vehicle positions are needed — use get_route_realtime instead.' Additionally, it offers a discovery fallback: 'call get_stops_around_location first if you only know a location.' This is exemplary usage guidance.
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 GeometryAReturns 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and idempotent behavior. The description adds meaningful context by specifying 'static map context' and 'No live data is fetched', which is beyond the annotation hints. It does not contradict annotations, but could have added more about error conditions or response structure; however, the output schema covers the latter.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by usage guidance, exclusions, and prerequisites. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple signature (one param, high schema coverage, and presence of an output schema), the description fully covers purpose, usage, exclusions, and prerequisites. It needs no further elaboration on return values because the output schema supplies that.
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% for the single parameter, and the schema already describes `stop_id` in detail. The description adds value by stating 'Requires a numeric stop ID' and providing a fallback instruction when only coordinates are available, which helps disambiguate how to obtain the required value.
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's action: 'Returns static map context for a stop: its marker and polylines for every route that serves it.' It also explicitly distinguishes itself from sibling `get_stop_realtime` by emphasizing 'No live data is fetched.'
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 when-to-use and when-not-to-use guidance: 'Use this when you need to enrich an existing map with route shapes...' and 'Do NOT use this when live arrival times or vehicle positions are needed — use `get_stop_realtime` instead.' It also names a prerequisite for coordinate-based queries: 'call `get_stops_around_location` first if you only have coordinates.'
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 RealtimeAReturns 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful context by stating it produces a map UI block and a structured list, and emphasizes 'live' data—details not available from 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?
Three sentences, each earning its place: purpose, usage guidance, and parameter requirement. Front-loaded with the core action, no fluff.
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 one-parameter tool with an output schema and strong annotations, the description fully covers purpose, alternatives, prerequisites, and output nature. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with stop_id thoroughly described (municipal code, example 707, digit-only string accepted). The description merely repeats 'numeric stop ID (shown on stop signage)' adding no new information beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live arrivals and vehicle positions for a stop, and specifies the two output forms (map UI block and structured arrival list). It also distinguishes itself from sibling tools by explicitly naming get_stop_geometry as the static alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names this as the default tool for arrival/departure/vehicle queries at a specific stop, provides an alternative (get_stop_geometry) for static data, and instructs using get_stops_around_location when only an address or coordinates are available. This is strong when/when-not guidance.
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 LocationADiscovers 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. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint, but the description goes further by disclosing the map UI side effect for map-capable clients, the metadata-only nature of the response, and the default radius behavior. These are meaningful behavioral insights beyond the structured 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 efficiently front-loaded with the core purpose, followed by the map UI detail, usage guidance, exclusions, and radius advice. Five sentences, each with a distinct purpose, no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and an output schema, the description fully covers the tool's purpose, return value characteristics, side effects, usage context, and parameter adjustment tips. It is sufficiently complete to guide an agent without needing additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the radius guidance already present in the schema (default 1,000 m, narrowing/widening) but doesn't add substantially new parameter-level meaning. It mentions output fields, but not param syntax beyond what schema covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Discovers') and clearly defines the resource ('transit stops near a geographic point') and the output (numeric code, name, coordinates, walking distance). It explicitly distinguishes the tool from siblings by adding 'Do NOT use this to fetch arrivals or live vehicle data — it returns stop metadata only.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: '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.' It also clearly states what not to use it for, making the when/when-not boundaries unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vehicle_infoGet Vehicle InfoAReturns full details for a specific transit vehicle by its ID: current position, bearing, route, license plate, direction, and upcoming stop arrivals. Use when the user wants to track a particular vehicle (e.g. after seeing it on a get_route_realtime map). Vehicle IDs come from get_route_realtime, get_nearby_vehicles, or get_stop_realtime results. Do NOT use this to get all vehicles on a route — use get_route_realtime instead.
| Name | Required | Description | Default |
|---|---|---|---|
| vehicle_id | Yes | Vehicle ID as returned by get_route_realtime, get_nearby_vehicles, or get_stop_realtime. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| view | Yes | |
| ui_blocks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds valuable context by listing the returned data fields and the source of valid vehicle IDs, which helps the agent understand the tool's scope and data provenance. It does not contradict annotations and provides reasonable behavioral detail beyond the structured fields.
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: purpose, usage context, and explicit exclusion. Every sentence earns its place, and the most critical information (what it returns and when to use) is front-loaded. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with full schema coverage, explicit output schema, and strong annotations, the description covers purpose, usage, data source, and alternatives. It is fully complete for an agent to select and invoke the tool correctly without needing additional context.
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 for the single parameter is 100%, with the schema already explaining vehicle_id as 'Vehicle ID as returned by get_route_realtime, get_nearby_vehicles, or get_stop_realtime.' The description repeats this source information rather than adding new meaning, so it earns the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Returns full details') and resource ('specific transit vehicle by its ID'), enumerating the exact data fields (position, bearing, route, license plate, direction, upcoming stop arrivals). It clearly distinguishes this tool from siblings like get_route_realtime by emphasizing 'specific vehicle' and explicitly naming the alternative for route-wide queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case ('when the user wants to track a particular vehicle'), a concrete example (after seeing it on a get_route_realtime map), source tools for vehicle IDs, and a direct exclusion with the correct alternative tool ('Do NOT use this to get all vehicles on a route — use get_route_realtime instead'). This is model-level usage guidance.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.