de en es ja ko zh

DB Timetable MCP Server

Name: DB Timetable MCP Server
Author: jorekai

by jorekai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

English | Deutsch

DB Timetable MCP Server

Smithery

A Model Context Protocol server for the official Deutsche Bahn Timetables API. It converts the compact DB XML into semantic JSON and merges the planned schedule with live changes into one station board.

What it guarantees

Correct platforms and times. effective holds the value to display. planned and changed explain the deviation.
Output built for models. Tools return structuredContent, descriptive JSON schemas, and a data model available as an MCP resource.
MCP conformance. Official TypeScript SDK, stdio for local clients, stateless Streamable HTTP for remote operation.
Safe defaults. No logs on stdout, loopback binding unless you change it, host allowlist, timeouts, non-root container, reproducible lockfile.
Verifiable behaviour. Unit, contract, and transport tests, coverage thresholds, CI, dependency and secret checks.

Related MCP server: db-mcp

Quick start

Requirements: Node.js 22 or 24 LTS, and a subscribed Timetables product in the DB API Marketplace.

git clone https://github.com/jorekai/db-timetable-mcp.git
cd db-timetable-mcp
npm ci
cp .env.example .env

Fill in .env:

DB_TIMETABLE_CLIENT_ID=deine-client-id
DB_TIMETABLE_CLIENT_SECRET=dein-api-key

Then build and start:

npm run build
npm start

In stdio mode the process waits for an MCP client. Status messages go to stderr only. stdout stays reserved for JSON-RPC.

Claude Desktop

Run npm ci && npm run build first, then point the configuration at an absolute path in claude_desktop_config.json.

macOS/Linux:

{
  "mcpServers": {
    "db-timetable": {
      "command": "node",
      "args": ["/absolute/path/db-timetable-mcp/dist/index.js"]
    }
  }
}

Windows:

{
  "mcpServers": {
    "db-timetable": {
      "command": "node",
      "args": ["C:\\absolute\\path\\db-timetable-mcp\\dist\\index.js"]
    }
  }
}

The .env file is looked up in the current working directory and next to the project directory, which covers the case where Claude Desktop starts the compiled server from somewhere else. You can also set the two credentials in the env object of the MCP entry instead.

After a configuration change, quit Claude Desktop completely and start it again. More in Troubleshooting.

Tools

Tool	Purpose
`getStationBoard`	Recommended. Joins the planned schedule and the full change set into a live station board
`getPlannedTimetable`	Static planned timetable for an EVA number, date, and hour
`getCurrentTimetable`	The complete change set (`fchg`), named this way for compatibility
`getRecentChanges`	Changes from the last two minutes (`rchg`) for incremental updates
`findStations`	Station search by name, EVA number, or DS100 code

Every tool takes an optional includeRawXml: true. The full reference with examples is in docs/api.md.

Data model

An arrival or departure event, abbreviated:

{
  "planned": { "time": { "local": "2026-07-17T10:20" }, "platform": "8" },
  "changed": { "time": { "local": "2026-07-17T10:27" }, "platform": "10" },
  "effective": { "time": { "local": "2026-07-17T10:27" }, "platform": "10" },
  "delayMinutes": 7,
  "platformChanged": true,
  "isCancelled": false
}

Use effective for anything a traveller sees. The model can retrieve the same explanation through the db-timetable://docs/data-model resource. Details in docs/data-model.md.

Streamable HTTP and Docker

Start it locally:

MCP_TRANSPORT=http npm start

MCP endpoint: http://127.0.0.1:3000/mcp
Health check: http://127.0.0.1:3000/health

With Docker Compose:

docker compose up --build -d
docker compose ps
curl http://127.0.0.1:3000/health

Compose binds the port to loopback on purpose, runs as an unprivileged user, and uses a read-only filesystem. A public endpoint additionally needs TLS and authentication behind a reverse proxy. ALLOWED_HOSTS must list every allowed hostname.

Configuration

Variable	Default	Description
`DB_TIMETABLE_CLIENT_ID`	–	DB client ID, required for API calls
`DB_TIMETABLE_CLIENT_SECRET`	–	DB API key, required for API calls
`DB_TIMETABLE_BASE_URL`	official v1 URL	Alternative base URL, mainly for tests
`DB_TIMETABLE_TIMEOUT_MS`	`15000`	Request timeout between 1000 and 120000 ms
`MCP_TRANSPORT`	`stdio`	`stdio` or `http`
`HOST`	`127.0.0.1`	HTTP bind address
`PORT`	`3000`	HTTP port
`MCP_ENDPOINT`	`/mcp`	Streamable HTTP path
`ALLOWED_HOSTS`	–	Comma-separated host allowlist, required with `0.0.0.0`/`::`
`DOTENV_CONFIG_PATH`	–	Explicit absolute path to an env file
`LOG_LEVEL`	`info`	`debug`, `info`, `warn`, or `error`

The old values TRANSPORT_TYPE=sse|httpStream and SSE_ENDPOINT still map to Streamable HTTP, so migration does not break an existing client.

Development

npm run dev          # stdio with watch mode
npm run dev:http     # Streamable HTTP with watch mode
npm run check        # lint, types, tests, and build
npm run test:coverage

Troubleshooting

Expected "," or "]" after array element in Claude Desktop

Update to version 2 and rebuild. Earlier versions wrote log lines to the stdio protocol channel. Version 2 uses stderr for that.

DB-API-Zugangsdaten fehlen even though .env exists (the message reads "DB API credentials are missing")

The file must sit in the repository root next to package.json. If it lives somewhere else, set DOTENV_CONFIG_PATH to an absolute path. Do not wrap the values in quotes or leave trailing spaces around them.

401/403 from the DB API

Check that the client ID and the API key belong together, and that the application has subscribed to the Timetables product.

Wrong platform

Use getStationBoard and read effective.platform. planned.platform is the scheduled platform by definition, and changed.platform is present only when DB has reported a change.

Data source and license

The timetable data comes from Deutsche Bahn and is served through the Timetables API 1.0.274. According to the DB API Marketplace the data is under CC BY 4.0, so attribution to Deutsche Bahn is required when you use it. The Marketplace currently states a limit of 60 calls per minute.

The MCP server itself is under the MIT 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

Name	Required	Description	Default
`pattern`	Yes	Suchmuster 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

Name	Required	Description	Default
`evaNo`	Yes	EVA-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

Name	Required	Description
`evaNo`	Yes	EVA-Nummer der Station (z.B. 8000105 für Frankfurt Hbf)
`date`	Yes	Datum im Format YYMMDD (z.B. 230401 für 01.04.2023)
`hour`	Yes	Stunde 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

Name	Required	Description	Default
`evaNo`	Yes	EVA-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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Feb 5, 2026
- First observedfindStations
- First observedgetCurrentTimetable
- First observedgetPlannedTimetable
- First observedgetRecentChanges

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-04-18 10:55 across 4 tools

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

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Db Rail A
io.github.pipeworx-io
DB Rail MCP — German + European rail and public transport, keyless.
Travel & Transportation Open Data
1
MobilityMCP A
eu.projektionisten
Journeys, departures, line courses, disruptions in Germany; nearby sharing as currently reported.
Government Data Location Services Travel & Transportation
131
kkjdaniel-bgg-mcp AOAuth
ai.smithery
BGG MCP provides access to the BoardGameGeek API through the Model Context Protocol, enabling retr…
Search Games & Gamification Entertainment & Media
10253
Swisstransport A
io.github.pipeworx-io
Swiss Transport MCP — wraps Transport Open Data API (free, no auth)
Travel & Transportation Open Data Government Data
432

Related MCP Servers

Deutsche Bahn MCP Server
Travel & Transportation Location Services
PaulvonBerg
F
license
Not graded
quality
C
maintenance
Provides unified access to Deutsche Bahn APIs for real-time railway data, station information, timetables, disruptions, parking, and accessibility services.
Updated 9 months ago (2026-01-06 15:44 UTC)
21
-
db-mcp
Travel & Transportation Location Services
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.
Updated 4 months ago (2026-06-07 10:27 UTC)
6
MIT
DB Timetable MCP Server
Travel & Transportation Open Data
zzuisa
A
license
A
quality
D
maintenance
Provides access to Deutsche Bahn's timetable data through MCP, enabling real-time train schedules, station search, and change tracking for German railway stations.
Updated 10 months ago (2025-12-24 13:44 UTC)
4
145 npm
MIT
db-fahrplan-mcp
Travel & Transportation Search
eric134422
A
license
A
quality
D
maintenance
An (unofficial) MCP server for the Deutsche Bahn Timetables API — station search, planned departures, and real-time changes (delays, platform changes, cancellations) as tools for Claude and other MCP clients.
Updated 3 months ago (2026-07-21 11:49 UTC)
4
2
MIT