Skip to main content
Glama
loosephoto

tokyo-transit-mcp

by loosephoto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Search Route

search_route
Read-onlyIdempotent

Find transit routes between any two stations in Tokyo with automatic language detection, weather and disruption alerts, plus AI advice on cycling alternatives.

Instructions

乗り換えルート検索 - 出発駅から到着駅までのルートを検索。日本語・英語・中国語自動識別、天候/高温/運休を検出しAIアドバイスを返答。language（ja/en/zh）を指定すると応答言語を強制（ユーザーのクエリ言語に合わせて指定推奨）。荒天・降雪・凍結時を除き、到着地点周辺のレンタサイクル案内を表示。user_location（緯度経度）指定時は運転見合わせ時の代替シェアサイクル案内を現在地基準で表示。

【出力指示/OUTPUT RULE】ツールの content には「表示済みの完成テキスト」が既に日本語・英語・中国語のどれかで含まれている。この content をそのままユーザーへ提示すること。要約・再構成・言い換え・省略・見出しの書き換えを一切しないこと。特に運転見合わせ・特別警報・緊急避難・振替輸送・シェアサイクル代替（emergency_alert / cycling_alternative / bus_transfer_alternative / suspended_lines / ai_transit_advice）など運行障害時の安全情報は、原文のまま必ずすべて表示すること。追加の説明は content の後に補足として付け加えてもよい。

Input Schema

NameRequiredDescriptionDefault
toYes到着駅名
fromYes出発駅名
languageNo応答言語の強制指定（省略時は駅名から自動判定）。ユーザーが英語で質問した場合は en、中国語なら zh を指定すると確実にその言語で応答。
user_locationNoユーザーの現在位置（緯度経度）。運転見合わせ時のシェアサイクル案内を現在地基準で表示する場合に指定。例: {"lat": 35.681, "lon": 139.767}

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 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 / language
      Added value: +{
+  "description": "応答言語の強制指定（省略時は駅名から自動判定）。ユーザーが英語で質問した場合は en、中国語なら zh を指定すると確実にその言語で応答。",
+  "enum": [
+    "ja",
+    "en",
+    "zh"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / user_location
      Added value: +{
+  "additionalProperties": false,
+  "description": "ユーザーの現在位置（緯度経度）。運転見合わせ時のシェアサイクル案内を現在地基準で表示する場合に指定。例: {\"lat\": 35.681, \"lon\": 139.767}",
+  "properties": {
+    "lat": {
+      "maximum": 90,
+      "minimum": -90,
+      "type": "number"
+    },
+    "lon": {
+      "maximum": 180,
+      "minimum": -180,
+      "type": "number"
+    }
+  },
+  "required": [
+    "lat",
+    "lon"
+  ],
+  "type": "object"
+}
  2. First observedv1.0.0

TDQS

A3.9/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive/openWorld). The description goes well beyond them: auto language detection, weather/heat/suspension detection, AI advice generation, the exact rule for when rental-cycle info appears, and a crucial output contract that content is already a finished localized text that must not be summarized or rewritten, with safety fields (emergency_alert/suspended_lines/etc.) preserved verbatim. This is exactly the behavioral context an agent needs and could not derive from structured fields.

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?

Purpose and conditional behaviors are front-loaded in the first block, and the OUTPUT RULE is separated and clearly marked. It is somewhat long and the output rule is repetitive in its prohibitions, but each sentence carries actionable content and nothing is pure filler.

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?

With no output schema, the description compensates by defining what 'content' contains and how it must be presented, which is essential for this tool. It also covers the main edge behaviors (weather, suspension, alternatives). Minor gaps remain — it doesn't describe response size/pagination or how multiple candidate routes are represented — but for a read-only search this is largely complete.

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 from/to/language/user_location are already documented, including the language enum and the lat/lon example. The description restates the language-forcing behavior and the user_location purpose but adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource: '乗り換えルート検索 - 出発駅から到着駅までのルートを検索' (transfer route search from origin to destination station). It is clearly separable from search_flight/search_bus/search_ferry by its station-to-station transfer framing, though it never explicitly says it covers rail/train versus other modes, so differentiation from the other search_* siblings is implied rather than stated.

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?

Provides conditional guidance on feature activation — when to pass language (match the user's query language), when to pass user_location (alternative shared-cycle on suspension), and when cycling guidance is suppressed (severe weather/snow/freezing). However, it never states when to choose this tool over siblings such as search_bus or get_timetable, so alternative selection is left to inference.

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