mirodn Public Transport MCP

Quick Verdict

mirodn/mcp-server-public-transport 0.1.4 is an unofficial, pre-alpha Model Context Protocol server for public transport data. It requires Python 3.11 or newer and aggregates providers covering six European regions: the United Kingdom, Switzerland, Norway, Belgium, Berlin/Brandenburg, and the Lisbon and Porto areas of Portugal. Depending on the region, tools may expose departures, arrivals, station lookup, nearby stops, journey planning, train connections, or vehicle locations. Coverage does not mean that every feature exists in every region under one uniform schema.

It is a reasonable candidate for personal experiments, travel-assistant prototypes, and MCP learning. It should not be treated as an authoritative source for missed-connection guarantees, emergency travel, accessibility commitments, or commercial dispatch without independent validation. The project is not a transport operator. Accuracy, latency, geographical boundaries, availability, and allowed usage come from several upstream providers. Version 0.1.4 being pre-alpha is a direct warning that interfaces and behavior can change. HTTP/SSE operation creates an additional risk when an unauthenticated server listens on 0.0.0.0; authentication and network controls must come before remote exposure.

Best For

• MCP developers prototyping conversational queries over European public transport data.
• Teams that want several regional providers behind one project and can handle different tools and response fields per region.
• Engineers prepared to add caching, timeouts, rate limits, monitoring, attribution, and provider-specific policy controls.
• Learners studying tool design for stations, coordinates, live departures, and journey planning.
• It is not ideal for global coverage, guaranteed accessibility information, authoritative fares, unattended critical decisions, or any workflow that assumes all six regions behave identically.

Key Features

• Six regional integrations: United Kingdom, Switzerland, Norway, Belgium, Berlin/Brandenburg, and Lisbon/Porto in Portugal.
• Region-specific transport tools: The combined set can include live departures and arrivals, station search, nearby stops, journeys, rail connections, and bus positions.
• Only the UK needs project credentials: TransportAPI uses an application ID and API key. Other current integrations use their respective open endpoints, subject to policy changes.
• Python runtime: The 0.1.4 package targets Python 3.11 or newer and can be installed in an isolated project environment.
• Multiple MCP transports: Local client use is possible, while HTTP/SSE-style remote paths require deliberate security configuration.
• MIT-licensed code: The server source is inspectable and modifiable, but transport records, maps, names, and provider brands do not become MIT-licensed data.
• Transparent upstream split: Each region maps to a named provider, making provider-by-provider testing possible.

Use Cases

A useful prototype might answer, “What leaves this Berlin station during the next thirty minutes?” The assistant first resolves a location, retains the provider’s station identifier, then requests departure data. Norway or Portugal may expose tools better suited to journey planning, while UK access depends on TransportAPI credentials and its available fields. A client should show the source, query time, stop identifier, and uncertainty instead of collapsing everything into one confident sentence.

Nearby-place queries need explicit boundaries. Results depend on latitude/longitude order, radius, provider coordinate quality, and ambiguous place names. Berlin/Brandenburg is not all of Germany, and the Portuguese integration is scoped to Lisbon and Porto rather than nationwide coverage. If a user supplies a home, workplace, or live position, reduce logging, shorten retention, and avoid passing exact coordinates to unrelated model services. For an imminent trip, the interface should tell users to confirm disruptions and platform changes through the relevant operator.

The server can also serve as an engineering reference for normalizing heterogeneous APIs. That experiment should include partial outages. One slow provider must not block every region, retries must not violate rate policies, and cached results need timestamps. Contract tests should preserve provider differences rather than pretending that missing data is an empty, authoritative answer.

Pricing

Version 0.1.4 is open source under MIT and has no documented project subscription. Operating it still consumes compute, logs, monitoring, outbound requests, and engineering time. The UK TransportAPI account may have its own quotas, pricing, or commercial conditions. The other current integrations do not require a key in this project, but “no key” does not mean unlimited requests, no attribution, or unrestricted commercial use.

Portugal relies on upstream infrastructure such as Transitous, whose attribution and usage policy must be followed. Every other provider has its own terms as well. MIT applies to the server code, not to live transport records, OpenStreetMap-derived material, logos, stop names, or API access. A serious deployment should maintain a provider register covering purpose, quotas, cache duration, attribution, geographical scope, and incident contacts.

Pros

• One repository gives an experimental entry point to six European transport regions.
• Structured MCP tools reduce the initial work of wrapping station, departure, and journey endpoints.
• Only the UK currently needs provider credentials in the project configuration.
• Python source and an MIT license make local inspection and modification straightforward.
• Named upstream providers let teams measure quality and reliability separately for each region.
• Local operation can keep client configuration and request handling under the deployer’s control.
• The regional variety is useful for testing how an assistant handles non-uniform tool capabilities.

Cons

• Version 0.1.4 is explicitly pre-alpha and should not be assumed to provide a stable production contract.
• It is unofficial and has no transport-operator guarantee of accuracy, freshness, or availability.
• Tools and fields differ by region; Portugal is limited to Lisbon and Porto.
• Keyless providers can still enforce attribution, fair-use limits, caching rules, and later policy changes.
• Disruptions, platforms, fares, accessibility, and crowding may be absent, incomplete, or delayed.
• An unauthenticated HTTP/SSE service on 0.0.0.0 exposes tool access and potentially sensitive location requests.
• Multiple providers multiply timeout, schema-change, monitoring, and terms-of-service work.

Alternatives

FAQ

Is this an official public transport server?

No. It is a community project maintained by mirodn and reads several third-party or public APIs. For actual travel, operator channels and on-site information remain authoritative.

Is version 0.1.4 ready for production?

Not without substantial evaluation and hardening. Pre-alpha means contracts may change. At minimum, pin the version, add contract tests, enforce timeouts and rate limits, monitor each provider, review data terms, and define a human fallback.

Do all six regions require API keys?

The current project configuration requires an application ID and key only for UK TransportAPI. Other providers may work without project credentials, but they can still impose usage, attribution, rate, and commercial restrictions.

Can the HTTP/SSE server listen on 0.0.0.0?

It may run that way, but an unauthenticated listener should not be exposed. Bind to a controlled interface, restrict access with a firewall and reverse proxy, add TLS and authentication, rate-limit requests, redact logs, and isolate provider secrets.

Why can nearby stops or journeys be wrong?

Common causes include reversed coordinates, radius choices, duplicate place names, provider delays, and geographical limits. Portugal is scoped to Lisbon and Porto, and every other integration should be interpreted within its listed provider boundary.

Can the data be used in a commercial travel product?

The MIT code license is not enough to answer that. Review each provider’s data rights, attribution, caching, branding, accuracy disclaimer, account quota, and commercial-use policy before release.

Bottom Line

mirodn Public Transport MCP is a convenient pre-alpha bridge to six European regions, not an official, uniform, global transport platform. For prototypes, it reduces the effort needed to wrap several APIs. For production, heterogeneous providers, sensitive location queries, narrow geographical boundaries, and a changing 0.1.4 contract create ongoing engineering and governance work.

Start with one region. Pin 0.1.4, test at least ten known stations and journeys, record provider sources and timestamps, and deliberately simulate timeouts, limits, invalid coordinates, and empty responses. Prefer a local transport during evaluation. If remote HTTP/SSE is necessary, secure it before adding real users. Expand only after provider terms, observed data quality, attribution, and fallback behavior have passed review.