Skip to main content
Glama
astroway-mcp

astroway-mcp

Official
by astroway

Hindu calendar: ICS feed of festivals and vrats

astroway_vedic_calendar_ics
Read-onlyIdempotent

Generates an iCalendar (.ics) file of Hindu festivals and vrats for a year and place, with tithi windows, parana times and stable UIDs, ready to import into calendar apps.

Instructions

The festivals and vrats of a year for a place as an iCalendar file (text/calendar, RFC 5545): one all-day event per observance, the rule, tithi window, parana and source in the description, a stable UID per festival, date and place. Query: year, latitude, longitude, timezone (IANA or auto), include (festivals, vrats or single vrat types, comma separated; default festivals,vrats), tradition. The key travels in X-Api-Key, so fetch it from your server and serve the file to calendar apps; it is priced as one festivals call.

[Group: Vedic] [Endpoint: GET /v1/vedic/calendar/ics] [Required: year, latitude, longitude] [Cost: 100 credits (Tier 4)]

Input Schema

NameRequiredDescriptionDefault
yearYesGregorian year; events are those dated in it.
includeNoComma list: festivals, vrats, or single vrat types (ekadashi, pradosh, sankashti, purnima, amavasya, masik-shivaratri).festivals,vrats
latitudeYesLatitude in decimal degrees, north positive.
timezoneNoIANA zone name, or auto to look it up from the coordinates. Followed day by day, summer time included.auto
longitudeYesLongitude in decimal degrees, east positive.
traditionNoWhose reckoning decides the day where traditions differ (Rama Navami, Janmashtami).smarta
ayanamsaIdNoAyanamsa id; 1 is Lahiri.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.1

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the exact media type and RFC, the one-all-day-event-per-observance structure, embedded rule/tithi/parana/source data, stable UIDs, X-Api-Key auth handling, and credit pricing. These are meaningful operational traits not already captured by readOnlyHint, idempotentHint, or destructiveHint.

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?

The definition is front-loaded with the tool's purpose, then query parameters, then auth and pricing. It is information-dense and mostly waste-free, though the first sentence is long and carries several output-detail clauses that make it slightly run-on.

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?

With no output schema, the description properly explains return values: an iCalendar file, one event per observance, rule/tithi/parana/source fields, stable UID, date and place. It also covers auth and pricing, leaving no major caller need 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 description coverage is 100%, so the schema already documents every parameter. The description repeats a subset of query semantics such as include defaults and timezone auto, while omitting ayanamsaId entirely, so it adds little meaning beyond the schema.

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?

The description clearly states that this tool returns a year's festivals and vrats for a location as an iCalendar file, including per-event details and a stable UID. It does not explicitly name or contrast with the sibling festivals/vrats tools, so the purpose is clear but sibling differentiation is left to the output format.

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?

It gives a clear use context: fetch the API key server-side and serve the resulting file to calendar apps. It does not state when to prefer this over the JSON festivals or vrats endpoints, nor does it list exclusions, so it stops short of full when/when-not guidance.

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

Deploy Server

Other Tools