Skip to main content
Glama
deenesjakozh
jorekai

DB Timetable MCP Server

by jorekai
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

DB Timetable MCP Server

A Model Context Protocol (MCP) server for the Deutsche Bahn Timetable API. The server provides MCP tools and resources for accessing timetable data, station information, and train changes.

Obligation to name:

This project provides Deutsche Bahn timetable data, which is publicly available under the Creative Commons Attribution 4.0 International License (CC BY 4.0) .

Further information about the API and license terms can be found at developers.deutschebahn.com . API requests are subject to the license terms.

Functions

  • Current timetables : Retrieve current timetable data for a station

  • Timetable changes : Tracking the latest changes

  • Planned timetables : Access to planned timetable data for a specific time

  • Station search : Search for train stations by name or code

Related MCP server: db-mcp

Requirements

  • Node.js 18 or higher

  • API credentials for the DB Timetable API (client ID and client secret)

installation

  1. Clone repository:

    git clone <repository-url>
cd db-mcp

  2. Install dependencies:

    npm install

  3. Compile TypeScript code:

    npm run build

configuration

Create an .env file in the root directory of the project with the following environment variables:

DB_TIMETABLE_CLIENT_ID=deine-client-id
DB_TIMETABLE_CLIENT_SECRET=dein-client-secret
TRANSPORT_TYPE=stdio
PORT=8080
SSE_ENDPOINT=/sse
LOG_LEVEL=info

Configuration options

  • DB_TIMETABLE_CLIENT_ID : Client ID for the DB API (required)

  • DB_TIMETABLE_CLIENT_SECRET : Client secret for the DB API (required)

  • TRANSPORT_TYPE : Transport type for the MCP server ( stdio or sse , default: stdio )

  • PORT : Port for the SSE server (default: 8080 )

  • SSE_ENDPOINT : Endpoint for SSE connections (default: /sse )

  • LOG_LEVEL : Logging level ( debug , info , warn , error , default: info )

use

Start server

In stdio mode (for CLI testing and debugging):

npm start

In SSE mode (for web clients):

TRANSPORT_TYPE=sse npm start

Test with Inspect mode

The server can be tested with the FastMCP Inspector:

npx fastmcp inspect path/to/index.js

MCP tools

The server provides the following tools:

  1. getCurrentTimetable : Retrieves current timetable data for a station

    • Parameter: evaNo - EVA number of the station (e.g. 8000105 for Frankfurt Hbf)

  2. getRecentChanges : Retrieves recent changes for a station

    • Parameter: evaNo - EVA number of the station (e.g. 8000105 for Frankfurt Hbf)

  3. getPlannedTimetable : Retrieves planned timetable data for a station

    • Parameter:

      • evaNo - EVA number of the station (e.g. 8000105 for Frankfurt Hbf)

      • date - Date in YYMMDD format (e.g. 230401 for 01.04.2023)

      • hour - hour in HH format (e.g. 14 for 2 p.m.)

  4. findStations : Searches for stations using a search pattern

    • Parameter: pattern - search pattern (e.g. "Frankfurt" or "BLS")

MCP resources

The server provides the following resources:

  1. Current timetable data : db-api:timetable/current/{evaNo}

  2. Current timetable changes : db-api:timetable/changes/{evaNo}

  3. Planned timetable data : db-api:timetable/planned/{evaNo}/{date}/{hour}

  4. Station search : db-api:station/{pattern}

Development

Project structure

db-mcp/
├── src/
│   ├── api/             # API-Client und Typen
│   ├── tools/           # MCP-Tools
│   ├── resources/       # MCP-Ressourcen
│   ├── utils/           # Hilfsfunktionen
│   ├── config.ts        # Konfiguration
│   └── index.ts         # Haupteinstiegspunkt
├── dist/                # Kompilierte Dateien
├── .env                 # Umgebungsvariablen
├── package.json
├── tsconfig.json
└── README.md

NPM scripts

  • npm run build : Compiles the TypeScript code

  • npm start : Starts the server

  • npm run dev : Starts the server in development mode with automatic reloading

  • npm test : Runs tests

Extensibility

Potential extensions

  1. Data processing and enrichment

    • Semantic timetable data processing: XML to structured JSON with semantic enrichment

    • Historical data analysis for delays and disruptions

    • Integration of multimodal transport connections

  2. Advanced MCP tools

    • Route planning between stations

    • AI-based delay and capacity forecasts

    • Travel disruption analysis

    • Accessibility check for stations and connections

License

MCP Server: MIT License

DB Timetable API: Creative Commons Attribution 4.0 International License

Available Tools

4 tools
findStationsB

Durchsucht das Verzeichnis der Bahnhofsstationen anhand eines gegebenen Suchmusters. Dies kann der Name der Station oder die EVA-Nummer sein. Das Tool liefert eine Liste von Stationen, die dem Suchmuster entsprechen.

ParametersJSON Schema
NameRequiredDescriptionDefault
patternYesSuchmuster für Stationen (z.B. Frankfurt oder 8000105)

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the search functionality and return type (list of stations) but lacks details on permissions, rate limits, error handling, or whether it's a read-only operation. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured in three sentences: it states the action, explains the parameter, and describes the output. Every sentence adds value without redundancy, making it efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (search with one parameter) and no annotations or output schema, the description is minimally adequate. It covers the basic purpose and parameter but lacks details on behavioral traits, usage context, and output format. It meets the minimum viable standard but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already fully documents the single parameter 'pattern'. The description adds minimal value by mentioning it can be a station name or EVA number, which is already implied in the schema's example. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: searching a directory of railway stations using a search pattern (station name or EVA number) and returning a matching list. It specifies the resource (station directory) and verb (search), but doesn't explicitly differentiate from sibling tools like timetable or change queries, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description explains what it does but doesn't mention when it's appropriate compared to sibling tools (getCurrentTimetable, getPlannedTimetable, getRecentChanges) or any other search methods. There's no context about prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getCurrentTimetableA

Ruft die aktuellen Fahrplandaten einer bestimmten Bahnhofsstation ab. Dies beinhaltet Informationen zu Ankunfts- und Abfahrtszeiten, Gleisbelegungen, Verspätungen und weitere Echtzeitinformationen für den aktuellen Betriebstag.

ParametersJSON Schema
NameRequiredDescriptionDefault
evaNoYesEVA-Nummer der Station (z.B. 8000105 für Frankfurt Hbf)

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that this is a read operation (retrieves data) and specifies what data is included (arrival/departure times, platform assignments, delays, real-time info). However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with two sentences that efficiently convey the tool's purpose and scope. The first sentence states the core function, and the second elaborates on what data is included. No wasted words, though it could be slightly more front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with no annotations and no output schema, the description provides adequate context about what data is returned. However, it doesn't describe the return format, potential pagination, or error handling, which would be helpful given the lack of structured output documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the evaNo parameter well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Ruft die aktuellen Fahrplandaten ab' - retrieves current timetable data) and resource ('einer bestimmten Bahnhofsstation' - of a specific railway station). It distinguishes from siblings by specifying it's for current/real-time data (vs. planned timetable or station search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool - for current timetable data with real-time information for the current operating day. It doesn't explicitly state when NOT to use it or name alternatives, but the context strongly implies this is for real-time vs. planned data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getPlannedTimetableB

Holt die geplanten Fahrplandaten für eine angegebene Bahnhofsstation zu einem bestimmten Datum und einer bestimmten Stunde ein. Diese Funktion ist nützlich, um Fahrpläne im Voraus zu planen und Informationen über zukünftige Zugverbindungen zu erhalten.

ParametersJSON Schema
NameRequiredDescriptionDefault
evaNoYesEVA-Nummer der Station (z.B. 8000105 für Frankfurt Hbf)
dateYesDatum im Format YYMMDD (z.B. 230401 für 01.04.2023)
hourYesStunde im Format HH (z.B. 14 für 14 Uhr)

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is a read operation for retrieving data, it doesn't disclose important behavioral traits such as whether the tool requires authentication, has rate limits, what format the returned data takes, or whether it supports pagination for large result sets. The description adds minimal behavioral context beyond the basic retrieval function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with two sentences that each serve a purpose: the first states the core functionality, the second provides usage context. It's front-loaded with the main purpose and avoids unnecessary elaboration. While efficient, it could potentially be slightly more concise by combining the two sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with 3 well-documented parameters and no output schema, the description provides adequate but incomplete context. It covers the basic purpose and usage scenario but lacks important details about the return format, error conditions, and behavioral constraints. Without annotations or output schema, the description should do more to help an agent understand what to expect from the tool's execution.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage with clear parameter documentation including examples and format specifications. The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it merely restates that parameters are for station, date, and hour without providing additional context or clarification. With complete schema coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: retrieving planned timetable data for a specified train station, date, and hour. It uses specific verbs ('holt...ein' - fetches/retrieves) and identifies the resource ('Fahrplandaten' - timetable data). However, it doesn't explicitly differentiate from sibling tools like getCurrentTimetable, which appears to serve a similar function but for current rather than planned data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implied usage context by stating the tool is useful for planning schedules in advance and obtaining information about future train connections. However, it doesn't explicitly state when to use this tool versus alternatives like getCurrentTimetable or findStations, nor does it mention any prerequisites or exclusions for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getRecentChangesB

Ermittelt die neuesten Fahrplanänderungen für eine spezifische Bahnhofsstation. Dazu gehören Verspätungen, Gleisänderungen, Ausfälle und andere kurzfristige Anpassungen im Betriebsablauf, die in Echtzeit aktualisiert werden.

ParametersJSON Schema
NameRequiredDescriptionDefault
evaNoYesEVA-Nummer der Station (z.B. 8000105 für Frankfurt Hbf)

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions real-time updates and lists types of changes (delays, track changes, cancellations), but doesn't address critical aspects like rate limits, authentication requirements, data freshness guarantees, or error conditions. For a real-time data tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with two sentences that efficiently convey the tool's purpose and scope. The first sentence states the core function, and the second elaborates on what's included and the real-time nature. There's minimal wasted verbiage, though it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (real-time operational data), no annotations, and no output schema, the description provides adequate basic context but lacks completeness. It covers what data is retrieved but doesn't address format, pagination, error handling, or limitations. The absence of output schema means the description should ideally explain return values, which it doesn't.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100% with the single parameter 'evaNo' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Ermittelt die neuesten Fahrplanänderungen für eine spezifische Bahnhofsstation' (retrieves the latest schedule changes for a specific train station). It specifies the verb 'ermittelt' (retrieves) and resource 'Fahrplanänderungen' (schedule changes), and distinguishes from siblings by focusing on real-time operational adjustments rather than station lookup or timetable retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by mentioning 'Echtzeit aktualisiert werden' (updated in real-time), suggesting this tool is for current operational changes rather than planned timetables. However, it doesn't explicitly state when to use this tool versus alternatives like getCurrentTimetable or getPlannedTimetable, nor does it provide exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: findStations searches for stations, getCurrentTimetable retrieves real-time data, getPlannedTimetable fetches future schedules, and getRecentChanges tracks recent changes. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern with three tools starting with 'get' and one with 'find', all using camelCase. The minor deviation is 'findStations' versus 'getX', but it remains readable and predictable.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of accessing railway timetable data. Each tool serves a specific and necessary function, providing a focused set without being too sparse or overwhelming.

Completeness4/5

The tool set covers core operations for timetable data: searching stations, retrieving current and planned schedules, and tracking changes. A minor gap is the lack of tools for modifying or managing data (e.g., CRUD operations), but this may be intentional for a read-only server, and agents can work around this limitation.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • db-mcp

    Amor216
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that exposes the Deutsche Bahn public transport API to any MCP-compatible client (Claude Desktop, Cursor, Cline, Continue, etc.). Five tools cover station search, departures, journey planning, trip details, and nearby stations.
    6
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jorekai/db-timetable-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server