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

鉄道駅LOD MCPサーバー

by uedayou
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

鉄道路線の全長(実測 + 営業キロ)を算出

get_railway_line_lengths

Calculate measured total length in kilometers for one or more Japanese railway lines from route geometries, and return published operating kilometers for comparison.

Instructions

1 本以上の鉄道路線について、路線形状(ポリライン)から実測した全長(km)を算出し、あわせて公表営業キロ(wdt:P2043、約 87% の路線が保持)を返す。複数路線の比較にも使える。実測長は国土数値情報 N02 の軌道中心線の幾何長で、(1) 事業者分割された路線(東海道線・山陽線・大糸線 等)ではその事業者の担当区間のみ、(2) 支線・貨物短絡線を含む、(3) 球近似の積算、という理由で鉄道各社の営業キロと数%〜数十%ずれる。乖離が大きい場合は lengthNote(operator-segment / includes-branches)で理由を示す。駅(ポイント)は対象外。時刻表・所要時間・運賃は扱わない。

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": {
      "routes": "<routes>"
    },
    "name": "get_railway_line_lengths"
  }
}

Input Schema

NameRequiredDescriptionDefault
routesYes路線の URI または「会社名/路線名」ラベルの配列(最大50件、1件でも可)。駅(ポイント)や形状を持たないエンティティは全長を算出できず unresolved として報告する。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.1/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 does so well: it discloses that the measured value derives from N02 track-centreline geometry, covers only the operator's own segment on split lines, includes branches and freight short links, uses spherical approximation, and can deviate from official figures by a few to tens of percent. It also explains that large deviations are flagged via lengthNote (operator-segment / includes-branches) and that unresolvable entities are reported rather than failing. Remaining gaps are minor, e.g. precision/rounding of returned values and whether lengthNote is always present.

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 core capability and the measured-plus-official dual output are front-loaded in the first sentence, followed by scope exclusions. It is dense with parentheticals (examples of split lines, property IDs, note tokens), which costs some readability but each clause carries substantive information.

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?

There is no output schema, so the description must describe returns, and it does: measured km, published operating km, and a lengthNote explaining large deviations. For a one-parameter tool this is nearly complete; only response-level details such as units/rounding of the operating figure and the handling of routes missing wdt:P2043 are left implicit.

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% for the single 'routes' array, and the schema already documents the URI-or-'company/line' label form, the 1-50 limit, and unresolved reporting. The description adds only the notion that multiple routes can be compared, which is usage framing rather than new parameter meaning, so the baseline of 3 applies.

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?

States a specific verb and resource: computes measured total length (km) from line polyline geometry and also returns published operating kilometres (wdt:P2043, present for ~87% of lines). It explicitly excludes stations (points) and timetables/travel time/fares, so an agent can distinguish it from get_railway_geometries or list_stations_on_line without opening another schema.

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?

It states the tool supports comparing multiple routes in one call and rules out station entities and timetable/fare questions, which gives clear usage context. It does not name a concrete alternative tool for the 'I need the shape/geometry' case, so the routing guidance stops short of explicit when-not-use-a-sibling instructions.

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