Japan JMA warnings, typhoons, volcano levels and municipality code history in English; x402 checks
Scored across 8 tools
Most tools have clearly distinct purposes, but the single vs. batch municipality tools overlap by design, and jp_trip_impact_check can be confused with using jp_warnings/jp_typhoons/jp_volcanoes directly. The descriptions do a good job clarifying these boundaries.
All names use snake_case and six domain tools share the jp_ prefix, which is predictable and readable. However, the set mixes noun-style names (catalog, jp_warnings) with a verb_noun utility name (get_receipt), so it is not fully uniform.
Eight tools are well scoped for this server: discovery, receipt retrieval, municipality lookup, batch lookup, trip impact, typhoons, volcanoes, and warnings. Each tool corresponds to a meaningful operation without excessive surface area.
The server covers the core paid-call lifecycle (catalog, calls, receipt retrieval) and the main described JMA/municipality resources. Notable gaps remain around other Japan hazard information such as earthquakes/tsunamis and any forecast or historical operations, though the descriptions explicitly disclaim forecasting.
List the tools of this server with prices, data sources, licensing, daily limits and data freshness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| legal | Yes | |
| terms | Yes | URL of the terms of service. |
| tools | Yes | Every tool of this server with its price. |
| paused | Yes | Operator pause flags (true = paused). |
| server | Yes | |
| payment | Yes | |
| provenance | No | Freshness receipts for every upstream source used. |
| daily_limits | Yes | Daily limits of paid calls (calls, usd, timezone) or a misconfiguration notice. |
| fetch_status_values | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds the content categories returned (prices, licensing, limits, freshness), which is useful context, but an output schema exists and would surface the same structure, so the incremental disclosure is modest.
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?
A single front-loaded sentence with no filler; every clause enumerates distinct payload content, so nothing is wasted.
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 no parameters, a read-only annotation, and an output schema present, the description need not explain return values or safety. It is nearly complete for this simple tool; only a hint about when to reach for it is absent.
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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies under the '0 params' rule.
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?
Clear verb ("List") plus resource ("the tools of this server") and an enumeration of the payload contents (prices, data sources, licensing, daily limits, freshness). It is plainly distinguishable from siblings like get_receipt or drone_flight_check, though it does not explicitly name or contrast them.
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?
No explicit when-to-use or when-not-to-use guidance is given; usage is only implied by the discovery framing ("the tools of this server"). An agent can infer this is the entry point for learning available tools and pricing, but nothing states that intent directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-fetch the stored result of a settled paid call (e.g. jp_trip_impact_check) by its receipt_id, for when the response was lost after payment. Free. Unknown or unsettled receipt ids return RECEIPT_NOT_FOUND. Results are kept for 30 days after settlement.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | The receipt_id returned with a paid result ("rcpt_" + 64 hex characters). |
| Name | Required | Description |
|---|---|---|
| tool | Yes | Name of the paid tool that produced the result. |
| terms | Yes | URL of the terms of service. |
| result | Yes | The stored result, exactly as returned by the paid call. |
| payment | Yes | |
| provenance | Yes | Freshness receipts for every upstream source used. |
| receipt_id | Yes | Receipt id of the settled paid call ("rcpt_" + 64 hex). Use with get_receipt. |
| settled_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint annotation by disclosing cost behavior ("Free"), the failure mode and exact error code (RECEIPT_NOT_FOUND) for unknown or unsettled ids, and the 30-day retention window. These are exactly the traits an agent needs to decide whether to retry or give up.
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?
Front-loaded with the core action, then three short clauses covering cost, error behavior, and retention. Every sentence carries distinct information and none repeats the title or 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?
Single-required-parameter tool with an output schema, and the description covers the remaining gaps: when to use it, cost, failure semantics, and data lifetime. Nothing an agent needs to invoke it correctly 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?
Schema coverage is 100%, and the schema already documents the receipt_id format ("rcpt_" + 64 hex characters). The description only restates that lookup is by receipt_id, adding no syntax or format detail beyond the schema, so baseline 3 applies.
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?
States a specific verb and resource ("Re-fetch the stored result of a settled paid call") and names an example sibling product (jp_trip_impact_check), making clear this retrieves a prior result rather than executing a new call. An agent can distinguish this from the sibling tools without opening the schema.
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?
Gives an explicit triggering condition: use when the response was lost after payment. It also notes the call is free, implicitly steering the agent away from re-invoking the paid sibling. It stops short of explicitly naming the alternative or stating when not to use it, so it's clear context rather than a complete routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which code does this Japanese municipality have on a date (default today)? Give a 5/6-digit code, or prefecture and name (old names OK). Returns status mapped / split_candidates / unknown / invalid, the valid code with English and Japanese names, change type and date (merger, incorporation, division, designated city, name change), confirmed JMA warning areas only, and J-LIS convenience-store certificate availability for 8 certificate types. Facts only, from e-Stat LOD (CC BY 4.0) and J-LIS.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Municipality code: 5 digits, or 6 digits including the check digit (e.g. 22131 or 221317). | |
| name | No | Municipality or ward name in Japanese (old names accepted; a ward may be prefixed with its city) or its e-Stat English name (e.g. "Naka-ku", "Hamamatsu-shi"). Use with prefecture. | |
| as_of | No | YYYY-MM-DD. The date the answer is for (default: today in Japan time). | |
| prefecture | No | Japanese prefecture: English name (e.g. "Tokyo", "Osaka", "Hokkaido"; "Tokyo-to" and "Osaka Prefecture" also work), Japanese name in kanji, or JIS code "01".."47". Use with name. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| input | Yes | The query as understood (code or prefecture and name, and as_of). |
| terms | Yes | URL of the terms of service. |
| source | Yes | |
| status | Yes | mapped / split_candidates / unknown / invalid. |
| changes | Yes | |
| disclaimer | Yes | |
| provenance | Yes | Freshness receipts for every upstream source used. |
| as_of_codes | Yes | Codes valid on as_of, with names, JMA area and J-LIS certificate availability. |
| license_note | Yes | |
| out_of_scope | Yes | |
| responded_at | Yes | |
| retrieved_at | Yes | |
| checked_scope | Yes | |
| status_values | Yes | |
| national_rules | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=true in annotations, the description carries meaningful extra weight: it enumerates the possible status outcomes (mapped / split_candidates / unknown / invalid), qualifies that only 'confirmed JMA warning areas' are returned, and cites the data provenance (e-Stat LOD CC BY 4.0 and J-LIS). This is genuine behavioral context beyond the annotation, though the output schema already covers the return shape.
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 core purpose question is front-loaded, followed by compact input guidance and a single dense sentence covering outputs, scope, and provenance. Every sentence contributes; there is no 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?
An output schema exists so return values need not be spelled out, and the description still notes statuses, scope limits, and data sources. Combined with 100% schema coverage and a read-only annotation, it gives an agent enough to call the tool correctly; only sibling routing 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?
Schema description coverage is 100%, so all four parameters are already documented in the schema, including code format, name handling, and prefecture formats. The description largely restates the schema ('old names OK', 5/6-digit code) without adding syntax or format meaning, so the baseline 3 applies.
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 opening question 'Which code does this Japanese municipality have on a date' names a specific resource (municipality code) and the resolution task, so an agent immediately understands it is a lookup tool. It does not explicitly name or differentiate from the sibling jp_municipality_batch, which is the one clear gap.
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 tells the agent which input forms are accepted ('a 5/6-digit code, or prefecture and name (old names OK)'), which is useful boundary info, but gives no explicit when-to-use vs when-not guidance or routing to the batch/trip-impact siblings. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which codes are valid on a date for up to 50 Japanese municipalities? e-Stat LOD change history (CC BY 4.0): status mapped / split_candidates (all successors, not apportioned) / unknown / invalid, the code valid on as_of with English and Japanese names, change type and date, confirmed JMA warning areas only, and J-LIS convenience-store certificate availability (available / not_listed / unknown). Facts only; no document preparation or legal advice. Retrying with the same payment is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Default as_of for items that do not set their own. | |
| items | Yes | 1 to 50 lookups; each gives code, or prefecture and name. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful context beyond them: the tool is paid and 'Retrying with the same payment is not charged' (retry/idempotency behavior), plus the data provenance (e-Stat LOD, CC BY 4.0) and status taxonomy returned.
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 key question is front-loaded, which is good, but the second half is a dense run-on enumerating status values, name languages, change fields, and certificate availability. It is informative yet cluttered rather than tight.
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, return values need not be explained, and the batch item rules live in the schema. The description still covers payment/retry behavior and data licensing, leaving little an agent needs missing, though the single-vs-batch routing is not spelled out.
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 code, name, prefecture, and as_of are fully documented in the schema. The description adds little parameter-level detail (only that answers are 'valid on as_of'), so the baseline 3 applies.
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 opening question names the verb (validate/lookup) and resource (Japanese municipality codes on a date) and the batch scope ('up to 50'), and the field list makes the output concrete. It distinguishes itself from the sibling jp_municipality only implicitly via the 50-item cap, never naming the single-lookup alternative.
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?
Usage is only implied: 'up to 50' signals when to prefer batch over a single lookup, and 'Facts only; no document preparation or legal advice' sets a scope boundary. There is no explicit when-to-use/when-not statement nor a named alternative, so the agent must infer the routing from the item limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Does a JMA warning or advisory in effect now match a stop on this Japan itinerary [{date, prefecture}]? Per stop: matched_advisory (with severity), no_match_in_checked_sources (NOT a statement of no impact) or unknown (data missing, or date not today/tomorrow JST). Returns checked sources and areas, unchecked areas, issued_at, retrieved_at, and current JMA typhoon/volcano bulletins (listed, not matched). No forecast. Retrying with the same payment is not charged; use receipt_id with get_receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| itinerary | Yes | 1 to 14 stops {date, prefecture}, in travel order. Only stops dated today or tomorrow (Japan time) can be matched; others return unknown, but typhoon and volcano bulletins currently in effect are still listed (not matched). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint, the description discloses the paid nature and retry billing rule ('Retrying with the same payment is not charged'), the receipt_id hand-off to get_receipt, the false-negative caveat that no_match_in_checked_sources is 'NOT a statement of no impact', the unknown condition, and structured return fields including unchecked areas. This is exactly the behavioral context annotations cannot carry.
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?
Front-loaded with the core question in the first clause, then packed with essential caveats in dense but purposeful parentheticals. Every sentence carries load (match semantics, return fields, billing, receipt hand-off), though the telegraphic style makes it slightly harder to scan than an ideal multi-sentence layout.
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, the description need not enumerate return values, yet it interprets the most dangerous one (no_match_in_checked_sources) and the unknown case, covers payment/retry and receipt retrieval, and states the no-forecast limitation. An agent has everything needed to call this correctly and interpret the result safely.
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 the baseline is 3; the description earns more by adding meaning to the itinerary parameter that the schema only partially conveys — that non-today/tomorrow dates yield unknown and that typhoon/volcano bulletins are still listed regardless. It does not re-explain the prefecture/date formats, but the schema already does that 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?
The opening sentence states a specific verb and resource: matching an in-effect JMA warning/advisory against stops on a Japan itinerary. It also draws the boundary against related-but-different tools by scoping to itinerary matching, and against jp_warnings-style raw data by noting bulletins are 'listed, not matched' and that there is 'No forecast'. An agent can place this tool precisely without opening any sibling schema.
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?
Usage context is clear: you supply a dated itinerary and get a match/no-match/unknown verdict, with the crucial precondition that only stops dated today or tomorrow JST can be matched. It does not, however, explicitly name alternatives (e.g. jp_warnings, jp_typhoons) or state when to prefer them over this paid call, so the routing guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which typhoons is JMA issuing bulletins for right now, and what do the bulletins forecast? Number, name, center position, central pressure, maximum wind, issue time, and forecast-circle centers, radii and times, relayed as structured JSON from JMA bulletins (VPTW60-65). No independent forecast, interpolation or track extension.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| count | Yes | |
| ended | Yes | |
| terms | Yes | URL of the terms of service. |
| source | Yes | Data source and processor. |
| status | Yes | listed = JMA is issuing typhoon bulletins; none_in_checked_sources = none in the checked feeds; partial/unknown = some or all could not be checked. |
| typhoons | Yes | |
| unchecked | Yes | |
| provenance | Yes | Freshness receipts for every upstream source used. |
| license_note | Yes | |
| responded_at | Yes | |
| retrieved_at | Yes | When the upstream data was retrieved (ISO 8601). |
| checked_sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already declaring the safety and external-data profile, the description adds real value: the upstream provenance (JMA bulletins VPTW60-65) and the explicit statement that no independent forecast, interpolation or track extension is performed. That provenance/scope disclosure goes beyond what annotations provide.
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?
A single dense sentence, front-loaded with the scoping question and followed by the returned fields, with no filler. The enumerated return fields duplicate what the output schema already provides, costing a little space.
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?
Zero parameters and an output schema mean the description need not explain invocation or return shapes, and it covers provenance and no-derivation limits. It stops short of noting bulletin update cadence or that 'right now' reflects the latest JMA issuance rather than live tracking.
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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The field list in the description actually describes outputs rather than inputs, which is redundant with the output schema but not harmful.
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 states a specific resource (JMA typhoon bulletins) and enumerates exactly what is returned: number, name, center position, pressure, max wind, issue time, forecast circles. This clearly separates it from jp_volcanoes and jp_warnings by resource, though it never names those siblings explicitly.
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?
Usage is implied by the framing question ('which typhoons is JMA issuing bulletins for right now') and constrained by 'No independent forecast, interpolation or track extension', which tells the agent this is a relay only. However, no alternative tool is named and no explicit condition for choosing this over, e.g., jp_warnings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is the current JMA Volcanic Alert Level (1-5, or warning kind) of this volcano or of every JMA-monitored volcano? Name in English or Japanese, or 3-digit JMA code. Returns JMA English and Japanese names, level, previous level and change, issue time, prefectures named in JMA bulletins, source URL and freshness receipt. Relay only; no forecast or interpretation. Gaps filled from JMA website lists (newer wins). No JMA source seen = not_seen_in_checked_feeds, never assumed level 1.
| Name | Required | Description | Default |
|---|---|---|---|
| volcano | No | Optional. JMA volcano name in English (e.g. "Sakurajima", "Asamayama") or Japanese (e.g. "桜島"), or the 3-digit JMA volcano code (e.g. "506"). Omit to list all volcanoes. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| count | Yes | |
| terms | Yes | URL of the terms of service. |
| source | Yes | Data source and processor. |
| coverage | Yes | complete = every volcano has a usable state (from an XML bulletin, warning.json or the monthly national summary) and no bulletin is pending or failed. |
| volcanoes | Yes | One entry per volcano. |
| provenance | Yes | Freshness receipts for every upstream source used. |
| license_note | Yes | |
| responded_at | Yes | |
| retrieved_at | Yes | When the upstream data was retrieved (ISO 8601). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description discloses the full return shape, the relay-only/no-interpretation contract, the provenance rule ('Gaps filled from JMA website lists (newer wins)'), and the critical failure semantics ('No JMA source seen = not_seen_in_checked_feeds, never assumed level 1'). That last clause is exactly the kind of anti-hallucination guidance an agent needs and that annotations cannot supply.
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 question-form opening is front-loaded and every clause carries weight: formats, return fields, relay policy, provenance, and the not_seen_in_checked_feeds rule. It is dense rather than padded, though the enumerated return fields are partly redundant with the output 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?
An output schema exists so return values did not need describing, yet the operational gaps are all covered: scope, input formats, provenance, currency (issue time, freshness receipt), and the no-source failure mode. Slightly over-explains the payload, but nothing an agent needs to call it correctly 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?
Schema description coverage is 100% and the single parameter already documents the accepted name formats and omission behavior, so the schema carries the burden. The description restates the same formats and adds only the scope phrase 'of every JMA-monitored volcano', giving it marginal value over structured data.
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 a specific verb+resource: 'current JMA Volcanic Alert Level (1-5, or warning kind)' for a named volcano or all JMA-monitored volcanoes. Success criteria and lookup keys (English/Japanese name or 3-digit JMA code) are stated, and the volcanic domain distinguishes it from siblings like jp_typhoons and jp_warnings.
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?
Usage context is clear: pass a name/code for one volcano, omit to list every JMA-monitored volcano. It also sets a downstream behavioral expectation ('Relay only; no forecast or interpretation'). It does not explicitly name alternatives or when-not-to-use cases against the sibling warning/typhoon tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which JMA weather emergency warnings, warnings and advisories are in effect in this Japanese prefecture now? Structured JSON in English and Japanese (type, level, status, areas with JMA's English names, issued_at, source URL). Relay only; no independent forecast.
| Name | Required | Description | Default |
|---|---|---|---|
| prefecture | Yes | Japanese prefecture: English name (e.g. "Tokyo", "Osaka", "Hokkaido"; "Tokyo-to" and "Osaka Prefecture" also work), Japanese name in kanji, or JIS code "01".."47". | |
| include_municipalities | No | Also list every municipality (Japanese and English names) per warning. Default false. |
| Name | Required | Description |
|---|---|---|
| terms | Yes | URL of the terms of service. |
| counts | Yes | |
| region | Yes | |
| source | Yes | Data source and processor. |
| coverage | Yes | complete = the current status of every forecast area was confirmed (JMA XML bulletin or JMA website current-status data); partial = some not confirmed; unknown = none confirmed (see missing_offices; not 'no warnings'). |
| warnings | Yes | Warnings and advisories in effect (type, level, status, areas). |
| bulletins | Yes | |
| prefecture | Yes | |
| provenance | Yes | Freshness receipts for every upstream source used. |
| license_note | Yes | |
| responded_at | Yes | |
| retrieved_at | Yes | When the upstream data was retrieved (ISO 8601). |
| danger_notice | Yes | |
| forecast_areas | Yes | |
| missing_offices | Yes | |
| lifted_in_latest_bulletin | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint and openWorldHint, so the bar is lower. The description adds real value beyond them: it declares the tool is a pure relay of JMA data with no independent forecasting, that results are bilingual, and that it reflects conditions 'now' rather than history. It stops short of stating caching or freshness latency, which would have pushed it higher.
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 filler, with the core question front-loaded and the return shape summarized in a parenthetical. The rhetorical question opener is slightly indirect but still efficient; nothing is wasted.
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 an output schema exists, the description need not explain return values, yet it usefully previews the field set and language coverage. Combined with annotations covering safety and open-world behavior, an agent has enough to call it correctly; only latency/freshness semantics for '(now)' are left unstated.
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 the schema already explains the prefecture formats and the include_municipalities flag. The description adds nothing beyond that for parameters (the mention of 'areas' refers to output, not input). Baseline 3 is appropriate when the schema does all the work.
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 states a specific verb and resource ('Which JMA weather emergency warnings, warnings and advisories are in effect'), scopes it to a Japanese prefecture and to the present moment, and enumerates the payload. An agent can immediately distinguish it from jp_typhoons or jp_volcanoes because the resource is prefecture-level weather warnings.
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?
Usage is implied rather than stated: 'in effect ... now' tells the agent this is a current-conditions lookup for one prefecture, and 'Relay only; no independent forecast' constrains downstream use. However, it never says when to prefer this over jp_trip_impact_check or jp_typhoons, nor any prerequisites, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
jp_volcanoes3 fields changedOutput schema / properties / coverage / descriptionAdded value: +"complete = every volcano has a usable state (from an XML bulletin, warning.json or the monthly national summary) and no bulletin is pending or failed."Output schema / properties / coverage / properties / volcanoes_not_seenAdded value: +{
+ "type": "number"
+}Output schema / properties / coverage / requiredPrevious value: -[
- "status",
- "tracking_since",
- "volcanoes_total",
- "volcanoes_listed"
-]New value: +[
+ "status",
+ "tracking_since",
+ "volcanoes_total",
+ "volcanoes_listed",
+ "volcanoes_not_seen"
+]jp_trip_impact_check1 field changedInput schema / properties / itinerary / descriptionPrevious value: -"1 to 14 stops {date, prefecture}, in travel order. Only stops dated today or tomorrow (Japan time) can be matched; others return unknown."New value: +"1 to 14 stops {date, prefecture}, in travel order. Only stops dated today or tomorrow (Japan time) can be matched; others return unknown, but typhoon and volcano bulletins currently in effect are still listed (not matched)."jp_warnings1 field changedOutput schema / properties / coverage / descriptionPrevious value: -"complete = every forecast area has a usable latest bulletin; partial = some missing; unknown = none."New value: +"complete = the current status of every forecast area was confirmed (JMA XML bulletin or JMA website current-status data); partial = some not confirmed; unknown = none confirmed (see missing_offices; not 'no warnings')."catalog1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "daily_limits": {
+ "additionalProperties": {},
+ "description": "Daily limits of paid calls (calls, usd, timezone) or a misconfiguration notice.",
+ "properties": {},
+ "type": "object"
+ },
+ "fetch_status_values": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "legal": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "paused": {
+ "additionalProperties": {
+ "type": "boolean"
+ },
+ "description": "Operator pause flags (true = paused).",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "payment": {
+ "additionalProperties": {},
+ "properties": {
+ "asset": {
+ "type": "string"
+ },
+ "enabled": {
+ "type": "boolean"
+ },
+ "network": {
+ "type": "string"
+ },
+ "protocol": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "protocol",
+ "network",
+ "asset",
+ "enabled"
+ ],
+ "type": "object"
+ },
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "server": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "stage": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "version",
+ "stage"
+ ],
+ "type": "object"
+ },
+ "terms": {
+ "description": "URL of the terms of service.",
+ "type": "string"
+ },
+ "tools": {
+ "description": "Every tool of this server with its price.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "price_usd": {
+ "description": "Price per call in USD (0 = free).",
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "price_usd",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "server",
+ "payment",
+ "daily_limits",
+ "paused",
+ "tools",
+ "legal",
+ "terms"
+ ],
+ "type": "object"
+}get_receipt1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "payment": {
+ "additionalProperties": {},
+ "properties": {
+ "network": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "transaction": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "network",
+ "transaction"
+ ],
+ "type": "object"
+ },
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "receipt_id": {
+ "description": "Receipt id of the settled paid call (\"rcpt_\" + 64 hex). Use with get_receipt.",
+ "type": "string"
+ },
+ "result": {
+ "description": "The stored result, exactly as returned by the paid call."
+ },
+ "settled_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "terms": {
+ "description": "URL of the terms of service.",
+ "type": "string"
+ },
+ "tool": {
+ "description": "Name of the paid tool that produced the result.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "receipt_id",
+ "tool",
+ "settled_at",
+ "payment",
+ "result",
+ "provenance",
+ "terms"
+ ],
+ "type": "object"
+}jp_municipality1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "as_of": {
+ "type": "string"
+ },
+ "as_of_codes": {
+ "description": "Codes valid on as_of, with names, JMA area and J-LIS certificate availability.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "convenience_store_certificates": {
+ "additionalProperties": {},
+ "properties": {
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "jma_area": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "code",
+ "jma_area",
+ "convenience_store_certificates"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "changes": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "checked_scope": {
+ "type": "string"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "input": {
+ "additionalProperties": {},
+ "description": "The query as understood (code or prefecture and name, and as_of).",
+ "properties": {
+ "as_of": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "as_of"
+ ],
+ "type": "object"
+ },
+ "license_note": {
+ "type": "string"
+ },
+ "national_rules": {},
+ "out_of_scope": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "responded_at": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "type": "string"
+ },
+ "status": {
+ "description": "mapped / split_candidates / unknown / invalid.",
+ "enum": [
+ "mapped",
+ "split_candidates",
+ "unknown",
+ "invalid"
+ ],
+ "type": "string"
+ },
+ "status_values": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "terms": {
+ "description": "URL of the terms of service.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "input",
+ "status",
+ "as_of",
+ "as_of_codes",
+ "changes",
+ "national_rules",
+ "out_of_scope",
+ "status_values",
+ "disclaimer",
+ "checked_scope",
+ "source",
+ "license_note",
+ "provenance",
+ "retrieved_at",
+ "responded_at",
+ "terms"
+ ],
+ "type": "object"
+}jp_municipality_batch1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "checked_scope": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "license_note": {
+ "type": "string"
+ },
+ "national_rules": {},
+ "out_of_scope": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "receipt_id": {
+ "description": "Receipt id of the settled paid call (\"rcpt_\" + 64 hex). Use with get_receipt.",
+ "type": "string"
+ },
+ "responded_at": {
+ "type": "string"
+ },
+ "results": {
+ "description": "One result per item, in input order.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "as_of": {
+ "type": "string"
+ },
+ "as_of_codes": {
+ "description": "Codes valid on as_of, with names, JMA area and J-LIS certificate availability.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "convenience_store_certificates": {
+ "additionalProperties": {},
+ "properties": {
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "jma_area": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "code",
+ "jma_area",
+ "convenience_store_certificates"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "changes": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "input": {
+ "additionalProperties": {},
+ "description": "The query as understood (code or prefecture and name, and as_of).",
+ "properties": {
+ "as_of": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "as_of"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "description": "mapped / split_candidates / unknown / invalid.",
+ "enum": [
+ "mapped",
+ "split_candidates",
+ "unknown",
+ "invalid"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "input",
+ "status",
+ "as_of",
+ "as_of_codes",
+ "changes"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "retrieved_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "type": "string"
+ },
+ "status_values": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "summary": {
+ "additionalProperties": {},
+ "properties": {
+ "invalid": {
+ "type": "number"
+ },
+ "mapped": {
+ "type": "number"
+ },
+ "split_candidates": {
+ "type": "number"
+ },
+ "unknown": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "mapped",
+ "split_candidates",
+ "unknown",
+ "invalid"
+ ],
+ "type": "object"
+ },
+ "terms": {
+ "description": "URL of the terms of service.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "receipt_id",
+ "count",
+ "summary",
+ "results",
+ "national_rules",
+ "out_of_scope",
+ "status_values",
+ "disclaimer",
+ "checked_scope",
+ "source",
+ "license_note",
+ "provenance",
+ "retrieved_at",
+ "responded_at",
+ "terms"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "description": "x402 PaymentRequired (returned with isError true when payment is required or was not accepted).",
+ "properties": {
+ "accepts": {
+ "description": "Payment options (x402 v2 PaymentRequirements).",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "network": {
+ "type": "string"
+ },
+ "scheme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "scheme",
+ "network"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "type": "string"
+ },
+ "resource": {
+ "additionalProperties": {},
+ "properties": {
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url"
+ ],
+ "type": "object"
+ },
+ "x402Version": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x402Version",
+ "accepts"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Either the paid result (with receipt_id) or, with isError true, the x402 PaymentRequired to pay and retry.",
+ "properties": {},
+ "type": "object"
+}jp_trip_impact_check2 fields changedInput schema / properties / itinerary / descriptionAdded value: +"1 to 14 stops {date, prefecture}, in travel order. Only stops dated today or tomorrow (Japan time) can be matched; others return unknown."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "checked_at_jst_date": {
+ "type": "string"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "license_note": {
+ "type": "string"
+ },
+ "not_covered": {},
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "receipt_id": {
+ "description": "Receipt id of the settled paid call (\"rcpt_\" + 64 hex). Use with get_receipt.",
+ "type": "string"
+ },
+ "related_bulletins": {
+ "additionalProperties": {},
+ "properties": {
+ "matched_against_stops": {
+ "type": "boolean"
+ },
+ "typhoon_status": {
+ "enum": [
+ "bulletin_listed_not_matched",
+ "no_bulletin_in_checked_sources",
+ "not_checked",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "typhoons": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "volcano_matched_against_stops": {
+ "type": "boolean"
+ },
+ "volcano_status": {
+ "enum": [
+ "bulletin_listed_not_matched",
+ "no_alert_in_checked_sources",
+ "not_checked",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "volcanoes": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "typhoon_status",
+ "typhoons",
+ "matched_against_stops",
+ "volcano_status",
+ "volcanoes",
+ "volcano_matched_against_stops"
+ ],
+ "type": "object"
+ },
+ "responded_at": {
+ "type": "string"
+ },
+ "results": {
+ "description": "One result per itinerary stop, in order.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "checked_areas": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "checked_sources": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "date": {
+ "type": "string"
+ },
+ "impact": {
+ "description": "matched_advisory / no_match_in_checked_sources (NOT a statement of no impact) / unknown.",
+ "enum": [
+ "matched_advisory",
+ "no_match_in_checked_sources",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "issued_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "prefecture": {
+ "additionalProperties": {},
+ "properties": {
+ "input": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "input"
+ ],
+ "type": "object"
+ },
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "retrieved_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "severity": {
+ "anyOf": [
+ {
+ "enum": [
+ "emergency",
+ "warning",
+ "advisory"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "typhoon": {
+ "enum": [
+ "bulletin_listed_not_matched",
+ "no_bulletin_in_checked_sources",
+ "not_checked",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "unchecked_areas": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "date",
+ "prefecture",
+ "impact",
+ "severity",
+ "typhoon",
+ "issued_at",
+ "retrieved_at",
+ "checked_sources",
+ "checked_areas",
+ "unchecked_areas",
+ "provenance"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "retrieved_at": {
+ "description": "When the upstream data was retrieved (ISO 8601).",
+ "type": "string"
+ },
+ "rules": {},
+ "source": {
+ "description": "Data source and processor.",
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": {},
+ "properties": {
+ "matched_advisory": {
+ "type": "number"
+ },
+ "no_match_in_checked_sources": {
+ "type": "number"
+ },
+ "unknown": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "matched_advisory",
+ "no_match_in_checked_sources",
+ "unknown"
+ ],
+ "type": "object"
+ },
+ "terms": {
+ "description": "URL of the terms of service.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "receipt_id",
+ "checked_at_jst_date",
+ "summary",
+ "results",
+ "related_bulletins",
+ "rules",
+ "not_covered",
+ "disclaimer",
+ "provenance",
+ "source",
+ "retrieved_at",
+ "responded_at",
+ "license_note",
+ "terms"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "description": "x402 PaymentRequired (returned with isError true when payment is required or was not accepted).",
+ "properties": {
+ "accepts": {
+ "description": "Payment options (x402 v2 PaymentRequirements).",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "network": {
+ "type": "string"
+ },
+ "scheme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "scheme",
+ "network"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "type": "string"
+ },
+ "resource": {
+ "additionalProperties": {},
+ "properties": {
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url"
+ ],
+ "type": "object"
+ },
+ "x402Version": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x402Version",
+ "accepts"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Either the paid result (with receipt_id) or, with isError true, the x402 PaymentRequired to pay and retry.",
+ "properties": {},
+ "type": "object"
+}jp_typhoons1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "checked_sources": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "count": {
+ "type": "number"
+ },
+ "ended": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "license_note": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "responded_at": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When the upstream data was retrieved (ISO 8601).",
+ "type": "string"
+ },
+ "source": {
+ "description": "Data source and processor.",
+ "type": "string"
+ },
+ "status": {
+ "description": "listed = JMA is issuing typhoon bulletins; none_in_checked_sources = none in the checked feeds; partial/unknown = some or all could not be checked.",
+ "enum": [
+ "listed",
+ "none_in_checked_sources",
+ "partial",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "terms": {
+ "description": "URL of the terms of service.",
+ "type": "string"
+ },
+ "typhoons": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "issued_at": {
+ "type": "string"
+ },
+ "slot": {
+ "type": "string"
+ },
+ "source_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slot",
+ "issued_at",
+ "source_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "unchecked": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "type": "string"
+ },
+ "slot": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slot",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "status",
+ "count",
+ "typhoons",
+ "ended",
+ "unchecked",
+ "checked_sources",
+ "note",
+ "provenance",
+ "source",
+ "retrieved_at",
+ "responded_at",
+ "license_note",
+ "terms"
+ ],
+ "type": "object"
+}jp_volcanoes1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "coverage": {
+ "additionalProperties": {},
+ "properties": {
+ "status": {
+ "enum": [
+ "complete",
+ "partial"
+ ],
+ "type": "string"
+ },
+ "tracking_since": {
+ "type": "string"
+ },
+ "volcanoes_listed": {
+ "type": "number"
+ },
+ "volcanoes_total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "status",
+ "tracking_since",
+ "volcanoes_total",
+ "volcanoes_listed"
+ ],
+ "type": "object"
+ },
+ "license_note": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "responded_at": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When the upstream data was retrieved (ISO 8601).",
+ "type": "string"
+ },
+ "source": {
+ "description": "Data source and processor.",
+ "type": "string"
+ },
+ "terms": {
+ "description": "URL of the terms of service.",
+ "type": "string"
+ },
+ "volcanoes": {
+ "description": "One entry per volcano.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "alert_level": {
+ "description": "Volcanic Alert Level 1-5, or null for volcanoes without levels.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "code": {
+ "description": "3-digit JMA volcano code.",
+ "type": "string"
+ },
+ "issued_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "additionalProperties": {},
+ "properties": {
+ "en": {
+ "type": "string"
+ },
+ "ja": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ja",
+ "en"
+ ],
+ "type": "object"
+ },
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "enum": [
+ "listed",
+ "not_seen_in_checked_feeds",
+ "unavailable"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "name",
+ "status",
+ "alert_level",
+ "issued_at",
+ "source_url",
+ "provenance"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "coverage",
+ "count",
+ "volcanoes",
+ "note",
+ "provenance",
+ "source",
+ "retrieved_at",
+ "responded_at",
+ "license_note",
+ "terms"
+ ],
+ "type": "object"
+}jp_warnings1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "bulletins": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "counts": {
+ "additionalProperties": {},
+ "properties": {
+ "advisory": {
+ "type": "number"
+ },
+ "emergency": {
+ "type": "number"
+ },
+ "warning": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "emergency",
+ "warning",
+ "advisory"
+ ],
+ "type": "object"
+ },
+ "coverage": {
+ "description": "complete = every forecast area has a usable latest bulletin; partial = some missing; unknown = none.",
+ "enum": [
+ "complete",
+ "partial",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "danger_notice": {
+ "type": "boolean"
+ },
+ "forecast_areas": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "en": {
+ "type": "string"
+ },
+ "ja": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "en",
+ "ja"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "license_note": {
+ "type": "string"
+ },
+ "lifted_in_latest_bulletin": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missing_offices": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "office_code": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "office_code",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "prefecture": {
+ "additionalProperties": {},
+ "properties": {
+ "en": {
+ "type": "string"
+ },
+ "ja": {
+ "type": "string"
+ },
+ "jis": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "jis",
+ "en",
+ "ja"
+ ],
+ "type": "object"
+ },
+ "provenance": {
+ "description": "Freshness receipts for every upstream source used.",
+ "items": {
+ "additionalProperties": {},
+ "description": "Freshness receipt for one upstream source.",
+ "properties": {
+ "content_sha256": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetch_status": {
+ "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
+ "enum": [
+ "found",
+ "empty",
+ "stale",
+ "unavailable",
+ "unsupported"
+ ],
+ "type": "string"
+ },
+ "parser_version": {
+ "type": "string"
+ },
+ "processed_by": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When this service retrieved the upstream data (null if unknown).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "additionalProperties": {},
+ "description": "Publisher and URL of the upstream document or dataset.",
+ "properties": {
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "publisher",
+ "url"
+ ],
+ "type": "object"
+ },
+ "upstream_updated_at": {
+ "description": "Update time stated by the upstream, or null when it states none.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "upstream_updated_at",
+ "retrieved_at",
+ "content_sha256",
+ "parser_version",
+ "fetch_status",
+ "processed_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "region": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "en": {
+ "type": "string"
+ },
+ "ja": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "en",
+ "ja"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "responded_at": {
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When the upstream data was retrieved (ISO 8601).",
+ "type": "string"
+ },
+ "source": {
+ "description": "Data source and processor.",
+ "type": "string"
+ },
+ "terms": {
+ "description": "URL of the terms of service.",
+ "type": "string"
+ },
+ "warnings": {
+ "description": "Warnings and advisories in effect (type, level, status, areas).",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "issued_at": {
+ "type": "string"
+ },
+ "office_code": {
+ "type": "string"
+ },
+ "source_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "office_code",
+ "issued_at",
+ "source_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "prefecture",
+ "region",
+ "forecast_areas",
+ "coverage",
+ "missing_offices",
+ "counts",
+ "danger_notice",
+ "warnings",
+ "lifted_in_latest_bulletin",
+ "bulletins",
+ "provenance",
+ "source",
+ "retrieved_at",
+ "responded_at",
+ "license_note",
+ "terms"
+ ],
+ "type": "object"
+}catalogget_receiptjp_municipalityjp_municipality_batchjp_trip_impact_checkjp_typhoonsjp_volcanoesjp_warningsJMA weather warnings by prefecture.
JMA volcano warnings and eruption forecasts.
Japan: next bus/tram/boat from 26 places, RTK bases, JMA warnings, municipality facts. No key.
Live JMA earthquake bulletins and intensity reports for Japan.
Add one secure layer between your agents and this server.