Skip to main content
Glama

compute_panchanga

Read-only

Calculate the five Vedic almanac limbs—tithi, vara, nakshatra, yoga, karana—for any instant and location, with sunrise-based weekday reckoning.

Instructions

Compute the panchanga — the five limbs of the Vedic almanac — for an instant: tithi (lunar day, with paksha and lord), vara (weekday reckoned from local sunrise, with its lord and the Rahu and Gulika Kalam windows as Julian Days), nakshatra (with pada), yoga (one of the 27 nithya yogas, with degrees remaining), and karana (half-tithi). Takes sidereal longitudes; all returned instants are Julian Days (UT). vara.from_sunrise reports HOW the weekday was reckoned: true means it was taken from an actual local sunrise (the Vedic definition); false means no sunrise exists to reckon from — the polar day or polar night, above about ±66.5° latitude — and the value is the observer's local CIVIL weekday as a documented fallback, which is a different quantity. Check it before presenting the vara at high latitude. vara.rahu_kalam being null is NOT the same signal: the Kalam windows can also be null while from_sunrise is true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jdYesJulian Day number in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms and uses UT1 directly for sunrise, which the vara is reckoned from; every returned instant, the Rahu and Gulika Kalam bounds included, is on this same UT1 scale. Supplying a TT/TDB Julian Day shifts sunrise by ΔT (≈ 69 s today), enough to move the vara for an instant near sunrise.
sunYesSidereal longitude of Sun [0, 360)
moonYesSidereal longitude of Moon [0, 360)
latitudeYesObserver latitude in degrees. Required — the vara is reckoned from local sunrise, so it depends on the observer.
longitudeYesObserver longitude in degrees, east positive. Required.
elevation_mNoObserver elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise — at 3650 m (Lhasa) 9.2 minutes earlier, enough to change the vara in that window. Pass the same value as search_muhurta for the same observer, or the two tools can report different weekdays for one instant.
tz_offset_minutesNoOffset of the observer's civil clock from UT, in minutes, in [-720, 840] (UTC-12:00 to UTC+14:00). Used only to name the vara's weekday.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
varaYes
yogaYes
tithiYes
karanaYes
nakshatraYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv8.0.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "karana": {
      +      "properties": {
      +        "index": {
      +          "description": "Karana index.",
      +          "type": "integer"
      +        },
      +        "is_fixed": {
      +          "description": "True for the four fixed karanas.",
      +          "type": "boolean"
      +        },
      +        "name": {
      +          "description": "Karana name.",
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "index",
      +        "name"
      +      ],
      +      "type": "object"
      +    },
      +    "nakshatra": {
      +      "properties": {
      +        "index": {
      +          "description": "Nakshatra index, 0-26.",
      +          "type": "integer"
      +        },
      +        "name": {
      +          "description": "Nakshatra name.",
      +          "type": "string"
      +        },
      +        "pada": {
      +          "description": "Pada within the nakshatra, 1-4.",
      +          "type": "integer"
      +        }
      +      },
      +      "required": [
      +        "index",
      +        "name",
      +        "pada"
      +      ],
      +      "type": "object"
      +    },
      +    "tithi": {
      +      "properties": {
      +        "lord": {
      +          "description": "Ruling graha.",
      +          "type": "string"
      +        },
      +        "name": {
      +          "description": "Tithi name.",
      +          "type": "string"
      +        },
      +        "number": {
      +          "description": "Tithi number, 1-30.",
      +          "type": "integer"
      +        },
      +        "paksha": {
      +          "description": "Shukla or Krishna.",
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "number",
      +        "name",
      +        "paksha"
      +      ],
      +      "type": "object"
      +    },
      +    "vara": {
      +      "properties": {
      +        "from_sunrise": {
      +          "description": "True when the vara was reckoned from sunrise rather than midnight.",
      +          "type": "boolean"
      +        },
      +        "gulika_kalam": {
      +          "properties": {
      +            "end_jd": {
      +              "description": "End as a Julian Day.",
      +              "type": "number"
      +            },
      +            "start_jd": {
      +              "description": "Start as a Julian Day.",
      +              "type": "number"
      +            }
      +          },
      +          "type": "object"
      +        },
      +        "gulika_kalam_slot": {
      +          "description": "Which eighth of the day Gulika Kalam falls in, 1-8.",
      +          "type": "integer"
      +        },
      +        "lord": {
      +          "description": "Ruling graha.",
      +          "type": "string"
      +        },
      +        "rahu_kalam": {
      +          "properties": {
      +            "end_jd": {
      +              "description": "End as a Julian Day.",
      +              "type": "number"
      +            },
      +            "start_jd": {
      +              "description": "Start as a Julian Day.",
      +              "type": "number"
      +            }
      +          },
      +          "type": "object"
      +        },
      +        "rahu_kalam_slot": {
      +          "description": "Which eighth of the day Rahu Kalam falls in, 1-8.",
      +          "type": "integer"
      +        },
      +        "weekday": {
      +          "description": "Vara name.",
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "weekday",
      +        "lord"
      +      ],
      +      "type": "object"
      +    },
      +    "yoga": {
      +      "properties": {
      +        "index": {
      +          "description": "Yoga index, 0-26.",
      +          "type": "integer"
      +        },
      +        "name": {
      +          "description": "Yoga name.",
      +          "type": "string"
      +        },
      +        "remaining_degrees": {
      +          "description": "Degrees left before the yoga changes.",
      +          "type": "number"
      +        }
      +      },
      +      "required": [
      +        "index",
      +        "name"
      +      ],
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "tithi",
      +    "vara",
      +    "nakshatra",
      +    "yoga",
      +    "karana"
      +  ],
      +  "type": "object"
      +}
  2. First observedv7.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals non-obvious behavioral details: the vara reckoning mechanic, the civil-weekday fallback when no sunrise exists, and the important distinction between a null rahu_kalam and from_sunrise being false. It also specifies the UT1 time scale and the ΔT sensitivity near sunrise, which are critical and undocumented elsewhere. This is exactly the kind of context an agent needs.

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 front-loaded with the core purpose and becomes more detailed only where needed for edge cases. Every sentence carries information, and the length is justified by the genuine complexity of the vara and rahu_kalam behavior. It could be tightened slightly, but it remains highly efficient.

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?

The description covers time-scale conventions, the polar fallback, the null-window distinction, and even warns to pass the same elevation_m as search_muhurta for consistency. With an output schema present, nothing an agent needs to invoke this tool correctly is missing. It is fully complete for the tool's complexity.

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?

The input schema covers 100% of the 7 parameters with already-thorough descriptions, including jd time-scale warnings and elevation's effect on sunrise. The main description reinforces that inputs are sidereal longitudes and outputs are in Julian Days (UT), but adds little parameter-level meaning beyond the schema. A baseline 3 is appropriate since the schema carries the load.

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 specific verb 'Compute' and a precise resource, 'the panchanga — the five limbs of the Vedic almanac — for an instant', then enumerates all five limbs (tithi, vara, nakshatra, yoga, karana). This distinguishes it clearly from sibling computation tools like compute_natal_chart or compute_dasha. No ambiguity remains about what the tool does.

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 operational context: it works on a single instant from sidereal longitudes, returns Julian Days (UT), and explains the polar-day/night fallback for vara at high latitude. It also warns to check vara.from_sunrise before presenting the weekday at high latitude. It does not explicitly name alternative tools, but the context is sufficient for correct use.

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