Skip to main content
Glama

Zovo PTO Accrual Calculator

Calculate PTO balance

calculate_pto_balance
Read-onlyIdempotent

Use this when someone asks how much PTO they have, wants a PTO accrual calculator or vacation accrual calculator, or needs an employee's PTO, vacation or sick leave balance from an accrual policy. Give the accrual rule as accrual_amount + accrual_unit (hours, days, weeks) + accrual_per (year, month, week, pay_period, hour_worked), e.g. 2 weeks a year = 2, weeks, year; 1 hour per 30 worked = 0.0333, hours, hour_worked; use accrual_rate text only as a fallback. Takes the policy (per hour worked like 1 h per 30, hours per pay period with weekly/biweekly/semimonthly/monthly pay, or a yearly amount front-loaded or accrued evenly), tenure tiers, hire date, max balance, annual cap, carryover limit and reset date, waiting period, hours worked, and time taken (dates, hours or ranges; future dates are planned). Returns the balance as of a date (default today, US Eastern), available hours, a dated ledger with accrued, used, capped and forfeited hours, upcoming accruals, a year-end projection with hours to use before the reset, and PDF, Excel and CSV files. Does not give legal advice, check state law compliance, compute PTO payout in money, or connect to payroll. For several employees use calculate_team_pto_balances.

Input Schema

NameRequiredDescriptionDefault
stateNoOptional US state, e.g. CA, for an informational note on state paid sick leave accrual rules.
pay_dateNoAny real payday for weekly or biweekly pay, e.g. 2026-01-09, so accruals land on the right Fridays. Default: the first Friday on or after the ledger start.
hire_dateNoHire (start) date, e.g. 2024-03-04. Used for tenure tiers, the waiting period and the first partial pay period.
as_of_dateNoDate to report the balance on, e.g. 2026-10-26. Default: today in US Eastern time.
first_yearNoFor annual_front_loaded: prorated (default, first grant prorated by days left in the year) or full.
hours_usedNoTotal PTO hours used without dates, e.g. 40 for "I used 40 hours this year". Subtracted on the as-of date. Use time_taken when dates are known.
reset_dateNoWhen the accrual year resets (carryover is applied), e.g. "01-01" (default January 1), "July 1", or "anniversary" (hire anniversary), or "none".
time_takenNoPTO used or planned, as a list [{"date":"2026-03-02","hours":8}] or text "2026-03-02 8h, 2026-07-06 to 2026-07-10, Dec 24 4h". Future dates count as planned time off in the projection.
accrual_perNoHow often accrual_amount is earned: year, month, week, pay_period, or hour_worked. Required for hours; days or weeks without it are read as per year.
annual_daysNoDays of PTO per year, e.g. 15. Converted with hours_per_day (default 8).
max_balanceNoMaximum balance (accrual stops at this cap until hours are used), in hours, e.g. 240, or "30 days".
accrual_rateNoFallback only, when you cannot fill accrual_amount/accrual_unit/accrual_per: the rule as text with a number, unit and period, e.g. "1 per 30", "4.62 hours per paycheck", "15 days a year". Hours without a period are refused.
accrual_unitNoUnit of accrual_amount: hours (default), days, or weeks (weeks = days_per_week x hours_per_day).
annual_hoursNoHours of PTO per year, e.g. 120. Use instead of annual_days.
hours_workedNoActual hours worked per pay period for per_hour_worked, e.g. [{"date":"2026-01-09","hours":72}] or "2026-01-09: 72, 2026-01-23: 80". Periods not listed use the standard hours.
tenure_tiersNoTenure tiers (years of service), as text "0-2: 10 days, 3-5: 15 days, 6+: 20 days" or a list [{"from_year":0,"annual_days":10},{"from_year":3,"annual_days":15}]. "years 3-5" starts at the 3rd work anniversary.
days_per_weekNoWorkdays per week, default 5. Converts weeks of PTO to hours.
employee_nameNoOptional name for the ledger header, e.g. Dana Kim.
hours_per_dayNoHours in one PTO day, default 8, e.g. 7.5.
pay_frequencyNoPay schedule: weekly, biweekly (default, every two weeks), semimonthly (15th and last day), or monthly.
accrual_amountNoPreferred way to give the rule: the amount earned, e.g. 15 (with accrual_unit days, accrual_per year), 4.62 (hours per pay_period) or 0.0333 (hours per hour_worked).
accrual_methodNoHow PTO is earned: per_hour_worked (e.g. 1 h per 30 h worked), per_pay_period (fixed hours each paycheck, e.g. 4.62 h), annual_front_loaded (whole year granted at once on the reset date), annual_accrued_per_period (yearly amount, e.g. 15 days, spread evenly over pay periods). Optional: inferred from the other fields.
hours_per_weekNoStandard hours per week, default 40, e.g. 30 for part time. Used when hours worked are not given.
waiting_periodNoWaiting period after hire before PTO can be used, e.g. "90 days" or "3 months".
carryover_limitNoHours that may roll over at the reset date, e.g. 40. 0 = use it or lose it. Leave out for unlimited rollover.
starting_balanceNoKnown balance on starting_balance_date, in hours, e.g. 32.5 (from a pay stub), or "4 days".
annual_accrual_capNoMost hours that can be earned in one accrual year, e.g. 48.
waiting_period_ruleNoaccrue_but_locked (default: hours accrue from hire but cannot be used until the waiting period ends) or no_accrual (nothing accrues during the waiting period).
starting_balance_dateNoDate of the starting balance, e.g. 2026-01-01. Default: the start of the current accrual year (or the hire date if later).
hours_worked_per_periodNoHours worked in each pay period, for per_hour_worked when it differs from the standard (40 h/week), e.g. 64.

Output Schema

NameRequiredDescriptionDefault
kindYes
tierYes
as_ofYes
notesYes
policyYes
employeeYes
upcomingYes
warningsYes
downloadsYes
projectionYes
as_of_labelYes
assumptionsYes
as_of_sourceYes
balance_daysYes
ledger_startYes
year_to_dateYes
balance_hoursYes
ledger_previewYes
available_hoursYes
ledger_rows_totalYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds real value beyond them: the returned artifacts (dated ledger with accrued, used, capped and forfeited hours, upcoming accruals, year-end projection, PDF/Excel/CSV files), the default as-of date and US Eastern timezone, and a refusal behavior ('hours without a period are refused'). It does not state how long a long-range ledger computation takes or how the generated files are delivered, so it falls just short of a 5.

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?

Front-loaded correctly: trigger conditions first, the long input inventory and output inventory after, exclusions last. The middle sentences are dense run-ons that partially restate the schema (pay frequency options, tier formats), which costs it a point, but almost every sentence carries decision-relevant information.

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 30-parameter, zero-required tool with an output schema and full annotations, the description covers the decisions an agent must make: which fields carry the accrual rule, which are fallbacks, defaults for dates and timezone, and what the response contains. Nothing essential to a correct invocation is missing.

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 schema alone would justify a 3. The description still adds precedence rules the schema cannot express: give the rule as accrual_amount + accrual_unit + accrual_per, with accrual_rate as a fallback only, plus worked examples ('2 weeks a year = 2, weeks, year'). It leaves the interaction between accrual_method inference and the explicit amount/unit/period fields only loosely described.

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+resource (calculate PTO balance from an accrual policy) and enumerates the exact user phrasings it answers. It also names the sibling tool calculate_team_pto_balances and the boundary (several employees), so the agent can distinguish it without opening either schema.

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

Usage Guidelines5/5

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

Opens with an explicit 'use this when' trigger list (balance questions, accrual calculator, sick leave balance) and closes with a named alternative for the multi-employee case. It also lists explicit out-of-scope cases (no legal advice, no state-law compliance check, no monetary payout, no payroll connection), which is the when-not half most descriptions omit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources