Skip to main content
Glama
loosephoto

tokyo-transit-mcp

by loosephoto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Search Bus

search_bus
Read-onlyIdempotent

Search bus stops and routes, then plan bus, train, or ferry transfers between two points in Tokyo with accessibility and language options.

Instructions

🚌🚃 バス路線・乗り継ぎ・横断乗り継ぎ検索 - バス停/系統を検索、from+to でバス→電車→バスの乗り継ぎ経路を探索。ノンステップバス情報を含む。language（ja/en/zh）指定で応答言語を強制可能。

Input Schema

NameRequiredDescriptionDefault
toNo到着バス停名（乗り継ぎ検索モード: from と共に指定）
fromNo出発バス停名（乗り継ぎ検索モード: to と共に指定・バス→電車→バスも可）
vehicleNo優先する乗り物（乗り継ぎ検索モードのみ）。bus=バス優先, train=電車優先, community_bus=コミュニティバス優先, ferry=水上バス優先, any=自動（最短）。指定乗り物が極端に遠回りになる場合は better_alternative でより良い経路を進言。
languageNo応答言語の強制指定（省略時はバス停名から自動判定）
busstop_nameNoバス停名（部分一致・バス停検索モード）

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv2.58.7
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / busstop_name / description
      Previous value: -"バス停名（部分一致）"New value: +"バス停名（部分一致・バス停検索モード）"
    • addedInput schema / properties / from
      Added value: +{
+  "description": "出発バス停名（乗り継ぎ検索モード: to と共に指定・バス→電車→バスも可）",
+  "type": "string"
+}
    • addedInput schema / properties / language
      Added value: +{
+  "description": "応答言語の強制指定（省略時はバス停名から自動判定）",
+  "enum": [
+    "ja",
+    "en",
+    "zh"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / to
      Added value: +{
+  "description": "到着バス停名（乗り継ぎ検索モード: from と共に指定）",
+  "type": "string"
+}
    • addedInput schema / properties / vehicle
      Added value: +{
+  "description": "優先する乗り物（乗り継ぎ検索モードのみ）。bus=バス優先, train=電車優先, community_bus=コミュニティバス優先, ferry=水上バス優先, any=自動（最短）。指定乗り物が極端に遠回りになる場合は better_alternative でより良い経路を進言。",
+  "enum": [
+    "bus",
+    "train",
+    "community_bus",
+    "ferry",
+    "any"
+  ],
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[]
  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 readOnly, idempotent, openWorld, non-destructive, so safety is covered. The description adds meaningful result context (ノンステップバス情報... inclusion) and the language-forcing behavior beyond what annotations state, though it omits any error/empty-input behavior for a tool with zero required params.

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?

Three compact sentences with the primary capability front-loaded before mode and language notes. Emoji are decorative but the content is dense and non-repetitive, so almost every clause earns its place.

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?

All five params are optional and no output schema exists, yet the description doesn't clarify what a no-parameter call returns or how empty/ambiguous input is handled. It covers modes, no-step info, and language, but leaves the zero-input case and result shape underspecified.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds value by explicitly pairing from+to as the transfer mode trigger and confirming the ja/en/zh language override. This meaningfully reinforces parameter usage beyond the raw schema.

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: searches bus stops/route systems and explores bus→train→bus transfer routes via from+to, matching the three implicit modes. It distinguishes three query modes but never names the sibling search_route/search_ferry, so an agent can't fully separate overlapping routing tools from the text alone.

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 mode selection is implied through parameters ('from+to で...乗り継ぎ' vs 'バス停名で検索モード'), which gives usable guidance. However there is no explicit when-to-use/when-not versus search_route or search_ferry, so alternatives must be inferred from schemas.

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