life__get_holidays
[台彩 發票 油價對獎]取得台灣國定假日、連假與補班日(依人事行政總處辦公日曆),含今天是否放假、下一個連假。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年份(西元),不填則回傳今天起的近期資訊 |
[台彩 發票 油價對獎]取得台灣國定假日、連假與補班日(依人事行政總處辦公日曆),含今天是否放假、下一個連假。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | 年份(西元),不填則回傳今天起的近期資訊 |
Changes observed during successful MCP inspections.
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 does disclose the authoritative data source and the two derived facts returned (today's holiday status, next long weekend), which is genuine behavioral context for a read-only lookup. It does not describe the return shape, coverage range of years, or how makeup workdays are flagged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core content is one front-loaded sentence with no redundancy. The leading bracketed category tag [台彩 發票 油價對獎] is off-topic for a holiday tool and consumes attention without earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must stand alone for a simple read-only lookup; it conveys purpose and source adequately. It stops short of clarifying the sibling overlap or the response contents, which matters given four other tools in the hub touch holidays or long weekends.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single optional year parameter is fully documented in the schema, including the default behavior when omitted. The description adds no syntax, format, or range detail beyond that. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The main sentence names a specific verb and resource set — Taiwan national holidays, long weekends, and makeup workdays (補班日) — plus the authority source (人事行政總處辦公日曆). It does not, however, distinguish itself from close siblings like life__is_holiday, life__get_next_long_weekend, or trip__taiwan_holidays, which cover overlapping ground. The unrelated bracketed prefix [台彩 發票 油價對獎] adds noise rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no exclusions. The description does not tell an agent why it should call this instead of life__is_holiday (today's status) or life__get_next_long_weekend, both of which are explicitly duplicated in its feature list. Usage is only inferable from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.