STPT MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STPT_MCP_HOST | No | HTTP bind address. | 127.0.0.1 |
| STPT_MCP_PATH | No | Streamable HTTP path. | /mcp |
| STPT_MCP_PORT | No | HTTP port. | 8000 |
| STPT_MCP_LOG_LEVEL | No | Python log level. | INFO |
| STPT_MCP_TRANSPORT | No | Transport protocol: stdio or http. | stdio |
| STPT_MCP_AUTH_TOKEN | No | Optional static bearer token (16+ chars). | |
| STPT_MCP_ALLOWED_HOSTS | No | Allowed hosts; required for non-loopback binds. | loopback |
| STPT_MCP_ALLOWED_ORIGINS | No | Browser origins allowed by the SDK. | loopback |
| STPT_MCP_MAX_REQUEST_BODY_SIZE | No | HTTP request body limit in bytes. | 1048576 |
| STPT_MCP_MAX_CONCURRENT_HTTP_REQUESTS | No | HTTP concurrency cap. | 100 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_stopsA | Search the bundled STPT network by stop ID, stop name, or line. Uses diacritic-insensitive matching. Returns up to 50 stops. |
| get_stopA | Get coordinates, serving lines, directions, terminals, and neighboring stops for a numeric STPT stop ID. |
| list_routesB | List STPT tram, trolleybus, bus, metropolitan, express, and vaporetto routes from the bundled GTFS-derived network snapshot. |
| get_arrivalsA | Get upcoming arrivals at an STPT stop. Live data is used only when its freshness is verified; otherwise departures come from the bundled GTFS timetable. Check provenance.freshness, provenance.fallback_reason, and each arrival's live flag. |
| get_alertsA | Get current or historical STPT service alerts. Filters by stop ID and/or line when supplied. Active periods are evaluated in Europe/Bucharest. |
| get_vehiclesA | Get current STPT vehicle positions, optionally filtered by line. Each vehicle includes its upstream observation timestamp and staleness flag. |
| get_service_statusA | Report server readiness, version, bundled network feed metadata, and bounded cache statistics. Contains no secrets. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a distinct transit object or concern: stop search, stop detail, route listing, arrivals, service status, alerts, and vehicle positions. Boundaries are clear even where arrivals and vehicle positions both relate to live transit data.
All tool names use a consistent snake_case verb_noun convention: search_stops, get_stop, list_routes, get_arrivals, get_service_status, get_alerts, get_vehicles. No ambiguous or inconsistent naming styles appear.
Seven tools is well-scoped for a transit MCP server, covering discovery, detail, arrivals, alerts, vehicles, and health without bloat. Each tool has a clear role.
The surface covers core transit workflows: finding stops, viewing routes and stop details, checking arrivals, alerts, and vehicle positions. Minor gaps exist, such as explicit route-detail or trip-planning operations, but core use cases are supported.