Business Days & Workday Calc

Calculate a business-day due date and SLA

add_business_days

Read-onlyIdempotent

Use this when the user asks what date is a number of working days, business days or workdays after or before a date, including an SLA due date or turnaround, for example "what date is 37 business days after 11 August in England?", "when is payment due 30 business days from invoice date 3 March in Germany?" or "5 working days before 20 December in the US". Pass the country code, the start date as YYYY-MM-DD, the number of days (negative for earlier) and a region when the user names one. The start date is day 0 and is not counted. Returns the resulting date and weekday, the holidays skipped, and the conventions used. At most 1000 business days. For a trade's settlement date (T+1, T+2) pass calendars, such as ["NYSE", "FED"], ["LSE"] or ["JPX"]. Do not use it for legal deadlines that follow their own court or contract rules, or for calendar-day offsets.

Input Schema

Name	Required	Description
`days`	Yes	Working days to move: positive for later, negative for earlier. At most 1000 either way.
`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.
`calendars`	No	Holiday calendars to apply; a day is off when any of them closes it. "public" (the default) is the country's public holidays. NYSE is the New York Stock Exchange (also Nasdaq), FED the Federal Reserve and Fedwire (which DTC settlement follows), LSE the London Stock Exchange, JPX the Japan Exchange Group, TARGET2 the euro payment system. For a settlement date join the market and payment calendars, such as ["NYSE", "FED"] for a US T+1 settlement or ["TARGET2", "FED"] for EUR/USD spot. Optional.
`startDate`	Yes	The date to count from, YYYY-MM-DD. It is day 0 and is not counted.
`weekendDays`	No	Days of the week that are not working days. Default: saturday and sunday. Use friday and saturday where that is the weekend.

Output Schema

Name	Required	Description
`days`	Yes
`note`	No
`region`	No
`source`	Yes
`country`	Yes
`weekend`	No
`calendars`	No	The calendars applied, when the call named calendars
`startDate`	Yes
`resultDate`	Yes
`conventions`	Yes
`calendarDays`	Yes
`resultWeekday`	Yes
`holidaysSkipped`	Yes
`startIsBusinessDay`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

addedInput schema / properties / calendars

Added value: +{
+  "description": "Holiday calendars to apply; a day is off when any of them closes it. \"public\" (the default) is the country's public holidays. NYSE is the New York Stock Exchange (also Nasdaq), FED the Federal Reserve and Fedwire (which DTC settlement follows), LSE the London Stock Exchange, JPX the Japan Exchange Group, TARGET2 the euro payment system. For a settlement date join the market and payment calendars, such as [\"NYSE\", \"FED\"] for a US T+1 settlement or [\"TARGET2\", \"FED\"] for EUR/USD spot. Optional.",
+  "items": {
+    "enum": [
+      "public",
+      "NYSE",
+      "FED",
+      "LSE",
+      "JPX",
+      "TARGET2"
+    ],
+    "type": "string"
+  },
+  "maxItems": 3,
+  "minItems": 1,
+  "type": "array"
+}

addedOutput schema / properties / calendars

Added value: +{
+  "description": "The calendars applied, when the call named calendars",
+  "items": {
+    "enum": [
+      "public",
+      "NYSE",
+      "FED",
+      "LSE",
+      "JPX",
+      "TARGET2"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

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.6/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety profile is covered; the description still adds real behavioral detail: the start date is day 0 and not counted, the 1000-business-day cap, and that the response includes the resulting date, weekday, skipped holidays and conventions used. It does not contradict any annotation.

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-loaded with the use case before the parameter mechanics and the exclusions last, which is the right ordering. It is dense and every sentence carries information, though the three illustrative examples make it longer than strictly necessary.

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, full schema coverage and annotations covering the safety profile, the remaining burden is edge-case guidance — day-0 counting, the 1000-day bound, weekend overrides, settlement calendars, and excluded use cases — all of which are addressed.

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 goes beyond it by explaining the sign convention for days, the role of region only when the user names one, and — most usefully — the join semantics for calendars (market + payment calendar for T+1/T+2 settlement).

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 and resource — computing a date N business days from a start date — and immediately distinguishes it from the sibling count_business_days by emphasizing the returned resulting date rather than a count. The three worked examples (37 business days after, 30 days from invoice, 5 working days before) pin down the operation precisely.

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?

Opens with an explicit 'Use this when the user asks...' trigger, then names the exclusion cases (legal deadlines with their own court/contract rules, calendar-day offsets) and routes settlement-date queries to the calendars parameter with concrete pairings like ["NYSE","FED"]. An agent has both the when and the when-not.

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.