Gachi Data API — Japan Station & Accessibility Data

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

No annotations provided, so description carries full burden. Discloses important behavioral traits: it's a relay of official facts, not a warning issued by this service, not a life-safety system. Missing details like update frequency or authentication, but adequate for a read-only data retrieval tool.

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 concise sentences with no fluff. Front-loaded with main purpose, then details and limitations. 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?

No output schema, but description explains what output contains (level, affected area, official summary, issue time). Includes disclaimers about life-safety. Complete for a single-parameter read-only tool with no output schema.

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?

Single parameter 'area' has 100% schema coverage. Description adds example (13 = Tokyo) and clarifies it can be prefecture code or JMA area code, but largely echoes schema description. Baseline 3 applies as schema already documents param well.

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 provides live river flood forecasts and landslide alerts for Japan (JMA official). Uses specific verb 'get' and resource 'active alerts', and explicitly distinguishes from general weather warnings and earthquakes. Covers specific JMA systems with precise 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?

Explicitly states when to use (for river flood and landslide alerts) and what NOT to use it for (general weather, earthquakes). Mentions optional area filtering. Lacks explicit comparison to sibling tools like get_station_alerts, but scope is clear enough to infer differentiation.

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

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

No annotations provided, so description carries full burden. It clarifies data is 'official values only' with no scoring, implying read-only behavior, but lacks details on rate limits or auth needs.

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 key outputs, then input guidelines. 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?

Given simple parameters and no output schema, description fully covers input, data types, and time ranges. No missing critical information.

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 description adds meaningful context: explains name_or_code accepts 5-digit codes or exact names (including Japanese), and lists possible field values for the optional parameter.

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 retrieves official Japanese government data for municipalities, listing specific data types (vacancy, ridership, etc.) and distinguishes from sibling tools focused on stations 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?

Description explains input format (code or exact name) and that data is official, but does not explicitly state when to use this tool over siblings or when not to use it.

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

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

Discloses important behavioral traits: result cap at top 50 for large cities, coverage of 612 municipalities, and acceptance of Japanese names. No annotations provided, so description carries full burden; it does well.

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 redundancy, front-loaded with key information. 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?

Covers purpose, scope, flags, and limitations. Lacks explicit return format, but acceptable without output schema. Could mention that coordinates and address are included, but overall sufficient.

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?

Only one parameter with full schema coverage; schema itself describes the parameter well. Description adds marginal value (e.g., coverage context) but does not significantly expand parameter meaning.

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?

Clearly states it lists public toilets by municipality with specific flags (wheelchair, baby-seat, ostomate) and distinguishes from sibling get_toilet_by_station by focusing on city-level query.

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?

Provides clear context for when to use (by city) and tips for accuracy (prefix prefecture). Does not explicitly mention when not to use or alternative tools, but siblings list makes differentiation implicit.

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

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

No annotations exist, so description carries full burden. It discloses source ('JMA') and says 'relay of official JMA facts,' but lacks details on output format, emptiness behavior, or any side effects. Minimal but not misleading.

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 efficient sentences: first states purpose and exclusions, second gives usage, third adds matching and source. Front-loaded and 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?

No output schema exists, so description should fill the gap. It vaguely says 'relay of official JMA facts' without specifying structure or how it relates to sibling tools like 'get_active_alerts' or 'get_station_hazard.' Incomplete for complex decision-making.

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% coverage for the single parameter, providing format (Japanese/romaji). Description adds context about 'prefecture-level match,' which is useful beyond 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 provides 'Live JMA river flood forecasts and landslide alerts affecting a station's prefecture' and explicitly excludes 'general weather warnings,' making the purpose specific and distinct from siblings like 'get_active_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?

Provides clear instructions to input station name in Japanese or romaji, and notes 'Prefecture-level match.' 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.

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

No annotations provided, so description carries full burden. It notes 'official values only — no scores' but lacks details on error handling, caching, or data freshness for a read-only lookup.

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 that is front-loaded and contains all key information without filler.

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?

No output schema. Description states it returns municipality context but lacks specifics about the returned fields. Adequate for a simple lookup, but could be more complete.

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%. Description adds value by clarifying the station_id format and the fields parameter's comma-separated syntax, going beyond schema descriptions.

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?

Clearly states it returns municipality data resolved from a station, explicitly distinguishing it from the sibling get_municipality_context by specifying the resolution method.

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?

Tells when to use (with a station_id) and mentions 'Official values only — no scores', but does not explicitly list alternative tools or when not to use.

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

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

No annotations are provided, but the description compensates thoroughly. It discloses the data source (MLIT), the fact that some categories are unavailable due to licensing (with behavior: return available:false and a link), and that values are returned as-is without composite scores. It also states accepted input formats (Japanese or romaji) and gives example names.

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 contributes useful information. It front-loads the core purpose and data source. Minor redundancy could be trimmed, but overall it is well-structured 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?

Despite no output schema, the description fully specifies what the tool returns (specific hazard categories) and notes gaps (landslide, tsunami). It also explains the data source and the tool's research/analytics use case. For a single-param tool, this is highly complete.

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 is only one parameter (station_name) with 100% schema coverage. The description adds value beyond the schema by specifying accepted formats (Japanese and romaji) and providing concrete examples (新宿, 武蔵小杉, Shinjuku, Musashi-Kosugi), which aids agent understanding.

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 Japanese train stations from a specific government source (MLIT). It specifies the exact types of data (flood inundation-depth rank, landform/liquefaction classification, storm-surge inundation-area) and distinguishes itself from sibling tools like get_active_alerts or get_toilet_by_station, which serve different purposes.

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 explicit usage guidance, stating the tool is for research/analytics and not a substitute for official hazard maps or evacuation decisions. It also notes that landslide and tsunami data are license-restricted and return available:false with a link, but does not explicitly mention when to use this tool over alternatives.

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

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

With no annotations, the description carries full burden. It discloses coverage (526 stations), input formats, and return fields (floor, gender, equipment, nearest exit). It does not mention error handling or rate limits, but for a simple lookup tool this is adequate.

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 with no wasted words. The key action and resource are front-loaded, making it easy to scan.

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?

Despite no output schema, the description thoroughly explains what will be returned (floor, gender, equipment, nearest exit) and the tool's scope (526 stations, input formats). It is complete for the tool's simplicity.

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 the station parameter already described. The description adds extra context (covers 526 stations, accepts romaji for major stations) but does not significantly enhance beyond the schema. Baseline of 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?

The description clearly states the verb 'look up' and the resource 'wheelchair-accessible / multipurpose toilets inside a Tokyo train station', including specific return fields. It distinguishes itself from sibling tools like 'get_public_toilet_by_city' and 'get_station_alerts' by focusing on station 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 on when to use (for station toilets in Tokyo) and input formats, but does not explicitly mention when not to use or contrast with other tools. The scope is well-defined.

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

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

With no annotations, the description carries the full burden. It discloses the status enum values (normal/delayed/suspended/resumed), how cause text is handled (English summary for known patterns, else original text or null), and the data source (ODPT CC BY 4.0). This provides useful behavioral context beyond the schema.

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, with a front-loaded purpose statement, a usage example, and key behavioral details. Every sentence earns its place, and it avoids redundancy with the schema.

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 parameter, no output schema, no annotations), the description covers purpose, usage, status enum, cause text behavior, and data source. It could be improved by explicitly stating the return structure, but it is sufficiently complete for an agent to understand the 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?

The input schema has one parameter ('query') with a description that covers usage (line or station name, English or Japanese). The schema description coverage is 100%, so the baseline is 3. The tool description adds no new parameter meaning beyond reinforcing the example.

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 train service status for Tokyo-area lines, including delays, suspensions, and resumptions. It differentiates from sibling tools (e.g., get_station_alerts, get_public_toilet_by_city) by focusing on train line status.

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 an example query ('is the Yamanote Line running?') and notes the input can be English or Japanese. However, it does not explicitly state when not to use this tool or mention alternatives like get_active_alerts for general alerts.

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