Skip to main content
Glama

Holidays and weekdays

ot_holidays
Read-onlyIdempotent

Check Iranian public holidays, including Fridays, in a date range with Jalali dates and weekdays to plan long weekends and avoid higher-priced holiday stays.

Instructions

List Iranian public holidays (Fridays included) in a date range, with Jalali dates and weekdays.

Holiday flags are filled only about 7 weeks ahead: later days show no holidays, which means unknown, not working days. Use to plan around long weekends; weekend nights (Wed, Thu) and holidays usually cost more (see ot_room_calendar).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYesLast day (inclusive), e.g. '2026-12-31'. At most a year after start.
startYesFirst day, Gregorian YYYY-MM-DD, e.g. '2026-10-20'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare this is a safe, idempotent read. The description adds the critical non-obvious caveat that holiday flags are only populated ~7 weeks ahead, so blank later days mean 'unknown', not 'working day'. That is exactly the kind of data-quality disclosure annotations cannot carry.

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 short sentences, front-loaded with the core purpose and immediately followed by the freshness caveat. The parentheticals earn their place, though the line-break layout is slightly awkward.

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?

Output schema exists, so return values need no explanation. Between the freshness limitation, the holiday/weekend definition, and the cross-reference to ot_room_calendar, an agent has everything needed to call and interpret this correctly.

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 both parameters are documented there, including the 'at most a year after start' constraint. The description adds 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List Iranian public holidays') with explicit scope (date range, Fridays included) and enrichment fields (Jalali dates, weekdays). An agent can immediately distinguish this from sibling date/availability tools like ot_room_calendar.

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?

Gives a clear use case ('plan around long weekends') and routes the agent to ot_room_calendar for pricing implications. It stops short of stating when-not to use it or what alternative exists for non-Iranian holidays, but the context is concrete.

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