Skip to main content
Glama
puru991

Kundlit Vedic Astrology

by puru991
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Hindu festival & vrat dates for a year

get_year_events
Read-onlyIdempotent

Retrieve dated Hindu calendar events for a full year at any city. Filter festivals, ekadashi, purnima, amavasya, or sankranti dates with exact local dates.

Instructions

Returns dated Hindu calendar events for a whole year at one city. category='festival' lists every festival and vrat that year (Holi, Diwali, Navratri, Shivratri and the rest); the other categories list every ekadashi, purnima, amavasya or sankranti date. Each row is the exact local date and the event name, plus a one-line significance on shorter lists. Use this for 'when is X this year' and 'list all ekadashi dates' questions. For the detail of a single day (tithi, sunrise, rahu kaal) call get_panchang with that date; for eclipses call get_eclipses. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), served from a shared cache -- a cold or expired entry recomputes and can take ~30s; no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Constraints: the year must be within two years either side of the current year, and results are computed for the nearest of 50 supported cities (a location_note names it when the snap is far); long lists are capped at 80 rows, so pass month to page through them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearYesGregorian calendar year as a number, e.g. 2026. Only the current year plus or minus two is supported; anything else is rejected.
monthNoRestrict the result to a single Gregorian month, 1 = January to 12 = December. Omit for the whole year. Use it when a year-wide list came back truncated.
placeNoCity as free text, e.g. "Jaipur" or "Chennai, India". Omit to use Delhi. Any input is snapped to the nearest of 50 supported cities, since tithi-based dates can differ by a day between distant longitudes.
categoryYes"festival" returns every event of the year; "ekadashi", "purnima", "amavasya" and "sankranti" each narrow the list to that lunar/solar family only.

Tool Definition Quality

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds computational details (Swiss Ephemeris, cache, ~30s cold recompute), rate limits (30/min/IP per instance, 60/min/IP shared), and safety (no writes, no auth). No contradiction.

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?

Single paragraph but well-organized: purpose, categories, usage guidance, sibling alternatives, behavioral notes. Every sentence adds value; minor opportunity for bullet points.

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?

Covers constraints (year range, city snapping, row cap), output structure (date, name, significance), and explains why city matters (longitude differences). No output schema, so description compensates well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 4 parameters have schema descriptions (100% coverage). Description adds context: year constraints, city snapping to nearest of 50, month for pagination, and category enum meanings with examples.

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?

Description clearly states it returns dated Hindu calendar events for a year at a city, lists examples (Holi, Diwali, ekadashi), and distinguishes from siblings like get_panchang and get_eclipses.

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?

Explicitly says when to use ('when is X this year', 'list all ekadashi dates') and when not (single day detail → get_panchang, eclipses → get_eclipses). Also mentions constraints like year range and pagination.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/puru991/kundlit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server