Business Days and Holidays

Count business days between dates

count_business_days

Read-onlyIdempotent

Use this when the user asks how many working days, business days or workdays there are between two dates, for example "how many working days between 14 July and 18 August in Germany?", "how many working days are left in December in Ontario?" or "does 16 days of leave cover 5 to 31 December?". Pass the country code, the start and end dates as YYYY-MM-DD, and a region when the user names a state or province. Both dates are counted by default (includeStartDate and includeEndDate change that). Weekends are Saturday and Sunday unless weekendDays is set. Returns the number of business days, calendar days and weekend days, the public holidays that fell on working days, the holidays only some regions keep, and the conventions used. Do not use it for hours, time zones, or date differences that do not exclude weekends and holidays.

Input Schema

TableJSON Schema

Name	Required	Description
`region`	No	State, province or nation within the country, as a subdivision code such as DE-BY or BY (Bavaria), GB-SCT (Scotland), US-CA or AU-NSW. Optional.
`country`	Yes	Two-letter ISO 3166-1 country code whose holidays apply, such as US, GB, DE, AU or VN.
`endDate`	Yes	Last date of the range, YYYY-MM-DD. Not before startDate.
`startDate`	Yes	First date of the range, YYYY-MM-DD.
`weekendDays`	No	Days of the week that are not working days. Default: saturday and sunday. Use friday and saturday where that is the weekend.
`includeEndDate`	No	Count endDate when it is a working day. Default true.
`includeStartDate`	No	Count startDate when it is a working day. Default true.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`region`	No
`source`	Yes
`country`	Yes
`endDate`	Yes
`weekend`	No
`startDate`	Yes
`conventions`	Yes
`weekendDays`	Yes
`businessDays`	Yes
`calendarDays`	Yes
`includesEndDate`	No
`includesStartDate`	No
`holidaysOnWorkdays`	Yes
`regionalHolidaysNote`	No
`regionalHolidaysNotCounted`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 3, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, open-world and non-destructive behavior. The description adds substantive detail beyond annotations: default inclusive counting, Saturday/Sunday weekend defaults, weekendDays override, and returned composition including holidays and regional observance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description front-loads the core usage scenario and examples, then moves through inputs, defaults, returns and exclusions. Despite its length, each block carries decision-relevant information for a seven-parameter tool.

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?

With an output schema present and annotations covering safety, the description supplies the remaining context an agent needs: trigger conditions, country and region conventions, default date inclusion, weekend handling, and explicit non-use cases. No material gap remains.

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 parameters are already fully documented. The description still adds practical semantics such as passing region only when a state or province is named and noting inclusion defaults for start and end dates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb and resource: count business days between two dates, with scope and exclusions. It does not name or route to sibling tools like add_business_days or list_holidays, so explicit sibling differentiation is absent.

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?

Gives explicit triggers such as 'Use this when the user asks how many working days...' and exclusions such as 'Do not use it for hours, time zones...'. It does not name an alternative tool for adjacent tasks like adding days or listing holidays.

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

All Business Days and Holidays tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?