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.7/5 across 8 of 8 tools scored.
Each tool targets a distinct operation (stop discovery, static route data, realtime arrivals, vehicle tracking, trip planning) with clear 'do not use' guidance in descriptions. No overlapping purposes.
All tools follow a consistent verb_noun pattern using snake_case (e.g., get_stops_around_location, get_route_realtime). plan_trip is the only deviation but still readable and fits the pattern.
8 tools is well-scoped for a public transport server, covering discovery, static metadata, realtime data, and trip planning without redundancy.
The tool surface covers the full lifecycle: stop discovery, route/stop static data, realtime vehicle positions and arrivals, specific vehicle tracking, and trip planning. No obvious gaps for a transit information server.
Available Tools
8 toolsget_nearby_vehiclesGet Nearby VehiclesARead-onlyIdempotentInspect
Returns 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). |
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 behavior. The description adds context about the 1 km radius constraint and requirement for decimal latitude/longitude in WGS84 format, which is not covered by 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, all essential. First states core function, second gives usage context, third adds precision and fallback. 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?
Given the output schema exists (not shown), the description covers purpose, when to use, prerequisites, and coordinate format. For a real-time geospatial tool with many siblings, it is complete enough for correct selection and invocation.
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 clear type, range, and examples. The description adds the requirement for decimal coordinates and WGS84, which provides additional clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it returns live positions for all transit vehicles within 1 km of given coordinates. It uses a specific verb and resource, and distinguishes from the sibling tool get_route_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?
Explicitly says when to use (user asks 'what transport is near me?' or wants live map without knowing route) and when to use an alternative (get_route_realtime for specific routes). Also provides prerequisite: use get_stops_around_location if only have a stop name.
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 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 indicate read-only and idempotent. Description adds context about being 'optimised for map rendering' and 'live positions', which is helpful but not required 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?
Three sentences, front-loaded with purpose, no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, annotations, and output schema existence, the description fully explains the tool's purpose, usage, and output nature without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the single parameter with 100% coverage. The description adds examples and context (e.g., 'Route short name... or numeric external ID'), slightly enhancing clarity.
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 vehicles on a route, optimized for map rendering, and distinguishes it from siblings like 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?
Explicitly provides when to use (e.g., 'where is my tram/bus right now?') and when not to (prefer alternatives for arrivals or static data), with example inputs.
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 (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. |
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 context that schedules are included in each stop's schedule field, but no additional behavioral traits beyond what annotations imply. Without contradiction.
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, front-loaded with purpose and output components, then usage guidelines, then parameter hint. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a static read-only tool: single parameter documented, output schema exists (assumed from context), usage boundaries and prerequisites clear.
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 only reiterates the schema description ('Route short name or numeric external ID'). No added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns static route metadata including names, vehicle type, color, stop lists, and polylines. It distinguishes itself from sibling tool get_route_realtime 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?
Explicitly states when to use (route info on map or scheduled times) and when not to (live positions, directing to get_route_realtime). Also provides prerequisite to call get_stops_around_location first if only location 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, idempotentHint, openWorldHint. The description adds that no live data is fetched and specifies return components (marker, polylines), which is valuable 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 well-structured sentences, front-loaded, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description adequately covers purpose, usage guidelines, and prerequisites. Parameter is simple. No gaps identified.
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 clear parameter description. The description reiterates it requires a numeric stop ID and adds cross-reference to get_stops_around_location, but adds minimal new semantic info beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns static map context for a stop: marker and polylines for every route. It uses specific verbs and resource, distinguishing from sibling 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?
Explicitly says when to use (enrich map, visualize routes) and when not to (live data needed), with a direct reference to get_stop_realtime as alternative. Also provides prerequisite to call get_stops_around_location if only coordinates are available.
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 and idempotent. The description adds that it produces a map UI block and structured list, which is behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with essential information, front-loaded with purpose, and no extraneous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, full schema coverage, and output schema, the description covers all necessary aspects: functionality, usage context, parameter source, and sibling relationships.
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 baseline 3. The description adds value by explaining how to obtain the stop ID (from signage) and when to use a different tool for other inputs, exceeding mere schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live arrivals and vehicle positions for a stop, specifying both a map UI block and structured arrival list. It distinguishes itself 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?
Explicitly says to use as default for arrivals/departures, prefers `get_stop_geometry` for static data, and suggests `get_stops_around_location` for address/coordinate inputs. Provides clear when-to-use and alternatives.
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 declare readOnlyHint=true and idempotentHint=true, so safety profile is clear. Description adds valuable context: emits a map UI block for map-capable clients, default radius is 1000 m, and valid radius range (50–3000). This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficiently structured: first sentence states primary function and added map UI block, second sentence provides usage guidance and exclusions, third sentence offers radius optimization tips. No redundant or superfluous information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return structure need not be described), the description is complete: it covers purpose, when to use, when not to use, and parameter behavior. Context signals (3 params, 2 required, 100% schema coverage, sibling tools) are fully addressed by the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already covers all parameters with descriptions (100% coverage). Description adds no new parameter details but provides usage context: default radius (1000 m), suggested values for dense urban (300 m) vs rural (3000 m), and clarifies that latitude/longitude use WGS84. This added value justifies a score above 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?
Description clearly states the tool discovers transit stops near a geographic point, returning specific metadata (code, name, coordinates, distance) and a map UI block. It distinguishes itself from sibling tools like get_stop_realtime (arrivals) and get_stop_geometry (geometry), ensuring unambiguous purpose.
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 to use as the first step when needing stop IDs before calling get_stop_realtime or get_stop_geometry, and warns not to use for arrivals or live data. Also provides radius adjustment guidance for dense urban vs rural areas, leaving no ambiguity about when to employ this tool.
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 InfoARead-onlyIdempotentInspect
Returns 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. |
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, so the safety profile is covered. The description adds useful behavioral context by listing returned fields (current position, bearing, route, etc.), which helps the agent understand what the tool returns without needing to infer from the output schema.
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 concise: two sentences that front-load the purpose, then provide usage guidance and exclusions. Every sentence adds value 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 has only one parameter with full schema coverage, clear annotations, and an output schema exists, the description is complete. It covers purpose, usage context, parameter source, and sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters (only one required parameter 'vehicle_id'). The description adds meaning beyond the schema by explicitly stating the source of valid vehicle IDs (from other specific tools), which helps the agent construct correct invocations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns full details for a specific transit vehicle by ID, listing key fields like current position, bearing, route, license plate, direction, and upcoming stop arrivals. It distinguishes from siblings by explicitly stating not to use for all vehicles on a route, and directs to 'get_route_realtime' instead.
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 guidance on when to use (track a particular vehicle, e.g., after seeing it on a 'get_route_realtime' map) and when not to use (use 'get_route_realtime' for all vehicles on a route). It also specifies where vehicle IDs come from: 'get_route_realtime', 'get_nearby_vehicles', or 'get_stop_realtime'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_tripPlan TripARead-onlyIdempotentInspect
Plans a transit trip from an origin stop to a destination stop using the static route graph. Returns direct options (single route) and 1-transfer options sorted by fewest stops. Use when the user asks 'how do I get from A to B?' or needs route recommendations between two stops. Requires numeric stop codes for both origin and destination; use get_stops_around_location first if you only have addresses or coordinates. Does NOT account for realtime service disruptions or live vehicle positions — combine with get_stop_realtime for live ETAs after planning.
| Name | Required | Description | Default |
|---|---|---|---|
| origin_stop_id | Yes | Numeric stop code of the departure stop. | |
| destination_stop_id | Yes | Numeric stop code of the destination stop. |
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?
Description adds context beyond annotations: specifies static graph usage, return format (direct and 1-transfer sorted by fewest stops), and limitations (no realtime). Annotations already indicate read-only and idempotent.
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 serves a purpose: function, usage, and prerequisites/limitations. Front-loaded and 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?
Covers input requirements, output description, and limitations. With output schema present, return format is likely documented. Complete for the tool's purpose.
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 baseline is 3. Description adds minimal extra meaning beyond schema (repeats numeric stop code requirement).
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 it plans a transit trip using static route graph, returns direct and 1-transfer options, distinguishing from siblings that handle realtime or nearby 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?
Explicitly states when to use (user asks for route from A to B), prerequisite (use get_stops_around_location for addresses), and limitation (no realtime, combine with get_stop_realtime for live ETAs).
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.