Skip to main content
Glama

station_search

Read-onlyIdempotent

Discover Japanese train stations by describing what you want around them, in English or Japanese — "朝ラーメンが食べられて車椅子トイレがある駅", "terminal station with late-night ramen", "水害リスクが低くてラーメンが多い駅". Semantic search over 9,035 station profiles (lines/terminal size, ramen density & styles, in-station accessible-toilet equipment, official hazard categories, ridership) with hybrid metadata filters — the filters guarantee the constraint, the embedding ranks by fit. Filter intent in the query text (朝ラー/深夜/おむつ/車椅子/水害リスク低…) is auto-applied (filter_source: inferred); explicit params win. Water-hazard intent (水害/洪水/浸水/高潮…リスク低) expands to flood rank AND storm-surge zone; 液状化/地盤 intent filters on the official liquefaction-tendency category; results carry risk_notes when other official hazard categories are high. Inferred facility filters with partial data coverage (おむつ/車椅子 — Tokyo-only data) BOOST confirmed stations instead of excluding unknowns (see soft_filters); explicit params remain strict. Taste/quality words (うまい, "good food", delicious…) are not evaluated (no review data); ramen ranking reflects shop density and style variety only. name_contains gives exact substring matching on station names (日本語/romaji) when the name itself is the requirement. Coverage notes: toilet stats = Tokyo stations only; ridership = Greater Tokyo operators only; hazard = official MLIT categories relayed as-is, NOT a safety judgment. Role split: station_search finds candidate stations — then get_toilet_by_station / search_ramen / get_station_hazard / get_station_context for detail on one station.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesNatural-language description of the station/area you want (ja/en). Concrete attribute words (朝ラー, wheelchair toilet, terminal, 水害リスク低) match best.
prefNoOptional prefecture filter, Japanese (東京都, 千葉 OK) or romaji (tokyo/osaka). Auto-inferred from the query text when omitted.
limitNoMax results (default 10; max 20, or 300 when name_contains is given — set limit >= name_matches_total for exhaustive name-match coverage).
diaperNoRequire a diaper changing table in station toilets (auto-inferred from おむつ/子連れ…).
ramen_minNoRequire at least this many ramen shops nearby (e.g. 30).
late_ramenNoRequire late-night ramen nearby (auto-inferred from 深夜/late night…).
morning_ramenNoRequire morning-ramen availability nearby (auto-inferred from 朝ラー/morning…).
name_containsNoSubstring filter on the station name (matches both 日本語 name_ja and romaji name, e.g. "谷" or "sakura"). ANDs with other filters; q still ranks the matches. Use for "stations whose name contains X" requests that semantic search cannot guarantee.
flood_rank_maxNoMax official flood inundation-depth rank 0–6 (0 = no assumed inundation; auto-inferred from 水害リスク低/flood-safe…).
accessible_toilet_minNoRequire at least this many in-station accessible toilets (Tokyo stations only; auto-inferred from 車椅子/wheelchair…).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoPresent when the query contains taste/quality words: they are not evaluated (no review data).
countNoResults returned.
notesNoCoverage caveats (toilet stats Tokyo-only, ridership Greater-Tokyo-only).
queryNoEcho of the query.
stationsNoMatching stations, best first: name, pref, similarity, ramen stats, toilet stats, official hazard categories (plus risk_notes when an official hazard category not covered by the filter is high), lines, ridership.
disclaimerNoHazard usage disclaimer.
attributionNoData source(s), license and provenance — an object, or an array of sources.
stats_as_ofNoFreshness of the underlying ramen stats (YYYY-MM-DD).
soft_filtersNoInferred facility filters applied as a score BOOST (confirmed stations get +BOOST on similarity = final_score; unknown/missing never excluded), with coverage note. Present only when active.
filter_sourceNoexplicit / inferred / none — how the filters were chosen.
applied_filtersNoHard metadata filters actually applied (explicit + inferred; includes name_contains when given).
name_matches_totalNoTotal stations whose name matched name_contains (before ranking/limit). Present only in name_contains mode.

TDQS

A5/5.0
Behavior5/5

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

Despite readOnlyHint and idempotentHint annotations, the description adds rich behavioral nuance: auto-inference of filter intent, water-hazard expansion to flood rank AND storm-surge zone, partial-data soft filtering (BOOST confirmed instead of exclude), and explicit statements that hazard categories are relayed as-is, not a safety judgment.

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?

Lengthy but every sentence adds value. Structured clearly: core purpose with examples, edge-case handling, coverage caveats, then role split. Front-loaded with the primary use case.

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?

For a tool with 10 parameters, hybrid search, auto-inference, and multiple data caveats, the description is comprehensive. Output schema exists, so return value explanation is not needed. Covers soft-filter behavior, data coverage, and tool relationships.

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

Parameters5/5

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

Schema description coverage is 100%, so baseline is 3. But the description elevates meaning by explaining auto-inference behavior ('explicit params win'), name_contains substring matching details, and limit semantics ('set limit >= name_matches_total for exhaustive name-match coverage').

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 opens with 'Discover Japanese train stations by describing what you want around them' — a specific verb, resource, and mechanism. It distinguishes from sibling detail tools via 'Role split: station_search finds candidate stations — then get_toilet_by_station / search_ramen / get_station_hazard / get_station_context for detail on one station.'

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?

Explicitly states when to use the tool: for candidate discovery, then delegates to specific sibling tools for detail. Also covers when to use name_contains ('when the name itself is the requirement') and warns about limitations (taste words not evaluated, coverage notes).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation2/5

Several tools have overlapping purposes: get_active_alerts and get_station_alerts both return JMA flood/landslide alerts, differing only by input type. Similarly, get_municipality_context and get_station_context expose the same underlying data via different resolvers, and get_station_context already includes hazard categories that get_station_hazard duplicates in more detail. These overlaps make it difficult for an agent to know which tool to select for a given query.

Naming Consistency4/5

Most tools follow a clear 'get_' prefix (e.g., get_toilet_by_station, get_train_status), which is consistent. However, 'station_search' and 'ping' break the pattern, and the role-split text references a non-existent 'search_ramen' tool. The dominant convention is clear, but the exceptions introduce minor inconsistency.

Tool Count4/5

With 10 tools, the count is within a reasonable range for the server's broad scope (station info, toilet accessibility, hazards, alerts, train status). However, the redundancy between municipality_context/station_context and actives_alerts/station_alerts means not every tool earns a unique place, making the set slightly over-provisioned. Still, it is not excessively large.

Completeness3/5

The server covers the main info-retrieval needs for toilets, station hazards, alerts, and train status. However, station_search explicitly tells agents to 'search_ramen' for ramen details, yet that tool is not provided, creating a clear dead end. Also, the domain is broader than the server name suggests, and some peripheral data (e.g., detailed ramen profiles) is only partially surfaced.

Resources