Skip to main content
Glama

DivineAI

Festival dates

get_festival_dates
Read-onlyIdempotent

Hindu festivals, vrats and observances between two dates, soonest first, from DharmikVibes' verified festival calendar, including multi-day festivals such as Navratri with their end date. A date is given only when it has been checked against an independent official or temple source; festivals still being checked are listed separately with no date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoInstead of to_date: how many days after the start, 1 to 400.
limitNoMost festivals to return, 1 to 30.
to_dateNoISO end date. Omit for 45 days after the start; at most 400 days.
from_dateNoISO start date, for example 2026-10-01. Omit for today in India.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
calendarYes
festivalsYes
window_toYes
window_fromYes
open_in_divineaiYes
date_to_be_confirmedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, closed-world safety profile, and the description adds genuinely non-obvious behavior: results are sorted soonest-first, multi-day festivals carry an end date, and undated festivals appear separately in a verification-pending state. That last caveat is critical for an agent interpreting empty date fields correctly.

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 sentences with no filler, and the core resource plus ordering are front-loaded before the verification caveat. The final sentence is long but carries high-value information about data trustworthiness, so it earns its length.

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?

An output schema exists, so return-value documentation is not required, and annotations plus 100% parameter coverage handle the safety and argument surface. The description completes the picture with the data-verification model; only the relationship to the two sibling tools remains unaddressed.

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%, so days, limit, from_date and to_date are already fully documented including defaults and ranges; the baseline of 3 applies. The description echoes the date-range scoping and ordering but adds no detail beyond the schema, such as how limit interacts with the separate undated-festival listing.

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 resource (Hindu festivals, vrats and observances), a scoping constraint (between two dates) and an ordering (soonest first), so an agent knows exactly what it returns. It does not, however, explicitly contrast itself with siblings get_panchang or get_vrat_guide, so differentiation must be inferred.

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

Usage Guidelines3/5

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

Usage is only implied: the date-range framing suggests calendar lookups, and the mention of vrats hints at overlap with get_vrat_guide, but no when-to-use, when-not-to-use, or alternative routing is stated. With two closely related siblings, this is the definition's weakest area.

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