DatoQA — Official Public Holidays

Server Details

International public-holiday calendars combining direct government sources for France, the United Kingdom and Hong Kong with the OpenHolidays curated collection. Discover available countries, territories and years with list_holiday_regions; coverage varies and is not exhaustive worldwide.

Get published dates, multilingual names, national/regional scope, inclusive date ranges, substitute-day notes and half-day flags. Filter OpenHolidays entries to nationwide holidays with nationwide_only. Export calendars as iCalendar/ICS through the HTTP API.

Try: German nationwide public holidays for 2027 using get_public_holidays with region oh-de, year 2027 and nationwide_only true.

Future dates may change. OpenHolidays is a third-party curated source, with no per-event government-confirmation guarantee. No holiday result does not prove a working day. Not school calendars or business opening hours.

5 focused MCP tools. Free during the pilot; no account, API key or wallet required. Citations, freshness, evidence and explicit gaps are preserved. Source/schema checks are not independent factual verification. Public pilot without an SLA.

Setup, coverage and calendar export: https://datoqa.bhazarstudio.workers.dev/docs/holidays/

Ownership verified

Status: Healthy
Last Tested: 2026-09-27 20:30
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-09-27 19:55 across 5 tools

Disambiguation3/5

get_public_holidays and list_holiday_regions are clearly distinct (data vs. discovery), and catalog is a distinct setup tool. However, get_record and get_evidence both serve provenance/verification purposes and get_record partially overlaps with get_public_holidays as a generic data fetcher, creating mild boundary confusion despite the descriptions.

Naming Consistency4/5

Four tools follow a clean verb_noun pattern (get_evidence, get_public_holidays, get_record, list_holiday_regions). Only 'catalog' deviates as a bare noun, a minor inconsistency.

Tool Count4/5

Five tools is well-scoped for a read-only public-holidays data service, covering discovery, data, scope, and provenance layers. It is slightly lean but no tool is redundant.

Completeness4/5

For a read-only data domain the surface covers discovery (regions), retrieval (holidays), scope setup (catalog), and provenance/integrity (record, evidence). No write operations are needed for holiday data, so coverage is essentially complete.

Available Tools

5 tools

catalogA

Read-onlyIdempotent

Inspect

Get the scope, allowed tool names, source IDs, endpoint and access policy for this thematic MCP. Call with no arguments when setting up this connection; skip it when the desired data tool and inputs are known. Use the listed domain directories only to resolve missing identifiers or coverage. This static catalog does not guarantee current availability; inspect the data response status and freshness.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`title`	No
`tools`	No
`profile`	No
`version`	No
`capabilities`	No
`available_records`	No
`independently_verified`	No	Official-source checks are not independent factual corroboration.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world and non-destructive, so safety is covered. The description adds genuine new context that annotations cannot express: the catalog is static and does not guarantee current availability, so the agent should inspect response status and freshness.

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?

Four sentences, front-loaded with what is returned before the usage rules, and every sentence carries actionable content. Slightly dense with compound clauses, but no wasted text.

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?

Awareness/discovery tool with an output schema that carries return details, so the description need not document fields. It covers purpose, call/skip conditions, and the static-vs-available caveat; only explicit pagination or size expectations are absent, which is minor for a catalog.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is 100% for the empty object, and the description correctly signals it is called with no arguments.

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?

It names a specific resource and enumerates exactly what the catalog returns (scope, allowed tool names, source IDs, endpoint, access policy), which distinguishes it from the data-retrieval siblings. The phrase 'this thematic MCP' is mild jargon but does not obscure the purpose.

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?

Explicitly states when to call it (no arguments, when setting up the connection), when to skip it (when the desired tool and inputs are already known), and the narrow secondary use (resolving missing identifiers or coverage). This is a complete usage policy.

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

get_evidenceA

Read-onlyIdempotent

Inspect

Retrieve the source JSON snapshot and SHA-256 digest for a currently available record. The digest proves snapshot integrity, not factual truth.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Record id returned by a DatoQA data response; returns the retained source snapshot for that record.

Output Schema

ParametersJSON Schema

Name	Required	Description
`notice`	Yes
`sha256`	Yes
`record_id`	Yes
`hash_scope`	Yes
`source_url`	Yes
`first_observed_at`	Yes
`source_payload_json`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is low. The description adds genuinely new context: the digest attests snapshot integrity only, not factual truth, and the record must be 'currently available' (i.e. still retained).

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?

Two compact sentences with zero filler; the retrieval scope leads and the important integrity caveat is attached immediately afterward.

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?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. The only meaningful omission is disambiguation from get_record, which would help an agent choose between two similarly named retrieval tools.

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?

Only one parameter with 100% schema description coverage, which already explains that the id comes from a DatoQA data response and returns the retained snapshot. The description adds little beyond that baseline, though 'currently available' reinforces the retention precondition.

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?

States a specific verb and a precise resource: the retained source JSON snapshot plus its SHA-256 digest. It does not, however, contrast itself with the sibling get_record, so an agent cannot tell from the description alone which of the two to call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: 'for a currently available record' signals that the record must still be retained, and the integrity-vs-truth caveat hints at provenance use cases. There is no explicit when-to-use / when-not-to-use rule and no alternative (e.g. get_record) is named.

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

get_public_holidaysA

Read-onlyIdempotent

Inspect

Get published public-holiday entries for one calendar and year or exact inclusive local date. Use a known region id directly (fr-metropole, gb-england-and-wales, hk-general, oh-de); consult list_holiday_regions only if scope is unknown. OpenHolidays entries retain multilingual names, subdivisions and half-day scope; set nationwide_only=true to exclude regional entries. Government feeds and third-party curated calendars are explicitly distinguished. Empty results do not establish working days; future dates can change, and aggregator dates are not individually government-confirmed.

ParametersJSON Schema

Name	Required	Description
`date`	No	Exact local calendar date YYYY-MM-DD, for example 2026-12-28; cannot be combined with year.
`year`	No	Calendar year; defaults to the current year. Only published years are available. Omit when date is supplied.
`region`	Yes	Calendar identifier from list_holiday_regions, for example gb-england-and-wales.
`nationwide_only`	No	For OpenHolidays country calendars, keep only entries marked nationwide by the source. Default false includes regional entries with their scopes. Government calendars retain their named territory scope.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	No
`items`	Yes
`notice`	No
`region`	No
`status`	Yes	Read this before using values; a successful transport does not establish data availability.
`returned`	Yes	Domain-specific result count, not necessarily the number of stored records in items.
`directory`	No
`requested_date`	No
`available_years`	No
`independently_verified`	No	Official-source checks are not independent factual corroboration.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive), so the description rightly spends its budget on substantive caveats instead: multilingual names/subdivisions/half-day scope are retained, government feeds vs third-party curated sources are distinguished, empty results do not establish working days, and future or aggregator dates may change. This is well beyond the annotation payload, though it does not describe pagination or result ordering.

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?

Four sentences, tightly front-loaded with the core operation first, then routing, then semantics, then caveats. Dense but nearly every clause is load-bearing; the loss of a point is only for a slightly run-on middle sentence.

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, return values need not be explained, and the description covers the remaining gaps an agent would have: source provenance, scope semantics, and the interpretation limits of empty or future results. Nothing needed for correct invocation is missing.

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 coverage is 100%, so date/year/region/nationwide_only are already fully documented, including the date-vs-year exclusivity, bounds, and enum values. The description's region examples (fr-metropole, oh-de) and nationwide_only note mostly restate what the schema says, so it adds little new parameter-level meaning.

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 ('Get published public-holiday entries') plus the exact selection axes (one calendar + year, or an exact inclusive local date). It is immediately distinguishable from the sibling list_holiday_regions, which it explicitly positions as a lookup aid rather than a substitute.

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?

Gives explicit routing: 'Use a known region id directly ... consult list_holiday_regions only if scope is unknown,' and gives the conditional 'set nationwide_only=true to exclude regional entries.' Both when-to-use and the alternative are named, leaving nothing to inference.

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

get_recordA

Read-onlyIdempotent

Inspect

Get an unexpired record with provenance and its explicit verification level. Source/schema validation is not independent factual verification.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Opaque record id returned by a DatoQA data response. Reuse it exactly; do not invent an id.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`data`	Yes	Source-specific payload; inspect units, observation dates, nulls and source notes.
`domain`	Yes
`citation`	Yes
`freshness`	Yes
`provenance`	Yes
`display_label`	No

TDQS

A3.7/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, and closed-world behavior. The description adds valuable semantic context by stating that records are unexpired and that source/schema validation is not independent factual verification, but it does not disclose error behavior or return shape beyond what the output schema provides.

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 is two sentences, front-loaded with the core action and followed by a precise caveat. Every phrase earns its place and nothing 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?

Given the simple one-parameter interface, rich annotations, and an output schema, the description is complete enough for an agent to call the tool correctly. It clarifies the record's expiration and verification semantics without needing to restate schema or return details.

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?

The input schema has 100% description coverage for the single id parameter, including an opaque-id warning. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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?

The description provides a specific verb and resource: 'Get an unexpired record' with provenance and verification level. It is clear what the tool retrieves, but it does not explicitly differentiate this tool from siblings like get_evidence or catalog.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no explicit guidance on when to use this tool versus alternatives. The usage is only weakly implied by the tool name and the requirement of an id, and no exclusions or alternative conditions are stated.

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

list_holiday_regionsA

Read-onlyIdempotent

Inspect

Discover available public-holiday calendars and exact region ids, published years, source kind and freshness. Includes FR/UK/HK government feeds and international OpenHolidays curated entries. Use when country/region/year coverage is unknown; otherwise call get_public_holidays directly. Configured calendars are not proof of available data. International coverage is incomplete.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`notice`	Yes
`regions`	Yes
`endpoint`	Yes
`region_count`	Yes
`count_meaning`	Yes
`configured_regions`	Yes
`source_event_count`	Yes
`independently_verified`	Yes	Official-source checks are not independent factual corroboration.
`refresh_interval_seconds`	Yes
`max_collection_age_seconds`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it names actual source kinds (FR/UK/HK government feeds, OpenHolidays entries) and warns that international coverage is incomplete. Missing caveats about how freshness is computed or how often the catalog changes keep it from a 5.

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?

Four short sentences, front-loaded with what is discoverable before routing advice and caveats. Every sentence carries distinct information; nothing repeats the annotations or schema.

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-value documentation is not needed. With zero parameters and complete annotations, the description supplies the missing pieces: what the catalog contains (region ids, years, source kind, freshness), when to choose it over get_public_holidays, and two important coverage limitations.

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?

The tool takes zero parameters, so there is no parameter syntax to explain; baseline for a zero-parameter tool is 4. The schema is trivially fully covered, and the description correctly spends no space re-documenting inputs.

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 ('Discover available public-holiday calendars') and enumerates exactly what the response provides: exact region ids, published years, source kind and freshness. It explicitly names the sibling it is not, get_public_holidays, so an agent can route between them without opening schemas.

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?

Gives an explicit conditional: use this when country/region/year coverage is unknown, otherwise call get_public_holidays directly. It also adds the crucial caveat that configured calendars are not proof of available data, which prevents a false inference about coverage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesSep 27, 2026

Changedget_public_holidays4 fields changed

addedInput schema / properties / nationwide_only

Added value: +{
+  "description": "For OpenHolidays country calendars, keep only entries marked nationwide by the source. Default false includes regional entries with their scopes. Government calendars retain their named territory scope.",
+  "type": "boolean"
+}

changedInput schema / properties / region / description

Previous value: -"Official calendar identifier from list_holiday_regions, for example gb-england-and-wales."New value: +"Calendar identifier from list_holiday_regions, for example gb-england-and-wales."

changedInput schema / properties / region / enum

Previous value: -[
-  "fr-metropole",
-  "fr-alsace-moselle",
-  "fr-guadeloupe",
-  "fr-guyane",
-  "fr-la-reunion",
-  "fr-martinique",
-  "fr-mayotte",
-  "fr-nouvelle-caledonie",
-  "fr-polynesie-francaise",
-  "fr-saint-barthelemy",
-  "fr-saint-martin",
-  "fr-saint-pierre-et-miquelon",
-  "fr-wallis-et-futuna",
-  "gb-england-and-wales",
-  "gb-scotland",
-  "gb-northern-ireland"
-]New value: +[
+  "fr-metropole",
+  "fr-alsace-moselle",
+  "fr-guadeloupe",
+  "fr-guyane",
+  "fr-la-reunion",
+  "fr-martinique",
+  "fr-mayotte",
+  "fr-nouvelle-caledonie",
+  "fr-polynesie-francaise",
+  "fr-saint-barthelemy",
+  "fr-saint-martin",
+  "fr-saint-pierre-et-miquelon",
+  "fr-wallis-et-futuna",
+  "gb-england-and-wales",
+  "gb-scotland",
+  "gb-northern-ireland",
+  "hk-general",
+  "oh-ad",
+  "oh-al",
+  "oh-at",
+  "oh-be",
+  "oh-bg",
+  "oh-br",
+  "oh-by",
+  "oh-ch",
+  "oh-cz",
+  "oh-de",
+  "oh-ee",
+  "oh-es",
+  "oh-fr",
+  "oh-hr",
+  "oh-hu",
+  "oh-ie",
+  "oh-it",
+  "oh-li",
+  "oh-lt",
+  "oh-lu",
+  "oh-lv",
+  "oh-mc",
+  "oh-md",
+  "oh-mt",
+  "oh-mx",
+  "oh-nl",
+  "oh-pl",
+  "oh-pt",
+  "oh-ro",
+  "oh-rs",
+  "oh-se",
+  "oh-si",
+  "oh-sk",
+  "oh-sm",
+  "oh-va",
+  "oh-za"
+]

changedOutput schema / properties / items / items / properties / provenance / properties / verification_level / enum

Previous value: -[
-  "official_source_and_schema_checked",
-  "method_specific"
-]New value: +[
+  "official_source_and_schema_checked",
+  "public_aggregator_and_schema_checked",
+  "method_specific"
+]

Changedget_record1 field changed

changedOutput schema / properties / provenance / properties / verification_level / enum

Previous value: -[
-  "official_source_and_schema_checked",
-  "method_specific"
-]New value: +[
+  "official_source_and_schema_checked",
+  "public_aggregator_and_schema_checked",
+  "method_specific"
+]

Changedlist_holiday_regions2 fields changed
- addedOutput schema / properties / regions / items / properties / date_confirmation
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / regions / items / properties / source_kind
```
Added value: +{
+  "type": "string"
+}
```

5 tool updatesSep 27, 2026
- First observedcatalog
- First observedget_evidence
- First observedget_public_holidays
- First observedget_record
- First observedlist_holiday_regions

Related MCP Connectors

DatoQA A
dev.workers.bhazarstudio.datoqa
Free MCP tools for historical exchange rates, country economic indicators and international public-holiday calendars. No account, API key or wallet required for factual tools during the pilot. Holiday coverage combines direct government calendars for France, the United Kingdom and Hong Kong with the international OpenHolidays curated collection. Available countries and years vary: consult list_holiday_regions for current coverage. Preserve national/regional scope, multilingual names, source dates, substitute-day notes and half-day flags. Coverage is not exhaustive worldwide; future dates may change and per-event government confirmation is unavailable for OpenHolidays. Try: the ECB USD-per-EUR reference rate on 2008-09-15; US GDP per capita in current USD for 2000 and 2020; or nationwide German public holidays for 2027 (region oh-de, year 2027, nationwide_only true). Calendar export is available in iCalendar/ICS through the HTTP API. Responses include source citations, observation dates, units, freshness, evidence links and explicit gaps. ECB rates are not live tradable quotes; economic series have publication delays and missing values. Source/schema checks are not independent factual verification. Public pilot without an SLA. Setup and examples: https://datoqa.bhazarstudio.workers.dev/docs/start/ Holiday coverage and calendar export: https://datoqa.bhazarstudio.workers.dev/docs/holidays/ 24 tools in the general edition. Focused editions use the same data: https://smithery.ai/servers/datoqa-data/historical-exchange-rates ; https://smithery.ai/servers/datoqa-data/economic-indicators ; https://smithery.ai/servers/datoqa-data/official-public-holidays .
Finance Government Data Research & Data
241
Inday - Public Holiday API
io.github.gokhanibrikci
Public holiday data for 30+ countries. Check holidays, working days and calendars via AI assistants.
Government Data Search Open Data
2
Holidays MCP A
io.github.Lulu-The-Narwhal
Free, keyless public holidays lookup for any country and year, plus single-date holiday checks.
Open Data Government Data Travel & Transportation
21
lookup-holiday A
io.github.encodi
Real public holiday lookup for 206 countries via a rule-based calendar engine. Paid via x402.
Government Data Open Data
11

Related MCP Servers

holidays-mcp
Open Data Calendar Management Government Data
Lulu-The-Narwhal
A
license
A
quality
C
maintenance
Provides real, official public holiday data for ~100 countries with tools to list holidays for a year and check if a specific date is a holiday. Free, no API key required, powered by Nager.Date.
Updated 2 months ago (2026-08-10 13:54 UTC)
2
MIT
mcp-holidays
Open Data Government Data Calendar Management
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables querying public holiday data by country and year, checking if today is a holiday, and listing upcoming holidays through the MCP protocol.
Updated 3 days ago (2026-09-25 00:13 UTC)
2 npm
MIT
lookup-holiday
Calendar Management Government Data
encodi
A
license
Not graded
quality
C
maintenance
Real public/bank/school holiday lookup for 206 countries via a rule-based calendar engine (moveable holidays like Easter computed astronomically, not guessed). Priced per call via x402/USDC on Base.
Updated 2 months ago (2026-08-11 22:14 UTC)
MIT
inday-api
Government Data Open Data Search
gokhanibrikci
A
license
Not graded
quality
C
maintenance
Public holiday data for 30+ countries. Check holidays, working days, and full calendars via AI assistants like Claude and Cursor.
Updated 5 months ago (2026-04-15 05:36 UTC)
MIT

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?