List Philippine holidays

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

Annotations already establish readOnly, idempotent, and openWorld behavior, so the description's main added value is disclosing the actual data coverage ('currently 2026 and 2027') — important because the schema permits 2000-2100. It does not say whether an out-of-range or out-of-coverage year yields an empty result, an error, or an extrapolation, which is the remaining behavioral gap.

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?

Two compact sentences with the content and coverage stated first and examples second, so nothing important is buried. The nested quotation inside the description is slightly awkward stylistically but does not impede comprehension.

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?

For a low-complexity, zero-required-parameter lookup tool with full schema coverage and read-only annotations, the description supplies what an agent needs: what is returned and which years exist. The only meaningful omission is explicit behavior for years outside the stated 2026-2027 coverage.

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%, so all three parameters, including both enums and the response_format default, are already fully documented. The description adds only a light illustration of how year and type combine; it provides no syntax or format detail beyond the schema, so the 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 description names a specific resource (Philippine regular and special non-working holidays), states the scope of data coverage (2026 and 2027), and lists the returned fields (date, name, type). It is instantly distinguishable from the sibling tools, which cover currency, weather, regions, schools, and scholarships.

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?

The two example queries ('When is Holy Week 2027?' and 'regular holidays this year') effectively illustrate the question shapes this tool answers, including the combination of type and year filters. There are no explicit exclusions or guidance on what to do when a year outside 2026-2027 is requested.

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