Skip to main content
Glama

Check dates

check_dates
Read-onlyIdempotent

For each date, tell whether it is a public holiday in the country (with its name and status), a weekend, and a business day, including make-up working days such as China's 调休. Also returns today in that country's time zone. For Japan, the kind is also given: 祝日 (national holiday) / 振替休日 (substitute holiday) / 国民の休日 (citizens' holiday).

Input Schema

NameRequiredDescriptionDefault
datesYes
regionNoOutside Japan: state/province code (ISO 3166-2 suffix, e.g. CA for California) to include regional holidays.
countryNoISO 3166-1 alpha-2 country code (e.g. US, GB, DE, CN, JP). Defaults to JP (Japan) when omitted.JP
year_end_closedNoJapan only: treat 12/29-1/3 as non-business days (common in Japanese companies).
include_governmentNoOutside Japan: also treat days off only for government offices (e.g. Indonesia's cuti bersama, Canadian federal holidays) as days off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / country / description
      Previous value: -"ISO 3166-1 alpha-2 country code (e.g. JP, US, CN, GB). Default JP."New value: +"ISO 3166-1 alpha-2 country code (e.g. US, GB, DE, CN, JP). Defaults to JP (Japan) when omitted."
  2. Changed1 schema field changed
    • addedInput schema / properties / include_government
      Added value: +{
      +  "default": false,
      +  "description": "Outside Japan: also treat days off only for government offices (e.g. Indonesia's cuti bersama, Canadian federal holidays) as days off.",
      +  "type": "boolean"
      +}
  3. Changed3 schema fields changed
    • addedInput schema / properties / country
      Added value: +{
      +  "default": "JP",
      +  "description": "ISO 3166-1 alpha-2 country code (e.g. JP, US, CN, GB). Default JP.",
      +  "pattern": "^[A-Za-z]{2}$",
      +  "type": "string"
      +}
    • addedInput schema / properties / region
      Added value: +{
      +  "description": "Outside Japan: state/province code (ISO 3166-2 suffix, e.g. CA for California) to include regional holidays.",
      +  "type": "string"
      +}
    • changedInput schema / properties / year_end_closed / description
      Previous value: -"Treat 12/29-1/3 as non-business days (common in Japanese companies)."New value: +"Japan only: treat 12/29-1/3 as non-business days (common in Japanese companies)."
  4. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive safety, but the description adds substantive behavior beyond them: per-date holiday name/status, weekend/business-day classification, make-up working days, today in local time zone, and Japan holiday kinds. It does not cover unsupported country/date errors, but adds clear return semantics.

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?

Three sentences, front-loaded with core function and no obvious filler; the Japan holiday-kind detail is useful but broadens scope. Could be slightly tighter, but appropriately sized.

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?

With no output schema, the description must carry return meaning; it does explain the key classifications and local 'today' return. It leaves output structure and edge-case handling unstated, so not fully complete.

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 80%, so the schema already documents most parameters. The description mentions country context and Japan-specific behavior, but does not explain region, year_end_closed, or include_government beyond what the schema provides.

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 ('tell whether') and resource (each date) and enumerates outputs: holiday/weekend/business day, today in the country's time zone, and Japan-specific holiday kinds. Clear enough on its own, but does not name sibling tools like business_days or list_holidays to differentiate.

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?

No when-to-use or when-not-to-use guidance is provided, and it does not mention alternatives such as business_days, find_long_weekends, or list_holidays. Usage is only implied by the query it performs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources