Skip to main content
Glama
deenesjakozh
jorekai

DB Timetable MCP Server

by jorekai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

铁匠徽章

DB 时刻表 MCP 服务器

德国铁路时刻表 API 的模型上下文协议 (MCP) 服务器。该服务器提供 MCP 工具和资源来访问时刻表数据、车站信息和列车变更。

命名义务：

该项目提供德国铁路时刻表数据，根据知识共享署名 4.0 国际许可协议 (CC BY 4.0)向公众开放。

有关 API 和许可条件的更多信息，请访问developers.deutschebahn.com 。 API 请求受许可条款的约束。

功能

  • 当前时刻表：检索车站的当前时刻表数据

  • 时间表变更：跟踪最新变更

  • 计划时间表：访问特定时间的计划时间表数据

  • 车站搜索：按名称或代码搜索火车站

Related MCP server: db-mcp

要求

  • Node.js 18 或更高版本

  • DB 时间表 API 的 API 凭证（客户端 ID 和客户端密钥）

安装

  1. 克隆存储库：

    git clone <repository-url>
cd db-mcp

  2. 安装依赖项：

    npm install

  3. 编译 TypeScript 代码：

    npm run build

配置

在项目根目录中创建一个.env文件，其中包含以下环境变量：

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

配置选项

  • DB_TIMETABLE_CLIENT_ID ：DB API 的客户端 ID（必需）

  • DB_TIMETABLE_CLIENT_SECRET ：DB API 的客户端密钥（必需）

  • TRANSPORT_TYPE ：MCP 服务器的传输类型（ stdio或sse ，默认值： stdio ）

  • PORT ：SSE 服务器的端口（默认值： 8080 ）

  • SSE_ENDPOINT ：SSE 连接的端点（默认值： /sse ）

  • LOG_LEVEL ：日志级别（ debug ， info ， warn ， error ，默认值： info ）

使用

启动服务器

在 stdio 模式下（用于 CLI 测试和调试）：

npm start

在 SSE 模式下（针对 Web 客户端）：

TRANSPORT_TYPE=sse npm start

使用检查模式进行测试

可以使用 FastMCP Inspector 测试服务器：

npx fastmcp inspect path/to/index.js

MCP 工具

该服务器提供以下工具：

  1. getCurrentTimetable ：检索车站的当前时刻表数据

    • 参数： evaNo - 车站的 EVA 编号（例如法兰克福 Hbf 的 EVA 编号为 8000105）

  2. getRecentChanges ：检索电台的最近更改

    • 参数： evaNo - 车站的 EVA 编号（例如法兰克福 Hbf 的 EVA 编号为 8000105）

  3. getPlannedTimetable ：检索车站的计划时刻表数据

    • 范围：

      • evaNo - 车站的 EVA 编号（例如法兰克福 Hbf 的 EVA 编号为 8000105）

      • date - YYMMDD 格式的日期（例如 230401 表示 01.04.2023）

      • hour - HH 格式的小时（例如 14 表示下午 2 点）

  4. findStations ：使用搜索模式搜索车站

    • 参数： pattern - 搜索模式（例如“Frankfurt”或“BLS”）

MCP 资源

服务器提供以下资源：

  1. 当前时间表数据： db-api:timetable/current/{evaNo}

  2. 当前时间表变更： db-api:timetable/changes/{evaNo}

  3. 计划时间表数据： db-api:timetable/planned/{evaNo}/{date}/{hour}

  4. 站点搜索： db-api:station/{pattern}

发展

项目结构

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 脚本

  • npm run build ：编译 TypeScript 代码

  • npm start ：启动服务器

  • npm run dev ：以开发模式启动服务器并自动重新加载

  • npm test ：运行测试

可扩展性

潜在的扩展

  1. 数据处理和丰富

    • 语义时间表数据处理：将 XML 转换为具有语义丰富的结构化 JSON

    • 延误和中断的历史数据分析

    • 多式联运连接的整合

  2. 先进的 MCP 工具

    • 站间路线规划

    • 基于人工智能的延误和容量预测

    • 出行中断分析

    • 车站和连接点的无障碍检查

执照

MCP 服务器： MIT 许可证

DB 时刻表 API：知识共享署名 4.0 国际许可证

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.

Tool Schema Changelog

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

  1. 4 tool updatesv1.0.0
    • 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 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

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

  • DB Timetable MCP Server

    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.
    4
    145 npm
    MIT

  • db-fahrplan-mcp

    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.
    4
    2
    MIT