Skip to main content
Glama
Taiwan Holiday MCP Server

Taiwan Holiday MCP Server

by lis186

check_typhoon_closure

Check Taiwan typhoon closures (天然災害停止上班上課) for today, tomorrow, or any date since 2001-07-30, nationally or by city. Returns work and school status, periods, and notes so you can confirm whether offices or classes are stopped.

Instructions

查詢台灣颱風假(天然災害停止上班上課)。今天、明天讀行政院人事行政總處(DGPA)即時頁,其他日期讀 2001-07-30 起的歸檔。 頂層 work/school 的 status 判讀規則:

  • stopped:全縣市停止,時段見 period/from。

  • conditional:只有部分地區、學制或時段停止,必須逐一讀 cities[].rows 判斷是否適用使用者所在地;未指定縣市時只要有任何停止就是 conditional。

  • normal:有公告且照常,或確定當日無公告。

  • unknown:無法判斷。絕對不可當成「照常上班上課」回答,應告知無法確認並請使用者查看縣市政府或 DGPA 公告。 reason 非 null 代表結果仍可能改變:live 為即時頁、當天仍可能更新;pending 為歸檔可能尚未收錄(昨天到 21 天前常見);source_not_ready 為當年度資料尚未產生。 回答時請轉述 summary 與 notes,並以各縣市政府公告為準。

Input Schema

NameRequiredDescriptionDefault
cityNo縣市名稱(可選),例如「臺北市」;台/臺視為相同。縣市名保留當時名稱,不對應改制前後的行政區。省略則回傳全國
dateNo要查詢的日期(臺灣時間),支援 today、tomorrow、YYYY-MM-DD 或 YYYYMMDD;省略為今天。最早 2001-07-30

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

A4.2/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses live vs archive behavior, status semantics including conditional and unknown edge cases, reason field meanings (live/pending/source_not_ready), and the critical rule that unknown must not be treated as normal. This is rich behavioral context beyond what the 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with bullet points and a front-loaded purpose statement. It is moderately long but the complexity justifies most of it; some output guidance (e.g., relaying summary and notes) could be trimmed slightly.

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?

Given no output schema and no annotations, the description covers data sources, status interpretation, reason meanings, and answer guidance. It could describe the return structure more fully (e.g., what fields exist beyond work/school status), but it is sufficient for correct invocation.

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 baseline 3. The description adds semantic meaning: date controls whether live or archive data is read, and city omission triggers 'any stop = conditional' interpretation. These rules go beyond the schema's field descriptions.

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 resource (query Taiwan typhoon days off / natural disaster work-school suspension). It does not name sibling tools, but the domain is clearly distinct from general holiday tools like check_holiday, so an agent can tell them apart.

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

Usage Guidelines4/5

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

Explains data sources by date (live page for today/tomorrow, archive for other dates) and gives interpretation rules (e.g., when no city specified, any stop is conditional). It also instructs on handling unknown results. No explicit exclusions or alternatives vs sibling holiday tools, but usage context is clear.

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