Skip to main content
Glama
skypier-jp-works

mcp-jp-paid-leave

出勤率8割の判定

check_attendance_rate

Determines whether an employee's attendance rate meets the 80% threshold for annual paid leave entitlement by classifying each day type according to Japanese labor law.

Instructions

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

Input Schema

TableJSON 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育児休業・介護休業等育児又は家族介護を行う労働者の福祉に関する法律に規定する育児休業又は介護休業をした日数
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.

Install Server

Other Tools

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