io.github.mohammad-abbasi-sh/flixtrain-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Unofficial read-only MCP server for FlixTrain departures via the FlixBus shop search API (no key, no login): search train-only departures between two cities on a date (times, stations, duration, price, seats), and find cities by name. NOTE: only FlixTrain legs are listed (buses on the same route are counted, not shown); city names resolve through autocomplete — Köln is returned as "Cologne" (the API's canonical name). Dates are DD.MM.YYYY, one-way only. Built by Mohammad Abbasi (mohammad-abbasi-sh) — https://almanibama.ir · https://mabbasi.ir — Germany MCP factory.
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| flixtrain_search_trainsA | Search FlixTrain-only departures between two cities on a date. from_city / to_city: city names, e.g. Berlin, Hamburg, Köln (Cologne). date: DD.MM.YYYY, e.g. 11.11.2026. limit: 1..20 (default 10). sort: departure (default) or price. |
| flixtrain_search_citiesA | Find cities by name (with train-station flag) for the train search. query: e.g. Berlin, Köln, München. limit: 1..10 (default 10). |
| flixtrain_healthA | Check whether the FlixBus search API is reachable right now. Returns status ok (HTTP 200), blocked (HTTP 403/429 — bot wall or rate limit) or error, plus the HTTP status and the probed URL. One polite request; it does not fetch any listings. |
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 3 tools
Each tool targets a clearly distinct concern: train departure search, city lookup, and API health probing. There is no overlap in inputs or outputs, and the fed relationship (cities → train search) is obvious from the descriptions.
All names share the `flixtrain_` prefix and mostly follow verb_noun (search_trains, search_cities). `flixtrain_health` drops the verb form, a minor deviation that is still unambiguous.
Three tools is on the thin side but each earns its place for a read-only search integration. Nothing extraneous, though a slightly richer surface (e.g. station/connection detail) would feel less minimal.
Discovery (cities), the core search, and a diagnostic health check form a coherent lifecycle for a search-only server. Gaps like no journey detail/price breakdown endpoint or deeper filtering exist, but agents can work around them with the search result payload.