Gachi Data API — Japan Station & Accessibility Data
Server Details
Deep, obscure Japanese station, accessibility & hazard data for AI agents. English-first.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- eng213035/gachi-data-api
- GitHub Stars
- 1
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.
Tool Definition Quality
Average 4.5/5 across 9 of 9 tools scored.
Tools are mostly distinct, but get_municipality_context and get_station_context both return municipality data (one by code/name, one by station) which could cause confusion. Similarly, get_public_toilet_by_city and get_toilet_by_station both deal with toilets but have different scopes. Descriptions help disambiguate.
All tool names follow a consistent verb_noun pattern in snake_case, with clear prefixes like get_ and a specific resource. Even ping fits as a common health check name. No mixing of conventions.
9 tools is well-scoped for a Japan station and accessibility API. Each tool covers a distinct aspect: alerts, municipality/station context, hazards, toilets, train status, and health check. Not too few or too many.
The set covers core operations for station and accessibility data. Minor gaps exist, such as station facilities beyond toilets or more granular accessibility features, but the main use cases are addressed.
Available Tools
9 toolsget_active_alertsARead-onlyIdempotentInspect
Live 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, idempotentHint, destructiveHint=false. The description adds critical behavioral context: it is a 'relay of official facts — not a warning issued by this service, not a life-safety system.' This is valuable beyond annotations. No contradiction.
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 relatively long but well-structured: what it does, what it's not, coverage details, optional filter, disclaimer. Every sentence adds value, though it could be slightly more concise.
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 does not need to explain return values. It covers the data types (level, area, summary, time), filtering, and source. It is complete for an information retrieval 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 one parameter. The description expands on the 'area' parameter by providing examples (e.g., prefecture code 13 for Tokyo) and mentioning JMA forecast-area codes, adding meaning beyond 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 provides live river flood forecasts and landslide alerts from JMA. It explicitly distinguishes itself from general weather warnings and earthquakes. The verb 'get' with specific resource 'active alerts' is reinforced by the detailed coverage description.
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 includes explicit negative statements about what the tool does NOT cover (general weather warnings and earthquakes). It does not directly name sibling tools as alternatives, but the exclusion is clear and helps guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_municipality_contextARead-onlyIdempotentInspect
Official 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 / 新宿区). |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds transparency by stating 'No scores, no judgment — official values only' and mentioning specific data years (2003–2023) for vacancy, which goes 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 two sentences, front-loading the main purpose and data offerings, then clarifying the input format. Every word adds value; no 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 output schema exists, the description covers all essential aspects: input requirements, available data categories, and behavioral traits. Combined with annotations, it is fully sufficient for an agent to use the tool correctly.
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 100% schema coverage, the description significantly enhances parameter understanding. It provides concrete examples for name_or_code (e.g., 13104, Shinjuku-ku, 新宿区) and lists the exact subset options for the fields parameter (vacancy, ridership, population, hazard, land_price, livability).
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 categories (vacancy, ridership, hazard, etc.). It distinguishes itself from sibling tools that focus on stations, toilets, or 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 when to use the tool (when needing official municipality data) and the input format. It does not explicitly state when not to use it or provide alternatives, but the sibling context implies it's the correct choice for municipality-level queries.
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_cityARead-onlyIdempotentInspect
List 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral info: coverage of 612 municipalities, large cities capped at top 50 results, and acceptance of Japanese names. 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 three sentences, front-loaded with the main action and key details. Every sentence adds value without redundancy or 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?
Given the single parameter, clear annotations, and the existence of an output schema (contextually indicated), the description is fully complete. It covers purpose, input format, coverage limits, and result features.
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 'city' parameter has 100% schema coverage with a description. The tool description adds meaning beyond the schema by specifying input format details (Japanese names, prefecture prefix). This extra context improves usability.
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 with specific flags (wheelchair, baby-seat, ostomate), address, and coordinates. It distinguishes from sibling get_toilet_by_station by focusing on municipal aggregation rather than station-specific lookup.
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 on when to use (to list public toilets) and input format tips (Japanese municipality names, prefix prefecture). It implicitly excludes station-specific queries by offering a sibling tool. However, it does not explicitly mention when not to use or list all alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_station_alertsARead-onlyIdempotentInspect
Live 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). |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds context about being a 'relay of official JMA facts' and 'Live', which is useful but not extensive. 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?
Three sentences, each adding value: purpose, input format, scope, and source. No wasted words. Front-loaded with the core function.
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 has only one parameter, strong annotations, and an output schema (not shown but indicated), the description sufficiently covers input format, scope, and data source. No missing critical info.
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% and the schema property description already states the accepted formats. Description repeats the same info with examples, adding no new semantics. Baseline 3 is appropriate.
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 specifies the tool provides 'Live JMA river flood forecasts and landslide alerts affecting a station's prefecture' and explicitly distinguishes from 'general weather warnings'. It also specifies input format (Japanese/romaji). Clear verb+resource+scope.
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?
Description tells when to use (affecting station's prefecture) and when not to use (NOT general weather warnings). It gives input format guidance but does not explicitly compare to sibling tools like get_active_alerts or get_station_hazard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_station_contextARead-onlyIdempotentInspect
Same 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint false. Description adds context: returns official data, no scores, and input methods. No contradictions. With annotations covering safety, description adds moderate value.
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?
Single sentence packed with essential information: comparison to sibling, input types, data source, and scope. No wasted words, front-loaded with key comparison.
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 output schema exists, description need not explain return values. Covers input options, data source, and sibling relationship. Could mention available fields explicitly, but schema covers it.
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 parameter descriptions. Description restates that station_name can be English/romaji or Japanese, but adds minimal new meaning beyond schema. Baseline 3 is appropriate.
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 explicitly states it returns official municipality data resolved from a station, comparing to get_municipality_context. Input methods are clearly specified (station name or ID). Distinguishes from sibling tools by input resolution and data type.
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?
Clearly explains when to use this tool (when you have station info) versus get_municipality_context (when you have municipality info). Notes official values only, no scores, hinting when not to use. Could be more explicit about alternatives like get_station_hazard for hazard data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_station_hazardARead-onlyIdempotentInspect
Official 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). |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds beyond that: it returns official values as-is without composite scores, explains license restrictions for landslide/tsunami, and notes the live data source from MLIT. No contradiction.
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 a single well-structured paragraph that front-loads the source and function, then lists categories, restrictions, and usage. It is concise for the amount of detail but could be slightly more streamlined.
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 has an output schema (not shown but exists), the description covers input, restrictions (license-restricted categories), data source, and purpose. It provides sufficient context for an agent to understand the tool's role and limitations.
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% and already describes station_name. The description adds clarifying examples (Japanese and romaji names) and reinforces the input format, providing added value 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 specifies that the tool retrieves official disaster-risk categories from MLIT for a Japanese train station, listing specific categories (flood inundation, landform, liquefaction, storm surge) and noting what is not included (landslide, tsunami). This clearly distinguishes it from siblings 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 states it is for research/analytics and not a substitute for official maps or evacuation decisions, providing clear context. However, it does not explicitly compare to alternative tools like get_station_alerts for current alerts, missing some guidance on when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_toilet_by_stationARead-onlyIdempotentInspect
Look 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). |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), it discloses coverage (526 Tokyo stations plus major non-Tokyo stations), data source, and that for major stations it groups toilets by ticket gate. No contradictions 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 concise yet comprehensive, with the core purpose front-loaded. Every sentence adds necessary context without redundancy. Appropriate length for the tool's complexity.
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 complexity (multiple station categories, grouping by operator/gate, output schema exists), the description covers all key aspects: purpose, input, coverage, return structure, and special cases. No gaps apparent.
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 has 100% description coverage for the single parameter 'station'. The description adds value by explaining acceptable formats (Japanese/romaji) and providing examples, going beyond the schema's minimal 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 looks up wheelchair-accessible/multipurpose toilets in train stations, specifies details (floor, gender, equipment, nearest exit), and differentiates from siblings like get_public_toilet_by_city by focusing on stations rather than cities.
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?
It explicitly describes when to use (finding accessible toilets in stations), provides input format guidance (Japanese or romaji for major stations), and implies alternatives for city-level toilets via sibling names. Coverage scope and station types are clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_train_statusARead-onlyIdempotentInspect
Live 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 "新宿". |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by detailing the status enum (normal/delayed/suspended/resumed) and cause text handling, which goes 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 concise (about 3 sentences), front-loaded with the core purpose, and every sentence adds value without redundancy.
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 existence of an output schema (mentioned in context), the description need not explain return values. It adequately covers the input behavior and data source, making it complete for a simple one-parameter 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 description coverage is 100%, but the description adds meaning by specifying that the query accepts both English and Japanese, and provides an example. This enhances the agent's 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 it provides live train service status for Tokyo-area lines, using specific verbs and resources. It distinguishes from siblings like get_station_alerts, get_station_hazard, etc., which target different domains.
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: accepts line or station name in English or Japanese, with an example. It implies usage for checking train status but does not explicitly exclude alternatives or mention when not to use it. However, siblings are distinct, so no strong need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingARead-onlyIdempotentInspect
Connection 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 | |||
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral details: no authentication required, no arguments, lightweight, and what the response contains (server identity, deploy version, etc.). 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 brief yet comprehensive, front-loaded with the core purpose, and every sentence adds meaningful information without redundancy.
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 (no parameters, good annotations, output schema present), the description fully covers purpose, usage, behavioral traits, and return value content. It is complete for an agent to select and invoke correctly.
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 tool has zero parameters, and the schema coverage is 100%. The description implicitly confirms no arguments are needed, which adds marginal value beyond the schema. Baseline for zero parameters is 4.
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's purpose as a connection test/health check for server reachability, and it distinguishes itself from sibling tools by emphasizing that it should be called first.
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 to 'call this first' to confirm server reachability, providing clear usage context. It does not specify when not to use or list alternatives, but given the nature of a ping tool, the guidance is adequate.
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.
Discussions
No comments yet. Be the first to start the discussion!