HinduCalendar — panchang, festivals & muhurta

get_birth_details

Read-only

Return birth star (nakshatra), birth name syllable (naam akshar / pada),
Chandra rashi (Moon sign), and Lagna rashi (ascendant sign) for a child
born at the given time and location — all from the app's own engine, so
they match the HinduCalendar app's kundali exactly.

Args:
    time:      ISO 8601 datetime of birth (e.g. "2025-08-15T10:30:00Z").
               Include timezone offset if known (e.g. "2025-08-15T10:30:00+05:30").
    lat:       Latitude of birth place in decimal degrees (e.g. 28.6139 for Delhi).
    lon:       Longitude of birth place in decimal degrees (e.g. 77.2090 for Delhi).
    ayanamsa:  "Lahiri" (Vedic sidereal, default) or "Sayan" (tropical).

Returns:
    Dict with:
      - time (ISO)
      - ayanamsa
      - nakshatra: { index (1–27), name }
      - pada: { index (1–4), overall_index (1–108), naam_akshar (birth name syllable) }
      - chandra_rashi: { index (1–12), name }  ← Moon sign
      - lagna_rashi:   { index (1–12), name }  ← Ascendant sign
    Plus a rendered South Indian kundali chart (PNG image).

Input Schema

TableJSON Schema

Name	Required	Default
`lat`	Yes
`lon`	Yes
`time`	Yes
`ayanamsa`	No	Lahiri

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only and closed world. The description adds significant behavioral context: it uses the app's own engine for consistency, and it returns both structured data and a rendered PNG chart. It also details the exact return structure, providing transparency beyond annotations. 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.

Conciseness5/5

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

The description is well-structured with a clear purpose statement, an Args section with bullet-style details, and a Returns section listing all output fields. It's detailed but every part serves a purpose, with the main verb and resource front-loaded.

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 absence of an output schema, the description enumerates all return fields (nakshatra, pada, chandra_rashi, lagna_rashi) and mentions the rendered chart. It also covers all required inputs with examples. This makes the description complete for an agent to invoke and interpret results.

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 schema has no property descriptions (0% coverage), but the description compensates fully: each parameter is explained with format, units, and examples (e.g., ISO 8601 with timezone for time, decimal degrees for lat/lon, and two allowed values for ayanamsa with default). This adds substantial meaning beyond the bare schema.

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 explicitly states the tool returns birth star, name syllable, Moon sign, and ascendant sign for a given birth time and location, and emphasizes it matches the app's kundali. This clear verb+resource+scope distinguishes it from sibling tools (festivals, muhurta, panchang).

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 clearly indicates the tool is for obtaining birth details for a child, with input parameters and a note that results match the app's engine. It doesn't explicitly mention when not to use it or name alternatives, but given the distinct purpose and sibling names, the context is clear.

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?