Skip to main content
Glama
skypier-jp-works

mcp-jp-paid-leave

by skypier-jp-works
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

mcp-jp-paid-leave

日本語版 README はこちら

An MCP (Model Context Protocol) server for calculating Japan's statutory annual paid leave ("nenkyu") under the Labor Standards Act: entitlement grants, attendance-rate checks, proportional grants for part-time workers, carryover/prescription, and the 5-day mandatory-use rule. It lets MCP-capable clients such as Claude Desktop invoke these calculations directly.

No network access is used at runtime. All statutory rules are embedded as constants in the code.

Core design principle

  • Every number and judgment this server returns is the statutory minimum under the Labor Standards Act.

  • Any company policy that grants more than the statutory minimum must be passed explicitly as an argument to apply_company_policy.

  • Every tool response includes a basis field:

    • "legal_minimum": the statutory minimum value

    • "company_policy_applied": the value after applying a company policy (only from apply_company_policy)

  • If a company policy value is below the statutory minimum, apply_company_policy automatically corrects it to the statutory minimum and returns a warning.

  • Resilience to legal amendments: rules that are known to have changed as of a specific effective date (such as the standard grant-days table) are stored as "rule generations with an effective date," and the generation valid at the calculation-target date is selected automatically. Calculating for a past period still uses the rules that were in force at that time. Every tool response includes a meta field with the effective date and source URL of each rule actually used, the date the data was last verified (dataVerifiedOn), and a staleness warning when applicable. See Versioning policy and Maintenance policy below.

Related MCP server: leave_manager

Disclaimer

  • This tool computes the statutory minimum under the Labor Standards Act. The accuracy of its output is not guaranteed.

  • If your work rules (shugyo kisoku) provide more favorable terms to employees, those always take precedence over this tool's output.

  • For any important labor/HR decision (including anything touching discipline, dismissal, or payroll), always confirm with a qualified professional (e.g., a licensed Shakai Hoken Roumushi / labor and social security attorney).

Tools (7 total)

Tool

Description

calculate_entitlement

Computes the grant date and number of days for a given grant occurrence, from hire date and reference-date method

check_attendance_rate

Checks whether the 80% attendance-rate requirement is met, with a numerator/denominator breakdown

list_grant_schedule

Lists the grant schedule for a given number of years from the hire date

proportional_entitlement

Computes the proportional grant for part-time workers, based on weekly/annual scheduled working days

calculate_carryover

Computes carryover, forfeiture under the 2-year prescription period, and remaining balance

check_mandatory_five_days

Determines whether an employee is subject to the mandatory 5-day rule, and reports compliance status

apply_company_policy

Applies a company policy on top of the statutory minimum, correcting and warning if it falls short

1. calculate_entitlement

Give the hire date (hireDate) and which grant occurrence to compute (grantNumber: 1 = the first grant at 6 months of service, 2 = the second grant at 1 year 6 months, etc.).

  • referenceDateMethod: "individual" (the statutory default — each employee's own basis date) or "uniform" (a company-wide unified basis date, i.e. "seiitsu-teki toriatsukai")

  • uniformBasisMonthDays: required when uniform is used — an array of "MM-DD" candidate basis dates (e.g. ["04-01"] or ["04-01","10-01"])

  • weeklyScheduledDays / annualScheduledDays / weeklyScheduledHours: optional, for proportional grants (part-time workers)

For the uniform method, the server correctly computes the recurring chain: once the first front-loaded basis date is found, every subsequent grant recurs on the same month/day each year. Any period shortened by front-loading is returned as shortenedPeriod, with a note that this period must be treated as fully attended for attendance-rate purposes (when calling check_attendance_rate, count it as ordinary worked days in actualWorkedDays etc. rather than as absence — don't carve it out as unattended).

Returns an error if the statutory basis date (statutoryBasisDate, not the hire date) falls before 2001-04-01. The current grant-days table (introduced by Act No. 112 of 1998) took effect for most purposes on 1999-04-01, but a transitional schedule with lower figures for certain tenure brackets applied through 2001-03-31. This tool does not implement that transitional schedule, so 2001-04-01 (once the transition was fully complete) is the verified floor (see Versioning policy and CHANGELOG.md).

This floor applies to each grant's own basis date, not to the hire date. No matter how old the hire date is, a specific grant computes fine as long as that grant's basis date is on or after 2001-04-01. For example, for an employee hired in 1995, computing "the most recent grant as of 2026" (the 31st grant, basis date 2025-10-01) succeeds. Only grants whose own basis date is before 2001-04-01 (e.g. that same employee's 1st grant, basis date 1995-10-01) return an error.

2. check_attendance_rate

Checks the "80% of all working days" requirement for entitlement.

Design principle: deciding whether a given day belongs in the numerator or is excluded from the denominator is exactly the value this tool should provide — and exactly where humans and AI callers are most likely to get it wrong. So the caller does not classify anything. Instead, break the period down into the following 11 day-count fields and pass them as-is (all required except asOfDate — if a category doesn't apply, pass 0 explicitly; omitting a field is an error, not an assumed zero):

Argument

Meaning

scheduledWorkingDays

Total scheduled working days for the period (days with a work obligation; excludes scheduled days off)

actualWorkedDays

Days actually worked

paidLeaveTakenDays

Days of annual paid leave taken

workInjuryOrIllnessLeaveDays

Days on leave for a work-related injury or illness

maternityLeaveDays

Days of maternity leave (Labor Standards Act Article 65)

childcareOrFamilyCareLeaveDays

Days of childcare or family-care leave

employerCausedSuspensionDays

Days suspended for reasons attributable to the employer (including employer-caused management/operational-obstacle suspension)

lawfulLaborDisputeDays

Days with no work provided due to a lawful strike/labor dispute

forceMajeureSuspensionDays

Days suspended due to force majeure

workedOnScheduledDayOffDays

Days worked on what was originally a scheduled day off — not included in scheduledWorkingDays

otherAbsenceDays

Ordinary absence not covered by any category above (unauthorized absence, personal illness, etc.)

scheduledWorkingDays must equal the sum of the other 9 fields (everything except workedOnScheduledDayOffDays). A mismatch is an error — the tool never guesses at a reconciling number.

Based on Labor Standards Act Article 39 paragraph 10 / Article 65, Directive Hakki No. 17 (Sept. 13, 1947), and Directive Kihatsu 0710 No. 3 (July 10, 2013), the tool classifies each field into one of four treatments internally:

  • Added to the numerator: actualWorkedDays, paidLeaveTakenDays, workInjuryOrIllnessLeaveDays, maternityLeaveDays, childcareOrFamilyCareLeaveDays

  • Ordinary absence (stays in the denominator, not added to the numerator): otherAbsenceDays

  • Excluded from total working days (the denominator): employerCausedSuspensionDays, lawfulLaborDisputeDays, forceMajeureSuspensionDays (Kihatsu 0710 No. 3, Section 1-3)

  • Not counted at all (never a scheduled working day to begin with): workedOnScheduledDayOffDays (Kihatsu 0710 No. 3, Section 1-1)

The result's breakdown.classification always includes each field's day count, its resulting treatment, and the specific legal basis (statute or directive) for that treatment.

3. list_grant_schedule

Same arguments as calculate_entitlement, plus numberOfYears (how many grant occurrences to list).

For long-tenured employees whose early grants have a basis date before the verified floor (2001-04-01), the call as a whole no longer fails. Those specific grants are returned as supported: false placeholders (no grant-days figure), while every other grant is computed normally with supported: true. Check the supported field on each entry.

4. proportional_entitlement

Computes the proportional grant from weekly scheduled days (1–4) or annual scheduled days. Returns an error if weekly scheduled hours are 30 or more, or weekly scheduled days are 5 or more (such workers use the standard table instead).

5. calculate_carryover

  • grants: array of grant records (grantDate, grantedDays)

  • usageRecords: array of usage records (date, days)

  • asOfDate: the date to evaluate as of

Each grant expires 2 years after its grant date (Labor Standards Act Article 115). Usage is consumed against the oldest grant first (this is common practice, not an explicit statutory rule — follow your work rules if they specify otherwise).

6. check_mandatory_five_days

For employees granted 10 or more days of annual paid leave, determines compliance with the employer's obligation to have the employee use 5 days within 1 year of the grant date (Labor Standards Act Article 39, paragraphs 7–8). Days taken at the employee's own request, or via a planned-leave scheme, count against the 5-day requirement.

This obligation itself was introduced by an amendment that took effect on April 1, 2019. If the grant date (grantDate) is earlier than that, the tool reports the employee as not subject to the rule regardless of the number of days granted, since the obligation did not yet exist.

7. apply_company_policy

Pass legalMinimumDays (the statutory minimum computed by another tool) and companyPolicyDays (optional — your company's policy value). If the company policy falls short of the statutory minimum, the result is automatically corrected to the statutory minimum, with a warning.

The meta field on every response

Every tool response includes a meta block, separate from the statutory calculation itself:

"meta": {
  "dataVerifiedOn": "2026-07-28",
  "rulesUsed": [
    {
      "rule": "Standard grant-days table (Labor Standards Act Article 39)",
      "effectiveFrom": "2001-04-01",
      "sources": [{ "label": "...", "url": "https://..." }]
    }
  ],
  "staleWarning": null
}

  • dataVerifiedOn: the date this server's data was last checked against primary sources.

  • rulesUsed: the rules actually used to compute this response, with their effective date (only when verified) and source URL.

  • staleWarning: a bilingual (Japanese/English) warning message when either of the following applies (otherwise null):

    • more than 6 months have passed since dataVerifiedOn (compared against the actual current time), or

    • the calculation-target date is more than 2 years past the verification date (a legal amendment may have occurred by then).

Versioning policy

  • Any update to statutory data (grant-days tables, proportional-grant table, eligibility requirements, etc.) bumps the minor version (e.g. 1.1.0 → 1.2.0). Patch versions are reserved for bug fixes and documentation.

  • Any breaking change to a tool's arguments (adding/removing/changing the meaning of a parameter such that existing callers break) bumps the major version (e.g. 1.3.0 → 2.0.0).

  • Statutory data and spec changes are recorded in CHANGELOG.md, noting when and which amendment or change was addressed.

  • Past legal amendments accumulate as "rule generations with an effective date." Existing generations are never rewritten — a new generation is added instead, so past-period results remain unaffected.

Maintenance policy

  • The maintainer intends to update src/leaveRules.ts whenever the Labor Standards Act, its enforcement regulations, or related MHLW notices/directives are amended. Since this server never makes network calls at runtime, reflecting an amendment requires a manual update.

  • If you are aware of a legal amendment (its effective date and what changed), please report it via GitHub Issues: https://github.com/skypier-jp-works/mcp-jp-paid-leave/issues

  • Before making an important labor/HR decision, check meta.dataVerifiedOn and meta.staleWarning, and consult the latest law or a qualified professional as needed.

Sources (primary references)

The statutory rules were implemented after actually retrieving and checking the following primary sources — not from memory (last checked: 2026-07-28). If these figures change due to a legal amendment, src/leaveRules.ts must be updated manually (this server never makes network calls at runtime).

Unverified items (honest disclosure)

  • When the proportional grant table took its current form has not been confirmed. Its values match the current e-Gov text, but no effective date is asserted (see PROPORTIONAL_GRANT_TABLE in src/leaveRules.ts).

  • Whether the 80% attendance threshold or the 2-year prescription period have ever changed since enactment has not been checked — only that they match the current statutory text.

  • The 2-year prescription period (Labor Standards Act Article 115) does not name "annual paid leave" in its text. It is a general rule ("claims other than wage claims: 2 years"); that paid-leave claims fall under it rests on administrative interpretation and established practice, not an explicit statutory reference.

  • The exact grant-days figures that applied before 2001-04-01 (including during the 1999–2001 transitional period) have not been verified. Calculations for that period return an error.

Setup

1. Requirements

node --version

2. Install dependencies

npm install

3. Build

npm run build

This produces build/index.js.

Using it from Claude Desktop

Add the following to your Claude Desktop config file (claude_desktop_config.json):

{
  "mcpServers": {
    "jp-paid-leave": {
      "command": "node",
      "args": ["/absolute/path/mcp-jp-paid-leave/build/index.js"]
    }
  }
}

Config file location:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Restart Claude Desktop afterward to make tools like calculate_entitlement available.

Running tests

38 automated tests cover all functionality:

npm test

All lines should show ✔ (pass).

Project structure

mcp-jp-paid-leave/
├── src/
│   ├── leaveRules.ts  … statutory rule constants (generations with effective dates), source citations
│   ├── dataMeta.ts    … rule-generation selection + staleness-warning infrastructure
│   ├── errors.ts      … shared validation error class
│   ├── dateUtil.ts    … shared date-arithmetic utilities
│   ├── leaveCalc.ts   … core calculation logic (entitlement, attendance rate, carryover, etc.)
│   └── index.ts       … the MCP server itself (exposes the 7 tools)
├── tests/
│   ├── leaveCalc.test.ts … automated tests
│   └── dataMeta.test.ts  … tests for rule-generation selection and staleness warnings
├── package.json
├── tsconfig.json
├── CHANGELOG.md       … record of statutory-data updates and spec changes
├── LICENSE
├── README.md          … this file
└── README.ja.md        … Japanese version

Related tools

Other MCP servers by the same author:

  • mcp-jp-calendar — calculates Japanese business days, national holidays, gotobi settlement days, and fiscal quarters

  • mcp-jp-corporate-id — validates and normalizes Japanese corporate numbers and qualified invoice registration numbers

License

MIT

Available Tools

7 tools
apply_company_policy自社規程の上乗せを適用A

法定最低基準の日数に、自社規程による上乗せ設定を適用します。自社規程が法定を下回る場合は、法定最低基準に補正した上で警告を返します(労働基準法第13条)。

ParametersJSON Schema
NameRequiredDescriptionDefault
legalMinimumDaysYes他のツールで計算した法定最低基準の日数
companyPolicyDaysNo自社規程で定めている日数(省略時は法定最低基準をそのまま返す)

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It discloses that the tool corrects policy below legal minimum and returns a warning. However, it does not mention whether the operation is destructive, idempotent, or requires authorization. For a mutation tool, more behavioral context is needed.

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?

The description is two sentences, front-loaded with the primary action, and adds the special case in the second sentence. No redundant information; every sentence adds value.

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

Completeness3/5

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

The tool has no output schema and the description does not explain what is returned (e.g., adjusted days, warning object). It also lacks information on error handling beyond the warning case. Given the simplicity, more details on return format would improve completeness.

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 schema already documents both parameters. The description adds no new semantic information beyond echoing the parameter roles. Baseline score of 3 is appropriate.

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 description clearly states the tool applies company policy additions on top of legal minimum days, and includes corrective behavior when policy is below legal. The verb ('apply') and resource ('company policy addition') are specific, and the tool is distinct from siblings like calculate_entitlement.

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

Usage Guidelines3/5

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

The description implies the tool is used after legal minimum days are computed, but it does not explicitly state when to use it versus alternatives (e.g., calculate_entitlement or check_attendance_rate). No exclusion criteria or 'when not to use' guidance is provided.

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

calculate_carryover繰越・時効消滅日数の計算A

複数回の付与記録と取得記録から、時効2年(労働基準法第115条)による消滅日数と、基準日時点の残日数を計算します。取得は古い付与分から順に消化するものとして計算します。

ParametersJSON Schema
NameRequiredDescriptionDefault
grantsYes付与記録の配列(複数年分をまとめて渡せる)
asOfDateYes基準日(この日時点の残日数・消滅日数を計算する) (YYYY-MM-DD形式、例: 2026-08-15)
usageRecordsNo年次有給休暇を取得した記録の配列(省略時は消化なしとして計算)

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the FIFO consumption assumption and the computation of expiration and remaining days, though it does not mention side effects or permissions (likely read-only).

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?

The description is two sentences, front-loading the purpose then providing one key behavioral detail. No redundant information.

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?

Given the complexity (multiple grants, usage records, FIFO, statute) and no output schema, the description covers inputs, outputs, and calculation logic adequately. Lacks edge case handling but sufficient for typical use.

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 schema already documents each parameter. The description adds no additional per-parameter detail beyond overall context, setting a baseline of 3.

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 description clearly states the tool calculates expiration days under the 2-year statute and remaining days as of a reference date using multiple grant and usage records. It is distinct from sibling tools like check_attendance_rate or calculate_entitlement.

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

Usage Guidelines3/5

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

The description explains the calculation method (FIFO consumption) and inputs, but does not explicitly state when to use this tool over alternatives or provide exclusions.

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

calculate_entitlement年次有給休暇の付与日・付与日数を計算A

入社日と算定基準日方式(原則の個別付与/斉一的取扱い)から、指定した回(第何回目)の年次有給休暇の付与日と付与日数(法定最低基準)を計算します。斉一的取扱いでは前倒しの連鎖を計算し、前倒しにより短縮された期間も返します。検証済み下限日(2001-04-01)はその回の基準日(算定基準日)にかかるものであり、入社日自体が古くても、指定した回の基準日が下限以降であればエラーにはなりません。

ParametersJSON Schema
NameRequiredDescriptionDefault
hireDateYes入社日 (YYYY-MM-DD形式、例: 2026-08-15)
grantNumberYes付与回数(第何回目の付与か)。1=第1回(雇入れ後6ヶ月時点), 2=第2回(1年6ヶ月時点)... 7以降は第7回以降(6年6ヶ月以上)としてすべて同じ日数上限になる
annualScheduledDaysNo1年間の所定労働日数(週所定労働日数が不定の場合に指定。指定するとweeklyScheduledDaysより優先される)
referenceDateMethodNo基準日の算定方式。"individual"=原則どおり労働者ごとに個別付与(省略時のデフォルト)。"uniform"=斉一的取扱い(全労働者共通の基準日に統一して前倒し付与)
weeklyScheduledDaysNo週所定労働日数(比例付与を計算したい場合に指定。1〜4日で比例付与対象、5日以上は通常の労働者扱い)
weeklyScheduledHoursNo週所定労働時間(任意。30時間以上の場合は比例付与の対象外であることの検証に使う)
uniformBasisMonthDaysNo斉一的取扱い(uniform)で使う、会社共通の基準日候補("MM-DD"形式の配列。例: ["04-01"] や ["04-01","10-01"])。referenceDateMethodが"uniform"の場合は必須

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description fully discloses behavior: it calculates based on legal minimum, handles uniform method with chain of early grants, and validates a lower bound date. It does not explicitly state it is read-only, but as a calculation tool, that is implied.

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 a single paragraph of four sentences, front-loading the main purpose. It is concise without waste, though a slightly more structured format (e.g., bullet points for return values) could improve readability.

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

Completeness3/5

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

The description covers core calculation and two methods, and mentions return values (grant date, days, shortened period for uniform). However, without an output schema, it lacks details on the exact format of the response, which is needed for a 7-parameter tool.

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 coverage is 100%, so the description adds minimal extra meaning beyond the schema. The description provides some behavioral context for parameters (e.g., the lower bound check) but does not enhance individual parameter understanding significantly.

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 description clearly states the tool calculates annual paid leave entitlement (grant date and days) based on hire date and reference date method, distinguishing between individual and uniform methods. It is distinct from sibling tools like check_attendance_rate or list_grant_schedule.

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

Usage Guidelines3/5

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

The description implies usage through its purpose but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or context for choosing this over sibling tools.

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

check_attendance_rate出勤率8割の判定A

年次有給休暇の付与要件である出勤率8割を満たすか判定します。呼び出し側は「分子に加算すべきか」「分母から除外すべきか」を判断する必要はありません。算定期間中の日数を種類別にそのまま渡してください。分類(分子への算入・分母からの除外・全労働日への不算入・通常欠勤のいずれに当たるか)は、労働基準法第39条第10項および平成25年7月10日基発0710第3号に基づき、このツール内部で行います。すべての日数は必須です(該当がなければ0を指定してください。省略や推測による補完はできません)。scheduledWorkingDaysは、workedOnScheduledDayOffDaysを除く他の9つの日数区分の合計と一致している必要があり、一致しない場合はエラーになります。判定結果には、各区分をどう分類したか(分母・分子への算入方法と根拠条文)を示す内訳を必ず含めます。

ParametersJSON Schema
NameRequiredDescriptionDefault
asOfDateNoこの判定の対象期間の終了日等(任意)。データ陳腐化の警告判定にのみ使用する (YYYY-MM-DD形式、例: 2026-08-15)
actualWorkedDaysYes実出勤日数。実際に出勤して労働した日数(年次有給休暇取得日・各種休業日は含まない)
otherAbsenceDaysYes上記のいずれにも該当しない、通常の欠勤日数(無断欠勤、私傷病による欠勤、遅刻・早退による全休扱いなど)。分母には含むが分子には算入しない
maternityLeaveDaysYes産前産後休業(労働基準法第65条)により休業した日数
paidLeaveTakenDaysYes年次有給休暇を取得した日数
scheduledWorkingDaysYes所定労働日数の合計(算定期間中に労働義務があった日数)。所定休日は含まない。下記の actualWorkedDays + paidLeaveTakenDays + workInjuryOrIllnessLeaveDays + maternityLeaveDays + childcareOrFamilyCareLeaveDays + employerCausedSuspensionDays + lawfulLaborDisputeDays + forceMajeureSuspensionDays + otherAbsenceDays の合計(workedOnScheduledDayOffDaysは含まない)と一致させること
lawfulLaborDisputeDaysYes正当な同盟罷業その他正当な争議行為により労務の提供が全くなされなかった日数
forceMajeureSuspensionDaysYes天災事変等、不可抗力による休業日数
workedOnScheduledDayOffDaysYes所定休日(もともと労働義務のない日、例: 会社カレンダー上の休日)に労働させた日数。この日数はscheduledWorkingDaysには含めない(そもそも所定労働日ではないため)
employerCausedSuspensionDaysYes使用者の責に帰すべき事由による休業日数(使用者側の経営上・管理上の障害による休業を含む。例: 発注元の都合による事業場閉鎖、資材不足による休業)
workInjuryOrIllnessLeaveDaysYes業務上の負傷又は疾病により療養のため休業した日数(私傷病による欠勤は含まない。私傷病はotherAbsenceDaysに含める)
childcareOrFamilyCareLeaveDaysYes育児休業・介護休業等育児又は家族介護を行う労働者の福祉に関する法律に規定する育児休業又は介護休業をした日数

TDQS

A4.1/5.0
Behavior4/5

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

Without annotations, description carries full burden. It discloses that classification is done internally based on legal standards, that a sum constraint must hold, and that output includes a breakdown with legal basis. This provides substantial behavioral context beyond the input schema.

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?

Description is long but front-loaded with purpose, then instructions, then constraints. Each sentence serves a purpose. No redundancy. Given complexity (legal rules, 12 parameters), this is appropriately concise.

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 complex tool with 12 required parameters and legal logic, description covers purpose, usage constraints, parameter relationships, and output inclusion (breakdown). No output schema exists, so description's promise of breakdown is sufficient. Minor gap: no explicit return format, but not needed.

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 100%, baseline 3. Description adds value by explaining that caller should not classify, that all days are required, and the critical relationship between scheduledWorkingDays and other fields. This compensates for the high parameter count (12) and clarifies usage.

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?

Description clearly states it determines whether attendance rate meets 80% threshold for annual paid leave, using a specific verb ('判定する') and resource ('出勤率8割の判定'). It distinguishes from siblings like check_mandatory_five_days by focusing on attendance rate rather than mandatory five days or carryover.

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

Usage Guidelines3/5

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

Description provides clear constraints: caller must pass raw days, all days required, sum constraint. However, it does not explicitly state when to use this tool versus siblings (e.g., check_mandatory_five_days vs calculate_entitlement). No 'when not to use' or alternative tool mentions.

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

check_mandatory_five_days年5日取得義務の充足判定B

年10日以上の年次有給休暇が付与される労働者を対象とする、年5日取得義務(労働基準法第39条第7項・第8項)の対象者判定と、充足状況・残り必要日数を返します。

ParametersJSON Schema
NameRequiredDescriptionDefault
asOfDateNo判定基準日(任意。省略可) (YYYY-MM-DD形式、例: 2026-08-15)
grantDateYes付与日(基準日) (YYYY-MM-DD形式、例: 2026-08-15)
grantedDaysYesその基準日に付与された年次有給休暇の日数
plannedGrantDaysNo計画年休制度により取得させた日数(5日から控除できる)
employeeRequestedDaysNo労働者自らの請求・取得により取得した日数(5日から控除できる)
employerDesignatedDaysNo使用者が既に時季指定して取得させた日数

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool returns determination and remaining days, implying a read-only query, but does not explicitly state side effects, authorization needs, or rate limits. The description is adequate but minimal for a check tool.

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 a single, dense sentence that conveys the essential information without fluff. It is front-loaded with the target condition and then states the outputs. However, it could be broken into multiple sentences for readability, but it earns a high score for conciseness.

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

Completeness3/5

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

Given the tool's complexity (legal requirement, 6 parameters, no output schema), the description explains the legal basis and what it returns (determination and remaining days), but it does not specify the return format or how parameters interact. With full schema coverage, it is adequate but could be more complete.

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 each parameter has a description. The tool description adds no parameter-specific meaning beyond the schema; it only gives high-level context about the legal requirement. Thus baseline score 3 is appropriate.

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 description clearly states the tool's purpose: determining if the mandatory five-day paid leave requirement applies and returning the fulfillment status and remaining days. It specifies the target population (workers with 10+ days granted) and cites the relevant law, distinguishing it from siblings like 'check_attendance_rate' or 'calculate_entitlement' by its unique legal focus.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it differs from siblings like 'calculate_entitlement' or 'apply_company_policy'. This leaves the agent to infer usage context without explicit instructions.

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

list_grant_schedule付与予定の一覧化A

入社日から指定した回数(年数)分の年次有給休暇の付与予定(付与日・付与日数)を一覧で返します。入社が古く、一部の回の基準日が検証済み下限日(2001-04-01)より前になる場合でも呼び出し全体はエラーにならず、該当の回だけ supported:false としてマークされ、それ以外の回は通常どおり計算されます。

ParametersJSON Schema
NameRequiredDescriptionDefault
hireDateYes入社日 (YYYY-MM-DD形式、例: 2026-08-15)
numberOfYearsYes一覧化する付与回数(何回分/何年分)
annualScheduledDaysNo1年間の所定労働日数(週所定労働日数が不定の場合に指定。指定するとweeklyScheduledDaysより優先される)
referenceDateMethodNo基準日の算定方式。"individual"=原則どおり労働者ごとに個別付与(省略時のデフォルト)。"uniform"=斉一的取扱い(全労働者共通の基準日に統一して前倒し付与)
weeklyScheduledDaysNo週所定労働日数(比例付与を計算したい場合に指定。1〜4日で比例付与対象、5日以上は通常の労働者扱い)
weeklyScheduledHoursNo週所定労働時間(任意。30時間以上の場合は比例付与の対象外であることの検証に使う)
uniformBasisMonthDaysNo斉一的取扱い(uniform)で使う、会社共通の基準日候補("MM-DD"形式の配列。例: ["04-01"] や ["04-01","10-01"])。referenceDateMethodが"uniform"の場合は必須

TDQS

A3.7/5.0
Behavior4/5

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

Without annotations, the description carries full burden. It discloses a non-obvious behavior: if some reference dates fall before 2001-04-01, those are marked as supported:false and the call does not error. This is good transparency, though other behaviors like error conditions are not mentioned.

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?

The description is a single, concise paragraph. It is front-loaded with the main purpose and follows with an important edge case. Every sentence adds value without redundancy.

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

Completeness3/5

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

The description lacks details about the output format (it says returns a list but not the structure). Also, parameter dependencies like uniformBasisMonthDays being required for uniform mode are not explained, though they are in the schema. Given the tool has 7 parameters and no output schema, more context would be beneficial.

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 baseline is 3. The description adds context about the overall purpose and the lower date limit behavior, but does not significantly elaborate on individual parameters beyond what the schema provides.

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 description clearly states it returns a list of scheduled annual paid leave grants for a specified number of years from hire date, including handling of dates before the verified lower limit. This is distinct from sibling tools like check_attendance_rate or calculate_entitlement.

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

Usage Guidelines2/5

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

The description does not provide any explicit guidance on when to use this tool versus alternatives. There are no when-to-use, when-not-to-use, or alternative recommendations.

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

proportional_entitlement比例付与日数の計算A

週所定労働日数(または年間所定労働日数)から、パート・アルバイト等への年次有給休暇の比例付与日数(法定最低基準)を計算します。

ParametersJSON Schema
NameRequiredDescriptionDefault
asOfDateNo比例付与表のどの世代を使うか判定する対象日(任意、省略時は現在日) (YYYY-MM-DD形式、例: 2026-08-15)
grantNumberYes付与回数(第何回目の付与か)。1=第1回(雇入れ後6ヶ月時点), 2=第2回(1年6ヶ月時点)... 7以降は第7回以降(6年6ヶ月以上)としてすべて同じ日数上限になる
annualScheduledDaysNo1年間の所定労働日数(週所定労働日数が不定の場合に指定。指定するとweeklyScheduledDaysより優先される)
weeklyScheduledDaysNo週所定労働日数(比例付与を計算したい場合に指定。1〜4日で比例付与対象、5日以上は通常の労働者扱い)
weeklyScheduledHoursNo週所定労働時間(任意。30時間以上の場合は比例付与の対象外であることの検証に使う)

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states 'calculates', implying a read-only operation, but does not explicitly confirm non-destructive behavior or disclose any side effects, prerequisites, or error conditions. For a calculation tool, this is adequate but could be more explicit.

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?

The description is a single, tightly phrased sentence in Japanese that directly conveys the tool's purpose. Every word is meaningful, and the structure is front-loaded with the core action ('calculates proportional entitlement days'). No redundancies.

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

Completeness3/5

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

Given the tool's complexity (5 parameters, no output schema), the description is brief. It does not explain the output (presumably days) or the relationships between parameters (e.g., mutual exclusion of weekly/annual days). Although the schema covers these details, the description could improve completeness by summarizing key inputs and output behavior.

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 100%, so the baseline is 3. The description adds value by framing the calculation within Japanese labor law ('statutory minimum standards') and hinting at the primary parameters (weekly or annual scheduled days). This context helps an AI agent understand the legal significance, extending beyond the schema's technical descriptions.

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 description clearly states the tool's action: it calculates proportional entitlement days for annual paid leave for part-time workers based on statutory minimum standards. It uses specific verbs ('calculates') and resources ('proportional entitlement days'), and distinguishes itself from siblings like 'calculate_entitlement' by specifying 'proportional' and 'statutory minimum'.

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

Usage Guidelines3/5

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

The description implies the tool is for calculating proportional leave for part-time employees, but it does not explicitly state when to use this tool versus siblings like 'calculate_entitlement' or 'check_attendance_rate'. No alternatives or exclusions are mentioned, leaving the agent to infer usage context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv2.0.0
    • First observedapply_company_policy
    • First observedcalculate_carryover
    • First observedcalculate_entitlement
    • First observedcheck_attendance_rate
    • First observedcheck_mandatory_five_days
    • First observedlist_grant_schedule
    • First observedproportional_entitlement
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool addresses a distinct aspect of Japanese paid leave: attendance rate check, entitlement calculation, grant schedule listing, proportional entitlement, carryover, mandatory five-day check, and company policy application. There is no overlap in purpose.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., check_attendance_rate, calculate_entitlement), but 'proportional_entitlement' lacks a verb, introducing a minor inconsistency.

Tool Count5/5

Seven tools cover the core computations and checks for paid leave without being excessive. Each tool serves a necessary function, and the count is well-scoped for the domain.

Completeness5/5

The set covers all essential aspects of Japanese paid leave management: eligibility conditions, entitlement calculation (standard and proportional), grant scheduling, carryover, mandatory five days, and company policy. No obvious gaps for the intended purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • leave_manager

    RamehNagella
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables natural-language-based employee leave management including leave balance checks, leave applications, approvals, and history retrieval through an MCP-compatible client.
    -

  • JP Business Calendar MCP

    tsuruokashun08
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables Japanese business calendar operations such as holiday checking, business day calculations, payment date calculation, fiscal year determination, and deadline tracking, all locally without external API.
    MIT

  • jp-business-calendar-mcp

    panda-studio-dev
    A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to perform Japanese business calendar calculations including holiday detection, business day arithmetic, payment date settlement, and deadline management using local data.
    6
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/skypier-jp-works/mcp-jp-paid-leave'

If you have feedback or need assistance with the MCP directory API, please join our Discord server