HinduCalendar — panchang, festivals & muhurta

get_panchang

Read-only

Full daily panchang for a date and place — computed by the same
panchang-core engine the HinduCalendar Android app ships, so the values
are identical to the app (not an approximation).

Returns the five limbs at sunrise (tithi, nakshatra, yoga, karana, vaar)
each with its END TIME, paksha, lunar month in both amavasyant and
purnimant conventions (with adhik maas flag), Vikram/Shaka/Kali/Gujarati
samvat years, samvatsara names, ritu (season), ayana (Uttarayan/
Dakshinayan), sun/moon rashi with next-transit time, and sunrise/sunset/
moonrise/moonset.

This is also the Gregorian→Hindu date converter: the masa + paksha +
tithi + samvat fields ARE the Hindu date. (For Hindu→Gregorian, use the
Kaalshodh MCP server's find_matching_dates.)

Example questions: "what is the tithi today in Delhi?", "when does
Ekadashi end tomorrow?", "what is today's date in Vikram Samvat?",
"which Hindu month is it?".

Args:
    date:      Gregorian date, YYYY-MM-DD. Default location is Ujjain;
               pass lat/lon/tz for other places.
    lat, lon:  Location in decimal degrees.
    tz:        IANA timezone name ("Asia/Kolkata") or a numeric UTC
               offset in hours ("5.5").
    ayanamsa:  "Lahiri" (default) or "Sayan".
    lang:      Language for names — "en", "hi", and the app languages
               (mr, gu, bn, ta, te, kn, ml, sa) plus "en-iast".

Input Schema

TableJSON Schema

Name	Required	Default
`tz`	No	Asia/Kolkata
`lat`	No
`lon`	No
`date`	Yes
`lang`	No	en
`ayanamsa`	No	Lahiri

TDQS

A4.8/5.0

Behavior5/5

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

With readOnlyHint=true already present, the description adds meaningful behavioral context: values are computed by the same engine as the HinduCalendar app (not an approximation), all limbs include their END TIME, and the default location is Ujjain with timezone/ayanamsa/language options. It also clarifies that the output constitutes a complete Hindu date conversion, going well beyond the annotation baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but densely packed with irreplaceable information. It front-loads the core purpose, then uses a structured list of outputs, a clear conversion note, example questions, and a labeled Args section. No sentence is wasted; each adds unique value for such a complex tool.

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 (six parameters, no output schema), the description is remarkably complete. It details every return category, provides default behavior, explains parameter usage, and gives real-world example queries. The absence of an output schema makes this thoroughness essential, and it fully delivers.

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?

The input schema provides only types and defaults (0% description coverage), so the description carries the full burden. It fully compensates by explaining the date format (YYYY-MM-DD), the meaning of lat/lon and default Ujjain location, tz as IANA name or numeric offset, ayanamsa choices (Lahiri/Sayan), and lang options including app languages. Every parameter receives meaningful semantic explanation.

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 opens with a clear action: 'Full daily panchang for a date and place' and explicitly enumerates all returned components (tithi, nakshatra, yoga, karana, vaar, samvat years, etc.). It differentiates itself from siblings by focusing on daily panchang and also identifies a secondary role as a Gregorian→Hindu date converter, making its 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 provides clear usage context through example questions and explicitly points to find_matching_dates on the Kaalshodh server for the reverse conversion (Hindu→Gregorian), naming an alternative. It does not explicitly state when to avoid this tool relative to sibling tools, but the purpose is so distinct that the context is sufficient.

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?