Skip to main content
Glama

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

by io.github.kishida-devil

年末調整(令和8年分)

calculate_year_end_adjustment

Year-end adjustment (年末調整) for 2026 from the National Tax Agency's 令和8年分 booklet: the printed 給与所得控除後の給与等の金額 table (1,103 rows), the income-adjustment deduction, social/life/earthquake insurance deductions, spouse, specified-relative (19-22 with income), dependant, disability, widow/single-parent/student and basic deductions, the year-end tax bracket table, the housing-loan credit and the 2.1% reconstruction surtax. Returns every box of the 源泉徴収簿 (⑦ to ㉗) and whether the difference is a refund or a collection.

Pay figures are for the whole calendar year, bonuses included. Pass only what the employee declared on their forms; the tool does not assume a spouse, dependants or insurance. Anyone paid 20,000,000 yen or more is outside 年末調整 and the tool says so. Medical, donation and casualty-loss deductions are not part of 年末調整 (they need a tax return) and resident tax is never involved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
flagsNo
spouseNo
total_payYesTotal pay for the year including bonuses (⑦).
dependantsNo
mutual_aidNo小規模企業共済等掛金 (⑭).
tax_returnNoDeductions that only a tax return can take (medical, self-medication, donations, casualty loss). They are NOT part of 年末調整; pass them to get a separate "if the employee files a return" estimate.
disabilitiesNoCounts of 障害者 / 特別障害者 / 同居特別障害者 among the employee, spouse and dependants.
other_incomeNoIncome other than this pay, for the basic and spouse deduction bands.
withheld_taxYesIncome tax withheld during the year (⑧).
life_insuranceNoPremiums PAID this year by category (new = contracts from 2012-01-01). The deduction is computed here.
social_insuranceYesSocial insurance premiums deducted from pay during the year (⑫).
income_adjustmentNoForce the 所得金額調整控除 on or off. Omit to derive it from pay > 8,500,000 and the under_23 / disability inputs.
housing_loan_creditNo住宅借入金等特別控除額 (㉔), from the certificate.
specified_relativesNo特定親族 (19-22 with 合計所得金額 over 620,000): one income figure per person.
earthquake_insuranceNoEarthquake insurance and 旧長期損害保険 premiums paid.
social_insurance_declaredNoSocial insurance the employee paid themselves and declared, e.g. 国民年金 (⑬).

Schema Changelog

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

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden and does it well: it states what the tool returns, that it does not assume unprovided inputs, that high earners are rejected, and that certain deductions are excluded. It could add more about error handling or whether the operation is purely computational, but the disclosed behavior is substantial.

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

Conciseness4/5

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

The description is long because the tool is complex, but the first paragraph front-loads the overall purpose and output, while the second paragraph delivers crucial boundary conditions. Every sentence adds information; the only minor issue is the dense enumeration of deductions, which partially duplicates schema content.

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?

For a 16-parameter tool with no annotations and no output schema, this description is remarkably complete: it defines the return value, scope, exclusions, assumptions, and edge cases such as the 20,000,000 yen threshold. The input schema covers the remaining parameter details, so an agent has enough context to 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 coverage is 81%, so the baseline is 3, but the description adds meaningful parameter-level context: pay and withheld figures are for the whole calendar year, only declared values should be passed, and the tax_return block is explicitly clarified as not part of 年末調整. This goes beyond the schema's property descriptions and helps the agent pass values correctly.

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 makes the tool's function clear: it performs Japanese year-end adjustment for 2026 and returns every box of the 源泉徴収簿 plus refund/collection status. It is specific about scope and contents, though it does not explicitly differentiate itself from sibling tools like calculate_withholding_tax.

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?

The second paragraph gives practical usage constraints: pay must cover the whole year including bonuses, only declared amounts should be passed, the tool does not assume family/insurance status, 20,000,000 yen or more is outside scope, and medical/donation/casualty-loss deductions belong to a tax return. This is strong guidance, but it does not name alternative sibling tools explicitly.

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