Business Days & Workday Calc

List bank holidays and school breaks

list_holidays

Read-onlyIdempotent

Use this when the user asks which public holidays, bank holidays, statutory holidays or school breaks a country, state or province has in a year, for example "is Monday a bank holiday in Bavaria?", "public holidays in Vietnam in 2027" or "school holidays in Bavaria". Pass the country code and the year, a region when the user names one, and kind school for school holidays, which are published for a limited set of countries. Public holidays come back with the date, weekday, English and local name, whether they apply nationwide or in listed regions, and whether they are a day off. Do not use it for religious or cultural festival dates without a country, trading-day calendars, or company holidays.

Input Schema

Name	Required	Description
`kind`	No	public (default) for public holidays, or school for school holidays, which exist for a limited set of countries.
`year`	Yes	Calendar year, for example 2027.
`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.

Output Schema

Name	Required	Description	Default
`kind`	Yes
`note`	No
`year`	Yes
`region`	No
`source`	Yes
`country`	Yes
`publicHolidays`	No
`schoolHolidays`	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.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds context beyond them: what the returned records contain (date, weekday, English and local name, nationwide vs regional, day-off flag) and the constraint that school holidays exist only for a limited set of 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?

Front-loaded with the trigger condition and examples before the parameter guidance and exclusions, so the most useful information comes first. The three inline examples add length, but each clarifies a distinct invocation pattern, so little is wasted.

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?

An output schema exists, so return values need no further explanation, and annotations cover the safety profile. With all four parameters documented and usage triggers plus exclusions spelled out, nothing an agent needs to call this correctly is missing.

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, but the description adds practical semantics: pass country and year, pass region only when the user names one, and use kind=school for school holidays (which are limited to certain countries). That 'when to supply region' guidance is not in the schema.

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 a concrete verb and resource ('which public holidays, bank holidays, statutory holidays or school breaks a country, state or province has in a year'), and the sibling tools (add_business_days, count_business_days) are clearly a different activity, so an agent can route without ambiguity.

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?

It gives explicit when-to-use triggers with three natural-language example queries and an explicit exclusion sentence ('Do not use it for religious or cultural festival dates without a country, trading-day calendars, or company holidays'). This is a full when/when-not statement.

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.