Free Agent Tools

Big medical bill in Japan: what's my 高額療養費 monthly cap, how much comes back, does the new yearly cap apply, and what changes in Aug 2027?

japan_high_cost_medical_check

Read-onlyIdempotent

Applies Japan's high-cost medical expense benefit (高額療養費) as of 2026-11-04 (MHLW review tables 001726232.pdf, 協会けんぽ, Setagaya / Machida / Fukuoka NHI pages). Monthly cap = base + max(0, 10割 total − threshold) × 1% (flat for lower bands), three schedules by treatment month: up to 2026-07; 2026-08…2027-07 (≈7% higher, e.g. income ¥3.7M–7.7M 85,800 + (x − 286,000) × 1%, ≤ ¥3.7M ¥61,500, tax exempt ¥36,900); from 2027-08 twelve bands (e.g. ¥5.1M–6.5M 98,100 + (x − 327,000), ¥6.5M–7.7M 110,400 + (x − 368,000), ¥16.5M+ 342,000 + (x − 1,140,000)). 多数回該当 from the 4th benefit month in 12 (140,100 / 93,000 / 44,400 / 24,600; 34,500 for ≤ ¥2M from 2027-08). New yearly cap per Aug–Jul on what was paid after monthly refunds (¥1.68M / ¥1.11M / ¥530k / ¥410k / ¥290k / 70+ 低所得I ¥180k). 70+ outpatient caps (一般 ¥18,000 → ¥22,000 → ¥28,000/¥22,000, yearly ¥216,000). Income one way: band (y1650, y1410, y1160, y1040, y950, y770, y650, y510, y370, y260, y200, y0, nontaxable, nontaxable_low; ア/イ/ウ/エ/オ accepted), standardMonthlyRemuneration (標準報酬月額), nhiIncome (旧ただし書き所得), taxableIncome (70+ 課税所得), rough annualIncome, or nonTaxable. Optional months tracker (array [{month, totalCost|copay, setting}] or '2026-08:300000,2026-09:300000') auto-applies 多数回 and the yearly cap. Returns verdict (under_cap | cap_applies | many_times_cap | annual_cap_reached), summary, band, schedule, month {monthlyCap, formula, youPay, monthlyRefund, manyTimes}, caps, annualCap {period, amount}, from2027 {youPay, changeJPY}, beforeAug2026, claim {deadline: 2 years from the 1st of the next month}, tracker, steps, notCounted, sources, disclaimer. Use for '高額療養費いくら戻る', '自己負担限度額計算', '高額療養費 2027年8月変更', '年間上限', 'hospital bill Japan how much will I pay', 'Japan medical cost cap'. Insured care only (meals, private rooms, 先進医療 excluded). Educational estimate, not medical, financial or legal advice; the insurer decides.

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_high_cost_medical_check"
  }
}

Input Schema

Name	Required	Description
`band`	No	Income band (y370 = income about ¥3.7M–5.1M).
`copay`	No	Insured copay paid at the counter (窓口負担) in yen; give this or totalCost.
`month`	No	Treatment month YYYY-MM (default this month JST); picks the schedule.
`months`	No	Yearly tracker: [{month, totalCost\|copay, setting}] or '2026-08:300000,2026-09:300000'.
`setting`	No	inpatient / household total (default) or outpatient (70+ outpatient-only cap).
`ageGroup`	No	under70 (default) or 70plus (70–74 and 75+ 後期高齢者).
`manyTimes`	No	Already had a benefit in 3+ of the last 12 months (多数回).
`nhiIncome`	No	NHI 旧ただし書き所得 (household) in yen.
`totalCost`	No	10割 total medical cost (総医療費) in yen.
`burdenRate`	No	Copay rate 0.1 / 0.2 / 0.3 (default by age and band).
`nonTaxable`	No	Resident-tax exempt household (住民税非課税).
`annualIncome`	No	Rough annual income (年収) in yen.
`taxableIncome`	No	70+: 課税所得 in yen.
`priorHitMonths`	No	Benefit months in the 12 months before.
`standardMonthlyRemuneration`	No	Employee insurance 標準報酬月額 in yen (e.g. 300000).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly/non-destructive/idempotent/closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the three schedule windows by treatment month, that the optional months tracker auto-applies the 多数回 and yearly caps, the default month (this month JST), and a clear caveat that results are educational estimates with the insurer as final arbiter. It stops short of describing fallback/error behavior when no income input is supplied.

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 opening clause is well front-loaded, but the body is a dense run of formula fragments, yen thresholds, and 2027 band tables that an agent does not need in order to select or invoke the tool. The information is accurate and earns some place as transparency into the calculation, yet the paragraph form makes the operationally relevant parts hard to extract.

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

Completeness4/5

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

For a 15-parameter, zero-required calculator with no output schema, the description compensates well: it enumerates the returned fields (verdict, month.monthlyCap, annualCap, from2027, claim.deadline, tracker, sources, disclaimer) and the verdict values. The one remaining gap is guidance on what happens when income-defining inputs are omitted entirely.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3 and the schema already explains each parameter including the band enum. The description adds one genuinely useful semantic the schema does not: 'Income one way' — that band, standardMonthlyRemuneration, nhiIncome, taxableIncome, annualIncome, or nonTaxable are mutually exclusive routes to income classification. Beyond that it mostly restates band values and thresholds rather than adding input guidance.

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?

States a specific verb and resource — 'Applies Japan's high-cost medical expense benefit (高額療養費) as of 2026-11-04' — and immediately enumerates what it computes: monthly cap, refund amount, yearly cap, and the Aug 2027 changes. No sibling tool in the list touches medical cost caps, so the scope is unmistakable.

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?

Gives concrete trigger phrases ('高額療養費いくら戻る', '自己負担限度額計算', '年間上限', 'hospital bill Japan how much will I pay') and an explicit scope boundary: 'Insured care only (meals, private rooms, 先進医療 excluded)'. It does not name an alternative tool to use instead, but no comparable sibling exists, so the practical gap is small.

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.