Free Agent Tools

Japan 防災庁 emergency request (2026-11-02): how much water, food and portable-toilet stock does this household need, is the home old quake standard, and what's left to do?

japan_disaster_prep_check

Read-onlyIdempotent

Turns the five-point emergency request (事前防災徹底のための緊急要請) issued by Japan's Disaster Management Agency (防災庁) on 2026-11-02 into a household checklist, rules as of 2026-11-02, from the request text, the PM's Office 災害への備え page, 防災庁 / METI portable-toilet guidance, MLIT seismic pages and the MoE pet pamphlet. Stockpile for days (default 7; the request: at least 3, ideally 1 week): drinking water 3 L per person per day (incl. cooking), 3 meals and 5 portable-toilet uses per person per day (infants: water only, milk and diapers listed), gap against haveWaterLiters / haveMeals / haveToiletUses; pets: food and water at least 5 days, ideally 7+. Building: 建築確認 before 1981-06-01 = old quake standard (旧耐震) → 耐震診断; build year 1981 → check the permit date; wooden houses 1981-06-01 – 2000-05-31 → MLIT 新耐震木造住宅検証法 owner self-check; renters → ask the landlord. builtYear accepts 1979, 昭和54, S54, 平成12, H12. Returns verdict (well_prepared | partly_prepared | not_prepared), summary, doneCount, household, days, stockpile {water {target, minimum3Days, have, gap, bottles2L}, meals, toiletUses, pets, alsoStock, rollingStock}, building {era old_standard | likely_old | new_pre2000_wood | new_standard | unknown, label, action}, request [{n, title, ja, status done | partial | todo, todo[]} ×5: 耐震・家具固定, 備蓄, ハザードマップ・避難経路, 非常持ち出し品, 防災訓練], links, note, sources, disclaimer. Use for '防災庁緊急要請何をすれば', '備蓄何リットル家族', '携帯トイレ何回分', 'how much water to store Japan earthquake', 'is my house 旧耐震', 'Japan disaster preparedness checklist'. Not a disaster prediction (the request is a standing call to prepare). Educational, not official and not engineering or safety advice; not affiliated with 防災庁 or any government body.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "japan_disaster_prep_check"
  }
}

Input Schema

Name	Required	Description
`cats`	No	Cats.
`days`	No	Days to stock for (default 7; minimum 3 per the request).
`dogs`	No	Dogs.
`adults`	No	Adults (default 1).
`tenure`	No	own (default) \| rent.
`elderly`	No	Older family members.
`infants`	No	Babies on milk / in diapers (water only; milk and diapers listed).
`children`	No	Children (count like adults).
`builtYear`	No	Year the home was built: 1979, 昭和54, S54, 平成12, H12.
`haveMeals`	No	Meals of stored food already on hand.
`goBagReady`	No	Grab bag (非常持ち出し品) packed.
`permitDate`	No	建築確認 date on the 確認済証, YYYY-MM-DD (exact 1981-06-01 line).
`drillJoined`	No	Joined a local disaster drill.
`seismicDone`	No	Already had a passing 耐震診断 or a retrofit.
`buildingType`	No	wood (木造 house) \| non_wood (RC / steel, most マンション) \| unknown (default).
`furnitureFixed`	No	Tall furniture and appliances are fixed.
`haveToiletUses`	No	Portable / emergency toilet uses (bags) already on hand.
`haveWaterLiters`	No	Drinking water already stored, litres.
`hazardMapChecked`	No	Checked hazard maps for home and work.
`evacuationRouteChecked`	No	Knows the evacuation site and route.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description still adds substantial behavior: the ruleset is pinned to 2026-11-02, the underlying sources are named (request text, PM's Office 災害への備え, 防災庁/METI toilet guidance, MLIT seismic pages, MoE pet pamphlet), and the output enumerations (well_prepared | partly_prepared | not_prepared; old_standard | likely_old | new_pre2000_wood | new_standard | unknown) are disclosed. It also states its own limits: educational, not official, not engineering or safety advice, not affiliated with any government body.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead sentence is correctly front-loaded, but the body degenerates into a long semicolon-chained run-on that crams rules, source list, and a full return-shape dump into one paragraph, which is hard to scan. Most content earns its place, but the sources list and the exhaustive field enumeration could be tightened or split.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 20 optional parameters and no output schema, the description carries the full burden and does so: it documents the computation rules, the default/minimum for days, every output grouping and its enum values, and the disclaimer. An agent could answer correctly on the first call without consulting anything else.

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

Parameters5/5

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

With 100% schema coverage the baseline is 3, but the description goes further by explaining how inputs drive outputs: 3 L water per person per day including cooking, 3 meals and 5 toilet uses per person per day, infants counted for water only, pets at least 5 (ideally 7+) days, 1981 build year → check the permit date against the 1981-06-01 建築確認 line, and renters → ask the landlord. That rescues the thin schema entries like 'Cats.' and 'Dogs.' by tying them to the 5–7 day pet stock rule.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific transformation verb and resource: it turns the 2026-11-02 防災庁 five-point emergency request into a household checklist and computes stockpile gaps and building-era status. The return-shape enumeration (verdict, stockpile{water, meals, toiletUses, pets}, building{era, action}, request[×5]) makes the scope unambiguous. Nothing in the sibling list (japan_emergency_alert_decode, japan_pet_quarantine_check, etc.) overlaps this preparation-planning function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit trigger phrasings in both languages ('防災庁緊急要請何をすれば', 'how much water to store Japan earthquake', 'is my house 旧耐震') and a clear exclusion: 'Not a disaster prediction (the request is a standing call to prepare).' What it lacks is a named alternative sibling to route to when the user actually wants an alert decoded or a trip plan, which would have made this a 5.

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

All Free Agent Tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.