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

鉄道駅LOD MCPサーバー

by uedayou
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

複数の駅・路線の位置情報をまとめて取得(地図化はこちら)

get_railway_geometries

Retrieve up to 50 railway stations or lines by label or URI and return them as one GeoJSON FeatureCollection, excluding unresolved items and noting them separately.

Instructions

複数の駅・路線をまとめて取得し、1 つの GeoJSON FeatureCollection として返す(最大 50 件)。路線網や駅群を地図に表示する場合はこれを使う。一部が解決できなくても全体は失敗にせず、features から除外して unresolved として注記する。

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": {
      "addresses": "<addresses>"
    },
    "name": "get_railway_geometries"
  }
}

Input Schema

NameRequiredDescriptionDefault
simplifyNoラインの座標点数を間引くレベル(既定 'none')。全 feature をまとめてトポロジー(共有頂点)を保持したまま簡略化する。長大路線を多数まとめるときに 'low'/'medium' を検討。'high' は形状の崩れが大きい。
addressesYesエンティティのラベル or URI の配列(最大50件)。解決ルールは get_railway_geometry と共通。路線網や駅群を地図に表示するときに使う。一部が解決できなくても全体は失敗にせず、features から除外して unresolved として注記する。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations at all, the description carries the full burden, and it does disclose the most important non-obvious behavior: partial failures do not abort the call, unresolvable items are dropped from 'features' and reported under 'unresolved'. The 50-item ceiling and GeoJSON return type are also stated. It still says nothing about authentication, rate limits, or ordering of the returned features.

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 sentences, front-loaded with the retrieval action and return type, then the usage routing, then the failure semantics. The 'unresolved' clause is repeated verbatim in the 'addresses' schema description, a minor redundancy, but no sentence is wasted.

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?

For a two-parameter read tool with full schema coverage this is nearly sufficient: purpose, map-display routing, batching limit, and partial-failure semantics are all covered, and no output schema exists to require return-value explanation. The only thin spot is the absence of any prose about the simplify option or ordering.

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 'addresses' and 'simplify' are already documented in the schema, including the enumeration and the shared resolution rules. The description adds no meaning beyond that — it never mentions the simplify trade-off in prose, so it does not compensate for anything nor exceed the baseline.

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?

The description states a specific verb and resource ('複数の駅・路線をまとめて取得し') plus the concrete return form ('1 つの GeoJSON FeatureCollection'), which separates it in practice from the single-entity sibling get_railway_geometry. The map-display framing ('路線網や駅群を地図に表示する場合はこれを使う') reinforces the plurality distinction, though the competing tool is never named outright.

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 a clear selecting condition: use this when you want to render a line network or station group on a map. What is missing is the negative case — no explicit statement telling the agent to prefer get_railway_geometry for a single station/line, or save_railway_geometries_to_file when persistence rather than mapping is required.

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