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

鉄道駅LOD MCPサーバー

by uedayou
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

駅・路線の位置情報を取得(駅=ポイント / 路線=ライン)

get_railway_geometry

Retrieve a specified Japanese railway station or line as GeoJSON Feature—Point for stations, MultiLineString for lines—with optional coordinate simplification for lightweight line geometry.

Instructions

鉄道駅LOD から、指定した駅または路線を GeoJSON Feature として取得する。駅は代表点(Point、geo:lat/long)、路線は形状(MultiLineString、分岐線を含む)。.json(RDF/JSON)を取得してクライアント側で GeoJSON に変換する。駅の properties は uri・name・operator(運営会社)・belongsToLine(所属路線)・lineColor・transferStations(乗換駅、ある駅のみ)・adjacentStations(隣接駅、ある駅のみ)、路線の properties は uri・name・operator・lineColor・publishedLengthKm(営業キロ)。乗降客数は含まない(get_station_passengers を使う)。戻り値の geometry は標準的な GeoJSON(RFC 7946)で、座標は [経度, 緯度] の順。ポリゴン(面)は存在しない。

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": {
      "address": "<address>"
    },
    "name": "get_railway_geometry"
  }
}

Input Schema

NameRequiredDescriptionDefault
addressYesエンティティのラベル、または URI。jrslod では「会社名/路線名」(路線)/「会社名/路線名/駅名」(駅)/完全 URI。事業者名の別名(JR東日本 等)や「〜本線」⇔「〜線」の揺れは自動補完を試みる。駅はポイント、路線は MultiLineString で返る。複数まとめて取得するときは get_railway_geometries を使う。
simplifyNoラインの座標点数を間引くレベル(既定 'none' = 間引かない)。長大路線(数千点)を軽量に扱いたいときに 'low'/'medium' を検討する。'high' は形状の崩れが大きい。駅(ポイント)には効果がない。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so: it discloses the underlying data path (fetching .json RDF/JSON and converting to GeoJSON client-side), the exact properties returned for stations (uri, name, operator, belongsToLine, lineColor, transferStations, adjacentStations) and lines (publishedLengthKm), and that transfers/adjacency exist only for some stations. It also pins down standards conformance and coordinate order (RFC 7946, [経度, 緯度]), which prevents a common axis-swap error.

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?

Four dense sentences, front-loaded with the core action, then shape, then transformation, then property inventory and exclusions. Nothing is redundant with the title and no sentence is filler.

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

Completeness5/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 return values itself — and it does, enumerating both geometry types, properties per type, and coordinate ordering. For a two-parameter read tool with no annotations, nothing an agent needs in order to call it and interpret the result is missing.

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 both parameters — the address label/URI form with its auto-completion behavior and the simplify enum levels — are already fully documented in the schema. The description adds return-side meaning but little parameter-specific semantics beyond what the schema already states, so the baseline 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?

The description names a specific verb and resource (「鉄道駅LOD から、指定した駅または路線を GeoJSON Feature として取得する」) and immediately disambiguates the two result shapes: station = Point with geo:lat/long, line = MultiLineString including branch lines. An agent can distinguish the singular-fetch behavior from multi-fetch and passenger sibling tools without opening any 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 gives clear routing for one case — passenger counts are not here, use get_station_passengers — and states a scope boundary (ポリゴン(面)は存在しない). It does not, however, say in the description when to prefer this over get_railway_geometries for multiple entities; that routing only appears in the schema's address parameter.

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