Skip to main content
Glama

Business days & public holidays (200+ countries)

business_days

Use this when you need to add business days to a date (SLAs, due dates, payment terms), count the business days between two dates, check whether a date is a working day, or list the public holidays of a year, in 200+ countries. Weekends are configurable (default Saturday–Sunday) and regional holidays can be included with an ISO 3166-2 region. Holidays come from Nager.Date (MIT), cached offline for AR, AU, BR, CA, CL, CO, DE, ES, FR, GB, IT, MX, PE, US and fetched live (then cached) for the other countries; Mexico uses the statutory rest days of the Ley Federal del Trabajo art. 74 computed from the law. Deterministic. Countries without a calendar (e.g. IN) return UNSUPPORTED_COUNTRY without charge.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "business_days"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoStart date (YYYY-MM-DD), e.g. "2026-03-13". Required with `days` or `endDate`; alone it tells whether the date is a business day.
daysNoBusiness days to add to `date` (negative to go back), e.g. 10 for a 10-business-day SLA.
yearNoYear to list the public holidays of, e.g. 2026. Use alone (without `date`).
itemsNoBatch mode: up to 500 items, each with the same fields as a single call. Omit when validating a single value through the top-level fields.
regionNoOptional ISO 3166-2 subdivision to include its regional holidays, e.g. "US-CA", "DE-BY", "ES-CT".
countryNoISO 3166-1 alpha-2 country code, e.g. "MX", "US", "DE", "BR". "UK" is accepted for "GB".
endDateNoEnd date (YYYY-MM-DD) to count business days after `date` up to and including `endDate`.
weekendNoISO weekdays that are not business days (1 = Monday … 7 = Sunday). Default [6, 7]; use [5, 6] for Friday–Saturday weekends.
holidayTypesNoNager.Date holiday types that count as non-working days. Default ["Public"]; add "Bank" for banking calendars.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses data provenance (Nager.Date, MIT), that 15 countries are cached offline while others are fetched live then cached, that Mexico is computed from Ley Federal del Trabajo art. 74, that results are deterministic, and that the unsupported-country error is not charged. It omits any statement about response shape or latency cost of live fetches, which matters for the uncached countries.

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?

It is front-loaded with the highest-value sentence (the four use cases) and stays one paragraph, so an agent can stop reading early. Some of the tail — the Ley Federal del Trabajo citation and the MIT license note — is provenance detail that does not help tool selection and could be trimmed.

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 9-parameter tool with no annotations and no output schema, the description covers the modes, country/region scoping, weekend configurability, caching behavior, and the failure case. The notable gap is batch mode (`items`, up to 500) and the returned object's shape, which the agent must infer from the schema alone.

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 every parameter and a 3 is the baseline. The description adds some interpretive value — weekend is configurable with a Saturday–Sunday default and region pulls in ISO 3166-2 regional holidays — but never mentions the batch `items` mode, `holidayTypes`, or `endDate` semantics, all of which the schema covers and the description does not reinforce.

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 states four concrete operations (add business days, count business days between dates, check if a date is a working day, list a year's public holidays) over a specific resource, across 200+ countries. None of the sibling tools (validate_*, lookup_*, get_fx_rate) overlap, so the boundary is unambiguous from the first sentence.

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?

"Use this when you need to add business days to a date (SLAs, due dates, payment terms), count the business days between two dates, check whether a date is a working day, or list the public holidays of a year" gives explicit triggers keyed to real agent tasks. It also states an exclusion path — countries without a calendar (e.g. IN) return UNSUPPORTED_COUNTRY — but names no alternative tool, which is acceptable given no sibling competes.

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.