Business Days & Workday Calc

Count working days, workdays and PTO

count_business_days

Read-onlyIdempotent

Use this when the user asks how many working days, business days, workdays, office days or PTO days there are between two dates, or for a statutory holiday count, 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

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

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.

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, and the description goes further with behavioral defaults the schema does not convey as narrative: both endpoints counted by default, Saturday/Sunday weekend assumption unless weekendDays is set, and the actual breakdown returned (business/calendar/weekend days, holidays on working days, region-specific holidays, conventions used). No contradictions with annotations.

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-loads the trigger condition and examples before the mechanics, so the important routing information is first. It is on the long side with several illustrative examples, but each sentence carries distinct information (when to use, what to pass, defaults, what is returned, what to avoid).

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 7-parameter, all-described-schema, output-schema-backed read tool, the description covers trigger, inputs, defaults, conventions and exclusions. Nothing needed to call it correctly is missing, and the return shape is already carried by the output schema.

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 baseline is 3; the description still adds value by giving usage-oriented guidance not in the schema (pass country code, dates as YYYY-MM-DD, region only 'when the user names a state or province') and by restating the include* inclusivity defaults as a single behavioral rule.

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?

Specific verb (count) plus resource (business/working days, PTO days) with scope made explicit through concrete query examples. It is clearly distinguishable from siblings like add_business_days and list_holidays, which do different things with the same holiday calendar.

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?

States exactly when to reach for it (working-day/business-day/PTO counts between two dates, statutory holiday counts) and names the negative cases explicitly: 'Do not use it for hours, time zones, or date differences that do not exclude weekends and holidays.' Example utterances remove any ambiguity about the intended trigger.

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

All Business Days & Workday Calc 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.