Skip to main content
Glama
Sign In
Date Math – Business Days, Holidays & Time Zones

Date Math – Business Days, Holidays & Time Zones

by JowenDelaPena
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Business-day job schedule

business_day_schedule
Read-onlyIdempotent

Calculate business-day and public-holiday schedules that cron cannot express, returning upcoming run times and whether a job runs on a given date for payroll, billing, reporting, and batch jobs.

Instructions

Schedules that understand business days and public holidays, which cron cannot express: "3rd business day of the month at 09:00", "last business day", "every Monday, or the next business day if it is a holiday", "the 25th, modified following", or any cron expression with a holiday rule. Returns the next run times and whether the job should run on a given date (today by default). Country holidays, custom holidays and workweeks, DST-aware. Use for payroll, billing, reporting and batch jobs. First 25 calls per day are free, then $0.001 per call (x402).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "rule": "<rule>"
    },
    "name": "business_day_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
nNonth_business_day: 1 = first business day of the month, 3 = third; -1 = last, -2 = second to last. Not 0
dayNoday_of_month: 1–31 (31 means the last day in shorter months) or "last"
fromNoRuns at or after this time: YYYY-MM-DD (local midnight), local YYYY-MM-DDTHH:MM, or ISO 8601 with offset. Default: now
ruleYesnth_business_day needs n; day_of_month needs day; weekly needs weekdays; cron needs expression
timeNoLocal run time HH:MM for nth_business_day, day_of_month and weekly (cron uses its own times)09:00
countNoHow many runs to return (searches up to 10 years ahead)
adjustNoWhen a scheduled date is a weekend or holiday: move to the next/previous business day; modified_following = next unless that crosses into the next month, then previous; nearest (ties go earlier); skip the run; or none. Not used by nth_business_daynext
monthsNoOnly these months, e.g. [1,4,7,10] for quarterly
countryNoISO 3166-1 alpha-2 country code (207 countries); its public holidays (2000–2050) are excluded from business days
holidaysNoExtra dates excluded from business-day counts (rest days from workdays are always excluded)
timezoneNoIANA time zone, e.g. America/New_York (default UTC)
weekdaysNoweekly: weekday numbers, 0 = Sunday, e.g. [1] for every Monday
workdaysNoWorking days of the week, 0 = Sunday. Default [1,2,3,4,5] (Mon–Fri); e.g. [0,1,2,3,4] for Sun–Thu or [1,2,3,4,5,6] for Mon–Sat
check_dateNo
expressionNocron: 5 or 6 field cron expression, e.g. "0 9 25 * *". At most 96 runs a day

Output Schema

NameRequiredDescriptionDefault
fromYes
ruleYes
runsYes
checkYes
countYes
adjustYes
timezoneYes
descriptionYesThe schedule in plain English

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld=false/idempotent, so the safety profile is covered; the description adds real behavioral context beyond them: DST awareness, the holiday rule model, that it returns both next run times and a run-on-date verdict, and an explicit pricing/rate limit ("first 25 calls per day are free, then $0.001 per call (x402)"). It does not mention failure modes for invalid rule/parameter combinations.

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 distinguishing capability and example rules are front-loaded, and the closing sentences cover use cases and pricing efficiently. The example list is dense but each example clarifies a distinct rule family rather than repeating itself.

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 15-parameter scheduling tool with an output schema, a 93% described schema, and read-only annotations, the description supplies what the structured fields cannot: the conceptual model of rule families, holiday/DST behavior, and the cost model. Nothing an agent needs before calling is missing.

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 93%, so the schema already carries nearly all parameter meaning; the description adds little param-specific detail beyond showing the natural-language forms the rule families map to. With coverage this high, the baseline 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 names a specific resource (business-day/holiday-aware schedules) and enumerates concrete rule shapes ("3rd business day of the month at 09:00", "last business day", "the 25th, modified following") plus what it returns. It also explicitly positions itself against cron ("which cron cannot express"), which separates it from the cron_schedule sibling.

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?

It gives a clear use context ("payroll, billing, reporting and batch jobs") and implicitly contrasts with plain cron. It does not explicitly name which sibling to pick instead for pure date math (business_day, pay_dates, public_holidays), so an agent must infer routing rather than being told.

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

Deploy Server

Other Tools