Skip to main content
Glama
Sign In
鉄道駅LOD MCPサーバー

鉄道駅LOD MCPサーバー

by uedayou
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

駅ネットワーク上の経路(乗換/駅数最小)

find_rail_network_path

Finds a railway route skeleton between two Japanese stations from static adjacency and transfer data, returning lines and waypoints with evidence notes; it excludes timetables and travel times.

Instructions

鉄道駅LOD の静的な路線図(隣接駅 wdt:P197・乗換駅 wdt:P833)上を探索し、2 駅間の経路の骨格を返す。時刻表・所要時間・最速経路・列車種別・直通運転は一切考慮しない。直通運転のある区間(例: 副都心線〜東急東横線、上野東京ライン)では乗り換え回数を過大に数える。運行系統(湘南新宿ライン・快速など)は路線として存在しない。長距離では地理的に不自然な経路を返すことがある。結果は「どの路線でどこを経由するか」の目安であり、経路案内サービスの代替ではない。各経路には信頼性の注記(reliability)と検証用の元データ URL(evidence)が付く。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "from": "<from>",
      "to": "<to>"
    },
    "name": "find_rail_network_path"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYes到着駅の駅名 or URI(例: '浅草')。
fromYes出発駅の駅名 or URI(例: '渋谷')。
optimizeNofewest_transfers=乗換回数最小(既定)/ fewest_stops=経由駅数最小(乗換は駅4つ相当のペナルティ)。`fastest`(最速)は時刻表が無いため提供しない。fewest_transfers

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses substantial behavioral context: it operates on a static graph, overcounts transfers for through services, omits operating patterns like Shonan-Shinjuku Line or rapid services, and may return geographically unnatural long-distance routes. It also mentions that each route carries a reliability note and evidence source-data URL. It does not describe the output shape in detail (e.g., how the route skeleton is structured), which keeps it from a 5.

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 front-loaded with the core purpose and then systematically lists limitations. Every sentence earns its place by either defining scope or preventing a foreseeable misuse, and there is no redundant restatement of the tool name.

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?

Given the absence of annotations and an output schema, the description is quite complete about behavioral limitations and reliability/evidence metadata. It stops short of describing the route output structure (e.g., whether it returns a sequence of lines, stations, or segments), which would help an agent know exactly what to expect.

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 input schema already documents from, to, and the optimize enum. The description adds no parameter-specific semantics beyond what the schema provides; it does not clarify input formats, edge cases for station names versus URIs, or how optimize interacts with the graph search.

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 states a specific verb and resource: it searches a static railway-station graph (adjacent stations wdt:P197, transfer stations wdt:P833) and returns the skeleton of a route between two stations. It distinguishes itself from timetable-based routing and names the exact graph predicates used, so an agent can tell it apart from sibling tools that deal with stations, lines, or geometries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-not-to-use guidance: it does not consider timetables, travel time, fastest routes, train types, or through services, and it is not a substitute for a route-guidance service. It also explains the intended use — a rough guide to which lines and via-points are involved — and warns that through-running and operating patterns are not modeled, which is the key selection criterion versus real routing tools.

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