Structured data on wheelchair-accessible & public toilets across Japan for AI agents and travel/accessibility apps. 526 Tokyo stations (each mapped to its nearest station exit) + 612 municipalities. Station names accept Japanese or romaji. Free tier with API key.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 10 of 10 tools scored.
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.
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.
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.
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.
get_active_alertsALive river flood forecasts and landslide alerts for Japan (JMA official). NOT general weather warnings (storm/heavy rain/snow) and NOT earthquakes. Covers JMA 指定河川洪水予報 (river flood forecast, levels 2–5) and 土砂災害警戒情報 (landslide warning), each with level, affected area, official summary and issue time. Optional area filters by 2-digit prefecture code (e.g. 13 = Tokyo) or a JMA forecast-area code. Relay of official facts — not a warning issued by this service, not a life-safety system.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Optional prefecture code (01–47, e.g. 13 = Tokyo) or JMA forecast-area code. |
| Name | Required | Description |
|---|---|---|
| count | No | Number of active alerts. |
| stale | No | True if the snapshot is stale. |
| alerts | No | Active JMA river-flood / landslide alerts with level, area, summary, issue time. |
| source | No | Source label. |
| coverage | No | What this feed covers — string or array of categories. |
| disclaimer | No | Relay disclaimer (not a warning issued by this service). |
| fetched_at | No | When the snapshot was fetched. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, etc.), the description adds critical behavioral context: 'Relay of official facts — not a warning issued by this service, not a life-safety system,' clarifying the tool's role and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear front-loading of purpose and necessary caveats. It could be slightly more concise but remains readable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers what the tool returns (levels, area, summary, time) and the optional filtering. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'area' is fully described in both schema and tool description with examples and acceptable formats (prefecture code or JMA forecast-area code), adding clear meaning beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Live river flood forecasts and landslide alerts for Japan (JMA official)' and explicitly distinguishes itself from general weather warnings and earthquakes, making the purpose precise and differentiating from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use (for specific JMA alerts) and what not to use it for (general weather, earthquakes). It also notes the optional area filter. However, it does not explicitly contrast with sibling tools beyond the 'NOT' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_municipality_contextAOfficial Japanese government data for any municipality, one call — housing vacancy (2003–2023), nearest-station ridership trend, hazard categories, land prices, livability counts. No scores, no judgment — official values only. Accepts a 5-digit municipality code (13104) or an exact name (Shinjuku-ku / 新宿区).
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional comma-separated subset: vacancy,ridership,population,hazard,land_price,livability. | |
| name_or_code | Yes | 5-digit 全国地方公共団体コード (e.g. 13104) or exact municipality name (Shinjuku-ku / 新宿区). |
| Name | Required | Description |
|---|---|---|
| hazard | No | Hazard categories. |
| vacancy | No | Housing-vacancy counts (2003–2023). |
| ridership | No | Nearest-station ridership trend. |
| land_price | No | Published land prices near the centroid. |
| livability | No | Livability counts. |
| population | No | Population / future estimate. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
| municipality | No | Resolved municipality + code. |
| hazard_disclaimer | No | Hazard usage disclaimer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly and idempotent. The description adds context: data is official, no scores/judgment, and 'one call' implies completeness. No contradictions, and additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. It front-loads the purpose and data types, then gives input details. No superfluous words – every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers the necessary scope: data categories, time range, input format. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully documented in the schema. The description adds value with concrete examples (13104, Shinjuku-ku) and lists the field options, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns official Japanese government data for municipalities, listing specific data fields (housing vacancy, ridership, hazard, land prices, livability). It differentiates from sibling tools like get_station_context which focus on station-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when municipal-level official data is needed and provides input format guidance ('5-digit code or exact name'). However, it does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_public_toilet_by_cityAList public toilets in a Japanese municipality, with wheelchair / baby-seat / ostomate flags, address and coordinates. Covers 612 municipalities nationwide (large cities capped at the top 50 results). Municipality names accept Japanese (e.g. 那覇市, 渋谷区); prefixing the prefecture improves accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Municipality name in Japanese (e.g. 那覇市, 渋谷区, 上天草市). Prefix the prefecture for accuracy. |
| Name | Required | Description |
|---|---|---|
| city | No | Resolved municipality. |
| note | No | Human-readable note. |
| count | No | Toilets returned. |
| error | No | Set when nothing was found. |
| toilets | No | Public toilets with wheelchair / baby-seat / ostomate flags, address and coordinates. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds behavioral details: coverage of 612 municipalities, a 50-result cap for large cities, and accuracy tips for municipality names. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then key limitations and usage tips. Every sentence adds value with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, output schema present, annotations cover safety), the description covers purpose, scope, limitations, and input guidance adequately. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter and 100% schema coverage, the description adds significant value by specifying accepted formats (Japanese names) and advising to prefix prefecture for accuracy, which the schema description does not fully convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists public toilets in a Japanese municipality, specifying the output includes wheelchair, baby-seat, and ostomate flags, address, and coordinates. It distinguishes itself from the sibling 'get_toilet_by_station' by focusing on city-level filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides good context on when to use (for Japanese municipalities) and gives practical tips for parameter input (Japanese names, prefixing prefecture). However, it does not explicitly mention when not to use or name alternatives like 'get_toilet_by_station'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_station_alertsALive JMA river flood forecasts and landslide alerts affecting a station's prefecture — NOT general weather warnings. Ask by station name in Japanese (新宿) or romaji (Shinjuku). Prefecture-level match (station master is Greater Tokyo). Relay of official JMA facts.
| Name | Required | Description | Default |
|---|---|---|---|
| station_name | Yes | Station name in Japanese (新宿) or romaji (Shinjuku). |
| Name | Required | Description |
|---|---|---|
| count | No | Number of alerts. |
| stale | No | True if stale. |
| alerts | No | JMA alerts affecting the prefecture. |
| station | No | Resolved station. |
| disclaimer | No | Relay disclaimer. |
| fetched_at | No | When the snapshot was fetched. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds that it is a 'relay of official JMA facts' and that the match is prefecture-level. This adds some context but does not disclose behavioral traits beyond what annotations provide. Thus, baseline 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences and a clarifying note. Front-loaded with key purpose, then input specifications. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, full schema coverage, and an output schema present, the description provides sufficient context: it explains what alerts are returned (floods and landslides), the matching method (prefecture-level), and a real-world example ('station master is Greater Tokyo'). Complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the schema already documents it. The description adds value by specifying the accepted formats ('Japanese (新宿) or romaji (Shinjuku)') and explaining the prefecture-level match. This goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Live JMA river flood forecasts and landslide alerts' and explicitly distinguishes from 'general weather warnings'. It specifies input format (station name in Japanese or romaji) and scope (prefecture-level). This is a specific verb+resource with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when NOT to use it (not for general weather warnings) and provides context for use ('Ask by station name... Prefecture-level match'). However, it does not explicitly mention alternatives like get_active_alerts or get_station_hazard, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_station_contextASame official municipality data as get_municipality_context, resolved from a station: pass a station name (Shinjuku / 新宿 / Musashi-Kosugi) or a Japan Station Master station_id (e.g. st_00001), and it returns the context for that station's municipality. Official values only — no scores.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional comma-separated subset: vacancy,ridership,population,hazard,land_price,livability. | |
| station_id | No | Japan Station Master station_id (e.g. st_00001). Alternative to station_name. | |
| station_name | No | Station name in English/romaji (Shinjuku) or Japanese (新宿). Provide this or station_id. |
| Name | Required | Description |
|---|---|---|
| hazard | No | Hazard categories. |
| station | No | Resolved station. |
| vacancy | No | Housing-vacancy counts. |
| ridership | No | Ridership trend. |
| land_price | No | Land prices near the centroid. |
| livability | No | Livability counts. |
| population | No | Population / future estimate. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
| municipality | No | Municipality + code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds that it provides 'official values only — no scores', which enriches understanding of returns without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and reference to sibling. No extraneous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (as per context signals), description need not detail return values. It covers resolution logic, input formats, and data source. Complete for a simple lookup tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already describes all parameters. Description adds minor clarification: station_name can be English/romaji or Japanese, and station_id format example (e.g. st_00001). Baseline 3, slight value but not significantly more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns the same municipality data as get_municipality_context but resolved from a station. Specifies input types (station name or ID) and output scope (official values only, no scores). Distinct from siblings like get_municipality_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes how to use: pass a station name or station_id. References the sibling get_municipality_context as an alternative, implying this is the station-based version. Lacks explicit when-not-to-use guidance but sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_station_hazardAOfficial disaster-risk categories at a Japanese train station, relayed live from the MLIT 不動産情報ライブラリ (Real Estate Information Library): flood inundation-depth rank, landform / liquefaction classification, and storm-surge inundation-area presence (landslide & tsunami are license-restricted and return available:false with a link to the official maps). Returns the official values/categories as-is — no composite score, no judgment. Accepts a station name in Japanese (新宿, 武蔵小杉) or romaji (Shinjuku, Musashi-Kosugi). For research/analytics; NOT a substitute for official government hazard maps or evacuation decisions.
| Name | Required | Description | Default |
|---|---|---|---|
| station_name | Yes | Station name in Japanese (新宿, 武蔵小杉) or romaji (Shinjuku, Musashi-Kosugi). |
| Name | Required | Description |
|---|---|---|
| hazard | No | Official categories: flood inundation depth, landform/liquefaction, storm-surge. |
| station | No | Resolved station + coordinates. |
| disclaimer | No | Usage disclaimer (not a substitute for official maps). |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: returns official values/categories as-is (no composite score, no judgment), indicates that landslide and tsunami data are license-restricted and return 'available:false' with a link. Annotations already include readOnlyHint, idempotentHint, etc., but the description adds valuable context about data availability and output nature. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence carries essential information: source, categories, restrictions, input format, disclaimer. It is front-loaded with the primary purpose. While not extremely concise, it avoids redundancy and is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (multiple hazard categories, license restrictions, special return behavior), the description is complete: it covers data source, included/excluded categories, input format, output behavior, and appropriate usage disclaimer. The existence of an output schema (not shown) further supports completeness. An agent can confidently select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for station_name. The description adds value by clarifying that the station name can be in Japanese or romaji, and provides examples (新宿, 武蔵小杉, Shinjuku, Musashi-Kosugi). This goes beyond the schema's generic description, aiding correct input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves official disaster-risk categories for a Japanese train station, specifying the data source (MLIT Real Estate Information Library), the categories included (flood inundation-depth rank, landform/liquefaction classification, storm-surge inundation-area presence), and what is excluded (landslide and tsunami). The verb 'get' and resource 'station hazard' are precise. This distinguishes it from sibling tools like get_station_alerts or get_station_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: 'For research/analytics; NOT a substitute for official government hazard maps or evacuation decisions.' It implies when to use (analytics, not emergency) and notes license restrictions for some categories. However, it does not explicitly contrast with alternative sibling tools or state when to prefer this over get_station_alerts, etc. Still, the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_toilet_by_stationALook up wheelchair-accessible / multipurpose toilets inside a train station, including floor, gender, equipment (wheelchair, ostomate, diaper table) and the nearest exit. Covers 526 Tokyo stations (Tokyo Bureau of Social Welfare data). Major stations outside Tokyo (Yokohama, Kawasaki, Omiya, Chiba, Fujisawa, Shin-Yokohama…) return an in-station layer that groups accessible toilets by ticket gate — inside vs outside — per railway operator. Accepts Japanese (新宿, 横浜) or romaji (Shinjuku, Yokohama) for major stations.
| Name | Required | Description | Default |
|---|---|---|---|
| station | Yes | Station name in Japanese (新宿, 渋谷) or romaji for major stations (Shinjuku, Shibuya, Kita-Senju). |
| Name | Required | Description |
|---|---|---|
| note | No | Human-readable note. |
| count | No | Toilets returned. |
| error | No | Set when nothing was found. |
| layer | No | Data layer (e.g. in_station_gate). |
| source | No | Data source label. |
| station | No | Resolved station (English). |
| toilets | No | Accessible toilets with floor, gender, equipment and nearest exit. |
| station_ja | No | Station name in Japanese. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
| station_name_source | No | How the name was resolved. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true; the description adds behavioral context: data source, coverage limits, and grouping by ticket gate for major stations. No contradictions, and description adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding essential information: purpose and attributes, coverage details, input format and special behavior. No redundancy or filler; well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary context: data source, geographic scope, input variations, and special behavior for major stations. An output schema exists, so return values need not be explained. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'station' parameter is described in the schema with basic input guidance. The description significantly enhances this by providing examples (新宿, Shinjuku), clarifying that major stations outside Tokyo return a grouped layer, and noting that romaji works only for major stations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up wheelchair-accessible toilets in train stations with specific attributes (floor, gender, equipment, nearest exit) and coverage (526 Tokyo stations, major stations outside Tokyo). It distinguishes from sibling 'get_public_toilet_by_city' by focusing on station-specific toilets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (looking up station toilets) and specifies input formats (Japanese or romaji). It does not explicitly exclude cases or mention alternatives, but the context is sufficient for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_train_statusALive train service status for Tokyo-area lines — delays, suspensions, resumptions. Ask 'is the Yamanote Line running?' by line or station name, English or Japanese. Status enum: normal / delayed / suspended / resumed. Cause text relayed from ODPT (English summary for known patterns, else original text + null). Data via ODPT (CC BY 4.0).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Line or station name (English or Japanese), e.g. "Yamanote" or "新宿". |
| Name | Required | Description |
|---|---|---|
| count | No | Number of lines. |
| lines | No | Per-line status: normal / delayed / suspended / resumed, with cause. |
| query | No | Echo of the query. |
| stale | No | True if stale. |
| fetched_at | No | When the snapshot was fetched. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive. The description adds value by explaining the cause text relay behavior (English summary vs original text) and data attribution to ODPT (CC BY 4.0). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, each providing essential information: purpose, usage example, status enum, and data source. No redundant or missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema presence, the description adequately covers the main features (live status, cause text, data source). A small gap: it doesn't mention if multiple results are returned or pagination, but this is minor for a status query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds examples ('Yamanote', '新宿') and clarifies that the query can be in English or Japanese, enhancing the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live train service status for Tokyo-area lines, including delays, suspensions, and resumptions. It gives specific examples of queries and distinguishes it from sibling tools like get_station_alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool (by line or station name, in English or Japanese) and mentions the status enum and cause text. However, it does not explicitly contrast when to use this tool vs siblings like get_station_alerts or get_active_alerts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingAConnection test / health check — call this first to confirm the server is reachable. Returns server identity, deploy version, tool count, station coverage, and the update times of the realtime layers (JMA alerts, train status) so you can confirm freshness, not just liveness. No auth, no arguments, lightweight.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tools | No | Number of tools exposed by this server. |
| server | No | Server name. |
| status | No | Always "ok" when the server is reachable. |
| version | No | Deploy version. |
| realtime_layers | No | Update times of the realtime KV snapshots (a field is omitted if that layer is unavailable). |
| stations_covered | No | Stations with accessible-toilet data. |
| rate_limit_noauth | No | No-auth rate limit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable detail on what specific data is returned (server identity, deploy version, tool count, station coverage, update times), confirming freshness beyond liveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states purpose, the second details return values. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, comprehensive annotations, and an output schema (not shown but described), the description fully covers the tool's behavior and return values. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100% (empty schema). The description does not need to add parameter meaning; it is complete as-is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a connection test/health check with specific verb and resource. It distinguishes from sibling tools by emphasizing it is a lightweight, preliminary call to check server reachability before using other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'call this first' and notes 'no auth, no arguments, lightweight.' While it provides clear context for when to use, it does not explicitly list alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
station_searchADiscover 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.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Natural-language description of the station/area you want (ja/en). Concrete attribute words (朝ラー, wheelchair toilet, terminal, 水害リスク低) match best. | |
| pref | No | Optional prefecture filter, Japanese (東京都, 千葉 OK) or romaji (tokyo/osaka). Auto-inferred from the query text when omitted. | |
| limit | No | Max results (default 10; max 20, or 300 when name_contains is given — set limit >= name_matches_total for exhaustive name-match coverage). | |
| diaper | No | Require a diaper changing table in station toilets (auto-inferred from おむつ/子連れ…). | |
| ramen_min | No | Require at least this many ramen shops nearby (e.g. 30). | |
| late_ramen | No | Require late-night ramen nearby (auto-inferred from 深夜/late night…). | |
| morning_ramen | No | Require morning-ramen availability nearby (auto-inferred from 朝ラー/morning…). | |
| name_contains | No | Substring 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_max | No | Max official flood inundation-depth rank 0–6 (0 = no assumed inundation; auto-inferred from 水害リスク低/flood-safe…). | |
| accessible_toilet_min | No | Require at least this many in-station accessible toilets (Tokyo stations only; auto-inferred from 車椅子/wheelchair…). |
| Name | Required | Description |
|---|---|---|
| note | No | Present when the query contains taste/quality words: they are not evaluated (no review data). |
| count | No | Results returned. |
| notes | No | Coverage caveats (toilet stats Tokyo-only, ridership Greater-Tokyo-only). |
| query | No | Echo of the query. |
| stations | No | Matching 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. |
| disclaimer | No | Hazard usage disclaimer. |
| attribution | No | Data source(s), license and provenance — an object, or an array of sources. |
| stats_as_of | No | Freshness of the underlying ramen stats (YYYY-MM-DD). |
| soft_filters | No | Inferred 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_source | No | explicit / inferred / none — how the filters were chosen. |
| applied_filters | No | Hard metadata filters actually applied (explicit + inferred; includes name_contains when given). |
| name_matches_total | No | Total stations whose name matched name_contains (before ranking/limit). Present only in name_contains mode. |
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.
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.
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.
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.
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.
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
