Jagannatha Hora — Vedic Astrology (Jyotish, Kundli, Horoscope, Panchang)

Birth Chart Summary

generate_horoscope

Read-onlyIdempotent

Generate a Vedic (sidereal) birth horoscope from birth date, time and place. Returns a summary (ascendant/lagna, Moon and Sun signs, birth nakshatras and padas); the Rashi (D-1) chart in 'rasi_chart' -- the ascendant and the nine grahas (Sun to Ketu), each with sign, degree within the sign, nakshatra and pada, plus the bhava house (equal 30° houses with the ascendant's degree at the middle of house 1, so a graha more than 15° from the ascendant's degree within its sign is one house off the plain sign count) and a retrograde flag for Mars to Saturn (these two only for the default house method and natal settings); the birth panchanga in 'calendar_info'; and the names of the other calculated sections. Call this first; later tools reuse the same cached chart for divisional charts, strengths, dashas and more. Data only -- no interpretation is added.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	Yes	Birth date in YYYY-MM-DD format, e.g. 1985-06-15
`time`	Yes	Birth time in 24h HH:MM:SS format, e.g. 10:30:00
`place`	No	Optional birth-place name (cosmetic only).
`gender`	No	Optional. A few classical yogas are defined by gender -- Mahabhagya's rule is gender x day/night x odd/even signs. Supply it when known; when omitted those yogas are left out of the result rather than computed against an assumed gender.
`latitude`	Yes	Birth-place latitude in decimal degrees, e.g. 13.0827
`timezone`	Yes	Timezone offset from UTC in hours, e.g. 5.5 for IST
`longitude`	Yes	Birth-place longitude in decimal degrees, e.g. 80.2707

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 26, 2026

addedInput schema / properties / gender

Added value: +{
+  "description": "Optional. A few classical yogas are defined by gender -- Mahabhagya's rule is gender x day/night x odd/even signs. Supply it when known; when omitted those yogas are left out of the result rather than computed against an assumed gender.",
+  "enum": [
+    "male",
+    "female"
+  ],
+  "type": "string"
+}

First observedAug 10, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met. The description adds genuinely non-obvious behavior: results are cached and reused by later tools, the response is 'data only -- no interpretation', and the equal-house/bhava caveat plus the retrograde-flag limitation. Minor gap: no note on errors or latency for a heavy computation.

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

Conciseness3/5

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

The opening sentence is front-loaded and effective, but the middle is one enormous run-on enumerating output fields, nakshatras, padas and house rules. Since no output schema exists some return detail is warranted, yet the density exceeds what an agent needs to select and call the 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?

With no output schema, the description carries the return-value burden and does so thoroughly: rasi_chart contents, calendar_info, section names, and the house-count caveat. Combined with a fully documented input schema and safety annotations, nothing essential is missing.

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?

Schema description coverage is 100% and every parameter already carries a description, including the gender-omission caveat. The description adds no parameter-level detail beyond 'birth date, time and place', so the baseline of 3 applies.

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?

States a specific verb (generate) and resource (Vedic/sidereal birth horoscope) with the exact inputs that drive it, and positions it as the entry point ('Call this first') relative to the many sibling calculation tools. An agent can distinguish it from get_divisional_chart, get_dasha, etc. without opening a schema.

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 states when to call it ('Call this first') and why, naming the downstream tools that reuse the cached chart (divisional charts, strengths, dashas). This is direct routing guidance rather than implied usage.

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

All Jagannatha Hora — Vedic Astrology (Jyotish, Kundli, Horoscope, Panchang) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?