Skip to main content
Glama

日本の給与・社会保険・労働法

by io.github.kishida-devil

賞与の社会保険料と源泉所得税

calculate_bonus

Premiums and income tax on a 賞与. Both work differently from monthly pay and are routinely got wrong.

Premiums are charged on 標準賞与額 (the bonus truncated to the thousand yen) under two caps that behave differently: health, long-term care and child support cap at 5,730,000 yen CUMULATIVELY across the fiscal year from 1 April, while pension caps at 1,500,000 yen PER PAYMENT. The annual cap cannot be applied without fiscal_year_to_date, so pass it whenever an earlier bonus was paid in the same fiscal year.

Withholding tax on a bonus is derived from the PREVIOUS month's pay, not from the bonus itself. Set include_tax to also compute it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ageNoAge in years. Either this or birth_date is required. Prefer birth_date.
as_ofNoYYYY-MM-DD. Which rate table to use. Rates change every March, so a bonus paid in a previous year needs the table that was in force then; the call is refused rather than answered with today's rates.
bonusYesGross bonus in yen.
columnNoWithholding column for the tax half: 甲 when a 扶養控除等申告書 was filed (the normal case), 乙 when it was not. 乙 has its own rate table. Defaults to 甲.
birth_dateNoDate of birth, YYYY-MM-DD. Strongly preferred over `age`: 年齢計算ニ関スル法律 puts the attainment of an age on the day *before* the birthday, so someone born on the 1st of a month crosses a threshold in the previous month and their premium changes a month earlier than a naive calculation gives.
dependantsNo
prefectureYesPrefecture of the employer's 適用事業所 — English ("Tokyo"), Japanese ("東京" or "東京都"), or JIS code 1-47. Health insurance rates differ by prefecture; pension does not.
include_taxNoAlso compute withholding tax. Requires previous_month_pay.
previous_month_payNoGross pay in the month before the bonus. The tax rate is derived from this.
fiscal_year_to_dateNo標準賞与額 already paid since 1 April this fiscal year. Needed for the annual health cap.
previous_month_insuranceNoSocial insurance deducted from that previous month's pay.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and discloses non-obvious behavior: premiums are based on 標準賞与額 truncated to thousands, health/long-term care/child support cap cumulatively at ¥5,730,000 while pension caps per payment at ¥1,500,000, and tax derives from the previous month's pay rather than the bonus. It also surfaces the dependency on fiscal_year_to_date for the annual cap, which is exactly the kind of hidden calculation nuance an agent needs.

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

Conciseness5/5

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

Three compact paragraphs front-load the purpose, then give the two core calculation rules (premium caps and tax basis) in order of importance. Every sentence carries necessary information; the 'routinely got wrong' warning is the only editorial addition and it reinforces why the tool exists.

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 an 11-parameter calculation tool with no output schema, the description covers the hard decision points: when to pass fiscal_year_to_date, when to set include_tax, and how the caps differ. It does not describe the return shape, but the input schema supplies parameter-level details such as as_of refusal behavior and the birth_date rule, so the agent can invoke the tool correctly.

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

Parameters4/5

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

Schema description coverage is already 91%, so the baseline is 3; the description then adds real semantic value by explaining what 標準賞与額 means (truncation), why fiscal_year_to_date matters, and how previous_month_pay feeds tax withholding. It does not discuss every parameter, but the schema already documents age, birth_date, as_of, and column in detail.

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

Purpose4/5

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

The description clearly identifies the tool as computing social insurance premiums and withholding income tax on a bonus (賞与), with 'Set include_tax to also compute it' confirming the calculate action. It does not explicitly name sibling tools or say 'use this instead of calculate_withholding_tax', but the bonus-specific caps and contrast with monthly pay make the scope unambiguous.

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 situational guidance: pass fiscal_year_to_date whenever an earlier bonus was paid in the same fiscal year, and set include_tax when withholding tax is also needed. It does not directly state which sibling tools are alternatives or when not to use this tool, but 'Both work differently from monthly pay' implies the bonus context.

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

All 日本の給与・社会保険・労働法 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have distinct, well-defined jobs—payroll calculations, revision judgments, eligibility checks, and data lookups are clearly separated. The main remaining risk is among the standard-remuneration judgment tools and the batch/singleton pairs, but their descriptions are detailed enough to prevent serious misselection.

Naming Consistency3/5

There is a reasonably recognizable pattern with calculate_, judge_, check_, get_, and validate_ groups. However, several noun-phrase names (business_days, consumption_tax, national_insurance, commuting_allowance_exemption) and overlapping verb choices (decide_ vs judge_ vs check_) prevent a fully consistent verb_noun convention.

Tool Count2/5

At 30 tools, the surface is materially larger than the 3–15 range that keeps an agent's selection burden low. Batch variants and three separate standard-remuneration revision tools add complexity, and although the domain is broad, the count feels heavy for an assistant to choose from confidently.

Completeness4/5

The core workflows are well covered: monthly pay, bonuses, overtime, standard-remuneration determination, year-end adjustment, resident tax, leave, worker classification, and invoice validation. Gaps exist around statutory benefit payments such as sickness or maternity allowances and retirement-specific processing, but most payroll and social insurance tasks can be completed without dead ends.

Resources