Skip to main content
Glama

Zovo PTO Accrual Calculator

Calculate team PTO balances

calculate_team_pto_balances
Read-onlyIdempotent

Use this when an owner or HR person wants PTO balances for a team: one PTO, vacation or sick leave balance per employee from one accrual policy (accrual_amount + accrual_unit + accrual_per, e.g. 15, days, year) and a list of employees (typed, pasted CSV, or an attached CSV/Excel file with name, hire date, starting balance, hours used). Applies the same policy options as calculate_pto_balance (per hour worked, per pay period, annual front-loaded or accrued, tenure tiers, caps, carryover and reset, waiting period). Returns each person's balance, hours used this year, year-end projection and hours at risk at the reset, team totals, and PDF, Excel (with each person's ledger) and CSV files. Does not give legal advice, process payroll, or compute PTO payout in money. For one person's dated ledger use calculate_pto_balance.

Input Schema

NameRequiredDescriptionDefault
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.
employeesNoThe team: a list of employees, or CSV text with a header such as "name,hire_date,starting_balance,used_hours" and one row per person. Up to 500.
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.
reset_dateNoWhen the accrual year resets (carryover is applied), e.g. "01-01" (default January 1), "July 1", or "anniversary" (hire anniversary), or "none".
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.
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.
employees_fileNoOptional CSV or Excel (.xlsx) file of employees with columns like name, hire date, starting balance, hours used, e.g. team-pto.csv.
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
as_ofYes
notesYes
policyYes
totalsYes
warningsYes
downloadsYes
employeesYes
reset_dateYes
as_of_labelYes
assumptionsYes
source_fileYes
as_of_sourceYes
employees_totalYes
projection_throughYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description adds rather than repeats: it discloses the output artifacts (PDF, Excel with per-person ledger, CSV) and the derived metrics (year-end projection, hours at risk at reset, team totals). It does not discuss limits on team size or failure behavior, which keeps it 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?

Guidance is front-loaded and every clause is informative given 28 parameters, but the body is a single dense run-on with parenthetical enumerations that restate schema details; light structuring would improve scanability.

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 28-parameter, nested-object tool with an output schema, the description covers the input pathways, the policy dimensions, the returned metrics and the sibling routing. Only edge behavior (validation failures, team- or file-size limits beyond the schema's maxItems) is left implicit.

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 a baseline 3 would suffice, but the description adds real meaning: the preferred accrual_amount + accrual_unit + accrual_per triple with an example, the three accepted employee-input modalities (typed, pasted CSV, attached CSV/Excel), and the fact that policy options mirror calculate_pto_balance.

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 (calculate), a specific resource (team PTO balances) and the scope: one balance per employee from one accrual policy. It explicitly contrasts with the sibling: 'For one person's dated ledger use calculate_pto_balance.'

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?

Front-loads the trigger condition ('when an owner or HR person wants PTO balances for a team'), names the sibling tool for the single-employee ledger case, and lists explicit out-of-scope uses (no legal advice, no payroll, no money payout).

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