Skip to main content
Glama
loosephoto

tokyo-transit-mcp

by loosephoto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Get Timetable

get_timetable
Read-onlyIdempotent

Find train departure times for a specified station using ODPT timetable data; filter by date, railway, calendar, or response language.

Instructions

🕐 時刻表検索 - 指定駅の時刻表をODPTデータから検索します。直接時刻を提供します。language（ja/en/zh）指定で応答言語を強制可能。

Input Schema

NameRequiredDescriptionDefault
dateNo検索日 YYYY-MM-DD（省略時は当日。calendar 未指定時の曜日判定に使用）
railwayNo路線名（省略可）
calendarNo対象カレンダー（省略時は検索日/当日の曜日で自動判定。土日=SaturdayHoliday）
languageNo応答言語の強制指定（省略時は駅名から自動判定）
station_nameYes駅名

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.58.7
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / calendar
      Added value: +{
+  "description": "対象カレンダー（省略時は検索日/当日の曜日で自動判定。土日=SaturdayHoliday）",
+  "enum": [
+    "Weekday",
+    "SaturdayHoliday",
+    "平日",
+    "土休日"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / date
      Added value: +{
+  "description": "検索日 YYYY-MM-DD（省略時は当日。calendar 未指定時の曜日判定に使用）",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}
    • addedInput schema / properties / language
      Added value: +{
+  "description": "応答言語の強制指定（省略時は駅名から自動判定）",
+  "enum": [
+    "ja",
+    "en",
+    "zh"
+  ],
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds useful context that data comes from ODPT and that it directly returns timetable times, but it does not describe response format, pagination, or limitations.

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 short and front-loaded, with the core purpose stated first. The emoji and repeated “timetable search” label are minor stylistic redundancy but do not obscure meaning.

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

Completeness4/5

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

For a read-only timetable lookup with rich input-schema coverage and annotations, the description provides enough context: source, station focus, direct time provision, and language forcing. It could be stronger by clarifying return shape, but no output schema exists and the core behavior is covered.

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?

Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description only highlights the language parameter and otherwise adds little beyond the schema's parameter semantics.

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 gives a specific verb and resource: searching a specified station's timetable from ODPT data. It clearly differentiates the tool from route/status siblings by focusing on timetable retrieval, though it does not explicitly name alternatives.

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?

Usage is implied by “specified station timetable” and “directly provides times,” which tells an agent when the tool is relevant. However, it gives no explicit when-not guidance or comparison to siblings such as search_route or get_station_info.

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

Deploy Server

Other Tools