Asterwise

Festival Calendar

asterwise_get_festival_calendar

Read-onlyIdempotent

Hindu festivals, vrats, sankrantis, eclipses and periods for a year at a location. Each lunar festival is fixed by its lunar month (amanta, with Adhik months found from new moons and sankrantis), its tithi, and the part of the day the tithi must hold (sunrise, forenoon, Madhyahna, Aparahna, Pradosh, Nishita, moonrise), with the classical tie-breaks when a tithi spans two days, Bhadra rules for Holika Dahan and Raksha Bandhan, and the Smarta Ekadashi rule. Checked against published panchang dates (New Delhi).

WORKFLOW: BEFORE: asterwise_geocode — when you only have a place name. AFTER: asterwise_get_panchanga — the day's limbs and timings for a festival date.

INPUT CONTRACT: year (1900-2100), lat, lon, timezone (IANA, default Asia/Kolkata). categories: optional list of festival, vrat, sankranti, eclipse, period; the default is ["festival"] (about 50 named festivals). Add "vrat" for every Ekadashi, Pradosh, Sankashti, Purnima and Amavasya, "period" for Adhik Maas, Pitru Paksha and Chaturmas, "eclipse" for eclipses.

DO NOT CONFUSE WITH: asterwise_get_panchanga_calendar — daily limbs for a month, not festivals. asterwise_get_muhurta — auspicious windows for an activity, not festival dates.

Full output and error contract: https://docs.asterwise.com/mcp/tools/get-festival-calendar/

Input Schema

Name	Required	Description	Default
`lat`	Yes	Latitude in decimal degrees, north positive.
`lon`	Yes	Longitude in decimal degrees, east positive.
`year`	Yes	Calendar year, e.g. 2026.
`timezone`	No	IANA timezone of the location.	Asia/Kolkata
`categories`	No	Which entries to return: festival (default, about 50 named festivals), vrat (Ekadashi, Pradosh, Sankashti, Purnima, Amavasya), sankranti, eclipse, period (Adhik Maas, Pitru Paksha, Chaturmas, Navratri, Holashtak, Kharmas).
`response_format`	No	Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.	markdown

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedSep 28, 2026

addedInput schema / properties / categories

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "enum": [
+          "festival",
+          "vrat",
+          "sankranti",
+          "eclipse",
+          "period"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Which entries to return: festival (default, about 50 named festivals), vrat (Ekadashi, Pradosh, Sankashti, Purnima, Amavasya), sankranti, eclipse, period (Adhik Maas, Pitru Paksha, Chaturmas, Navratri, Holashtak, Kharmas)."
+}

addedInput schema / properties / lat

Added value: +{
+  "description": "Latitude in decimal degrees, north positive.",
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}

removedInput schema / properties / latitude

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Latitude in decimal degrees, north positive (e.g. 13.08)."
-}

removedInput schema / properties / location

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Place name, e.g. 'Chennai, India'. Alternative to giving latitude, longitude and timezone."
-}

addedInput schema / properties / lon

Added value: +{
+  "description": "Longitude in decimal degrees, east positive.",
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}

removedInput schema / properties / longitude

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Longitude in decimal degrees, east positive (e.g. 80.27)."
-}

removedInput schema / properties / timezone / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

changedInput schema / properties / timezone / default
```
Previous value: -nullNew value: +"Asia/Kolkata"
```

changedInput schema / properties / timezone / description

Previous value: -"IANA time zone name, e.g. 'Asia/Kolkata'."New value: +"IANA timezone of the location."

addedInput schema / properties / timezone / type
```
Added value: +"string"
```

changedInput schema / properties / year / description

Previous value: -"Four-digit calendar year, e.g. 2026."New value: +"Calendar year, e.g. 2026."

addedInput schema / properties / year / maximum
```
Added value: +2100
```
addedInput schema / properties / year / minimum
```
Added value: +1900
```

changedInput schema / required

Previous value: -[
-  "year"
-]New value: +[
+  "year",
+  "lat",
+  "lon"
+]

Changed1 schema field changedSep 7, 2026

changedInput schema / properties / year / description

Previous value: -"Four-digit calendar year, e.g. 2026. Defaults to the current year when omitted."New value: +"Four-digit calendar year, e.g. 2026."

Changed6 schema fields changedSep 5, 2026

addedInput schema / properties / latitude / description

Added value: +"Latitude in decimal degrees, north positive (e.g. 13.08)."

addedInput schema / properties / location / description

Added value: +"Place name, e.g. 'Chennai, India'. Alternative to giving latitude, longitude and timezone."

addedInput schema / properties / longitude / description

Added value: +"Longitude in decimal degrees, east positive (e.g. 80.27)."

addedInput schema / properties / response_format / description

Added value: +"Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload."

addedInput schema / properties / timezone / description

Added value: +"IANA time zone name, e.g. 'Asia/Kolkata'."

addedInput schema / properties / year / description

Added value: +"Four-digit calendar year, e.g. 2026. Defaults to the current year when omitted."

Changed2 schema fields changedSep 4, 2026
- addedInput schema / properties / response_format / default
```
Added value: +"markdown"
```
- changedInput schema / required
```
Previous value: -[
-  "year",
-  "response_format"
-]New value: +[
+  "year"
+]
```
AddedMay 3, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful methodology — how lunar festivals are fixed by month, tithi and day-part, tie-break rules, Bhadra/Smarta Ekadashi rules — and validation against published panchang dates. However, it does not disclose practical behaviors like response size for a full year or rate limits; solid added context, but not exceptional beyond annotations.

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?

Front-loads purpose, then structured WORKFLOW / INPUT CONTRACT / DO NOT CONFUSE sections. The tithi and Bhadra methodology sentence is dense and somewhat verbose, but it is relevant and does not bury the routing information.

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?

The tool is complex (astronomical festival computation, six parameters, category defaults), and the description covers placement workflow, disambiguation, defaults, category expansion and validation basis. Because an output schema exists, it need not explain return values, so this is complete for an agent to call it correctly.

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 the baseline is 3. The description earns an extra point by adding meaning the schema does not convey in the same words: the default ['festival'] yields about 50 named festivals, and 'vrat'/'period'/'eclipse' each expand the result set in specific ways. It supports the enum semantics rather than merely repeating them.

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+resource with scope: Hindu festivals, vrats, sankrantis, eclipses and periods for a year at a location. It explicitly names the siblings it is not (get_panchanga_calendar, get_muhurta), so an agent can distinguish it without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit BEFORE/AFTER workflow (geocode, then panchanga) and a 'DO NOT CONFUSE WITH' section naming alternatives with disambiguating conditions. It also explains exactly when to add each category value.

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

All Asterwise tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?