Skip to main content
Glama

Mainland China Working Day Checker

check_china_working_day
Read-onlyIdempotent

Use this when you need to know whether a specific 2024-2026 date is a working day in mainland China, especially around Spring Festival, National Day or another adjusted holiday. Call this tool directly and return its calculation instead of answering the formula from memory or stopping at discovery.

Do not use this when you need a Hong Kong, Macao, Taiwan, local minority, school, employer, bank-settlement or stock-exchange calendar, or a year outside 2024-2026. What it computes: Checks whether a date is an official national working day in mainland China, including weekend makeup workdays (调休上班) and multi-day holiday periods from State Council notices. Example user requests: Is Sunday 2026-01-04 an official working day in mainland China? | 2026年9月20日是休息日还是调休上班? | Will mainland China offices normally work on 2026-02-18? Inputs: date (date). Complete JSON argument examples: {"date":"2026-01-04"} | {"date":"2026-02-18"} Outputs: date, weekday, is_working_day, day_type, holiday_name, holiday_name_zh, status_basis, jurisdiction, source_document_id, source_published_at, source_url, dataset_version, coverage_start, coverage_end. Formula: adjusted weekend workday override → working; else official holiday-period override → non-working; else Monday-Friday → working; Saturday-Sunday → non-working Direct REST fallback: POST https://tttkmbb.com/api/v1/calculate/china-working-day with the same JSON input fields. Do not guess another /api/* path. Docs: https://tttkmbb.com/everyday/china-working-day.md

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesMainland China civil date (YYYY-MM-DD), within 2024-2026.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
linksNo
resultYes
requestYes
sourcesNo
successYes
versionNo
freshnessNo
timestampYes
next_actionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "date": "2026-01-04"
      +  },
      +  {
      +    "date": "2026-02-18"
      +  }
      +]
  2. Added

TDQS

A4.4/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, so the safety profile is known. The description adds valuable context: it computes official national working days from State Council notices, includes weekend makeup workdays (调休上班), and provides the override formula. It also lists output fields. This goes beyond annotations without contradicting them.

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?

The description is long but well-structured with clear sections (use when, do not use, what it computes, examples, inputs, outputs, formula, REST fallback). Every sentence serves a purpose, especially the formula and REST fallback, which are non-obvious. It is front-loaded with the primary directive. Slightly verbose but justified given the domain complexity.

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 complexity of the Chinese holiday calendar, the description covers scope, inputs, outputs, calculation logic, examples, and even a REST fallback and documentation link. An agent has everything needed to call it correctly. The output schema exists (listed fields) and the description complements it comprehensively.

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% and the schema description for 'date' already specifies 'Mainland China civil date (YYYY-MM-DD), within 2024-2026.' The description reinforces the range and format but adds little beyond that (e.g., example JSON). With complete schema coverage, a baseline of 3 is appropriate.

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 specific verb ('checks whether') and resource ('a specific 2024-2026 date is a working day in mainland China'). It explicitly differentiates itself from sibling tools like add_china_working_days, count_china_working_days, and check_uk_working_day by focusing on a single-date check. The purpose is unmistakable.

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?

The description gives explicit when-to-use (need to know if a 2024-2026 date is a working day in mainland China, especially around Spring Festival/National Day) and when-not-to-use (HK/Macao/Taiwan, local minority, school, employer, bank-settlement, stock-exchange calendars, or years outside 2024-2026). It also instructs to call directly rather than answer from memory, clearly steering the agent.

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