HinduCalendar — panchang, festivals & muhurta

get_muhurat_windows

Read-only

Dated windows of the auspicious muhurta yogas and the observance periods —
the "when are the vivah muhurats in 2026?" and "when is Chaturmas?" family.
Computed live by panchang-core's MuhurtaFinder, the same engine behind the
app's Muhurta Finder and the hinducalendar.app muhurat pages.

Twenty presets in two categories:
  • yoga   — Sarvarth Siddhi, Amrit Siddhi, Guru Pushya, Ravi Pushya, Ravi,
             Dwipushkar, Tripushkar, Siddha, Amrita, Vivaah Muhurat.
             Intra-day windows, often several a week.
  • period — Chaitra / Sharad / Gupta Navratri (Ashadha and Magha),
             Chaturmas, Pitru Paksha, Holashtak, Panchak, Gand Mool,
             Kharmas. Multi-day observances and blackout spans.

Each window has a `start` and `end` in ISO 8601 carrying the requested
place's UTC offset ("2026-01-14T15:05:00+05:30"), so they read directly as
the local time the muhurat is kept by.

Asking for everything in a year matches ~600 windows, so an unnarrowed
request answers with per-preset counts and says so (`windows_omitted`).
Name a muhurat or pass a month to get the actual times — a single named
muhurat always returns its windows in full.

Example questions: "vivah muhurat dates in 2026", "when is Pitru Paksha
this year?", "Sarvarth Siddhi yoga in November 2026", "when does Chaturmas
start?", "list the Panchak periods in 2027", "is there a Guru Pushya yoga
next month?".

Args:
    year:      Gregorian year.
    muhurat:   Optional name filter — fuzzy, matches slug, English and
               Hindi names ("vivaah", "sarvarth siddhi", "गुरु पुष्य").
    category:  Optional — "yoga" or "period".
    month:     Optional 1..12, to narrow within the year.
    lat, lon, tz_offset_hours:
               Location (default Ujjain, the canonical reference). These
               windows are rise/set and panchang dependent, so they do
               shift with location.
    lang:      Language for names — "en" (default) or "hi".

Input Schema

TableJSON Schema

Name	Required	Default
`lat`	No
`lon`	No
`lang`	No	en
`year`	Yes
`month`	No
`muhurat`	No
`category`	No
`tz_offset_hours`	No

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses key behaviors: the ~600 windows per year, the windows_omitted response for broad queries, the ISO 8601 format with UTC offset, and that the windows are rise/set and panchang dependent, so they shift with location. This is rich behavioral context that fully informs the agent of the tool's behavior.

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 description is long but well-structured with an intro, bullet-list categories, example questions, and a clear Args section. Each section adds necessary value for a complex, 8-parameter tool. Slightly verbose in places, but appropriately sized for the complexity.

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?

Given the high complexity, 0% schema coverage, and no output schema, the description is remarkably complete. It covers return behavior (counts vs. actual windows), window format, location sensitivity, languages, and provides concrete example queries. An agent could confidently select and invoke this tool with no further documentation.

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?

With 0% schema description coverage, the description fully compensates by explaining all 8 parameters in the Args section, including defaults, allowed values, and fuzzy matching for muhurat. It also adds context like language support and location defaults, which are essential for correct invocation.

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?

The description clearly states the tool returns dated windows of muhurta yogas and observance periods, with specific examples like 'vivah muhurat dates in 2026' and 'when is Chaturmas?'. It distinguishes itself from the sibling tool get_muhurta by focusing on windows and listing two categories (yoga and period) with 20 presets, making the purpose unmistakable.

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?

The description gives strong usage guidance: it warns that an unnarrowed request returns per-preset counts and omits windows, and advises naming a muhurat or month to get actual times. It also explains that location shifts the windows, which is important for use. It does not explicitly mention alternative tools, but the guidance for narrowing the query is clear and actionable.

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

All HinduCalendar — panchang, festivals & muhurta tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation4/5

Each tool targets a distinct aspect of the Hindu calendar (birth details, festivals, muhurat windows, moment-specific muhurta, panchang). However, get_muhurta and get_muhurat_windows have overlapping names and could be initially confused, though the descriptions clearly separate single-day versus multi-day windows.

Naming Consistency4/5

All tools use the consistent 'get_' prefix with descriptive nouns (birth_details, festival_dates, muhurat_windows, muhurta, panchang). Minor inconsistency: 'muhurat_windows' uses plural and modifier while 'muhurta' is singular, but overall the pattern is recognizable and predictable.

Tool Count5/5

Five tools is well-scoped for a specialized Hindu calendar server. Each tool covers a distinct major feature (birth chart, festivals, muhurat windows, daily muhurta, panchang), and none feel redundant or excessive.

Completeness5/5

The tool surface covers the core needs of a Hindu calendar app: panchang details, festival dates (including complex tithi/solar rules), muhurta for specific moments and broad windows, and birth details (nakshatra/rashi). There are no obvious gaps for the stated purpose; the reference to an external server for Hindu-to-Gregorian conversion is a sensible boundary rather than a deficiency.

Resources

Need Help?