Vedic Astrology and Kundli MCP Server by RoxyAPI

Heliacal rising and setting (udaya and asta) - Graha Asta Calculator API

post_vedic_astrology_heliacal

Read-only

Calculate heliacal rising (udaya) and setting (asta) of the six visible grahas for any date and place, by the Surya Siddhanta rule. Returns whether each graha currently clears the solar glare, its separation from the Sun in classical degrees of time, and the dates its visibility last changed and next changes. This is the calculation behind Guru Asta and Shukra Asta, the periods classical muhurta withholds marriage and other auspicious ceremonies. Unlike a birth chart combustion flag it is location aware, because the angle the ecliptic makes with the local horizon decides how long a graha lingers after the Sun. Graha asta API, Guru Asta Shukra Asta dates, heliacal rising calculator, planetary combustion muhurta.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	Yes	Local calendar date to judge, in YYYY-MM-DD format. There is deliberately no time field: heliacal visibility is a once-a-day verdict read at that day sunrise or sunset, so a clock time could only pick a different day.
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`latitude`	Yes	Observer latitude in decimal degrees, restricted to -60 to 60. Visibility depends on the observer, unlike the longitude orb every chart API reports, because the angle the ecliptic makes with the horizon decides how long a graha lingers after the Sun. Beyond this band the classical rule stops describing solar glare and starts describing polar horizon geometry, so it is declined rather than answered wrongly.
`timezone`	No	Timezone: IANA name (e.g. "Asia/Kolkata", "Europe/London") OR decimal hours from UTC. Fixes which local day the date refers to, and every datetime in the response is returned in it. Defaults to 5.5.
`longitude`	Yes	Observer longitude in decimal degrees. Sets local sunrise and sunset, which are the instants the verdict is read at. Example: Mumbai 72.8777, Delhi 77.2090, London -0.1278.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`date`	Yes
`grahas`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "date": {
+      "type": "string"
+    },
+    "grahas": {
+      "items": {
+        "properties": {
+          "graha": {
+            "type": "string"
+          },
+          "horizon": {
+            "enum": [
+              "east",
+              "west"
+            ],
+            "type": "string"
+          },
+          "kalamsa": {
+            "type": "number"
+          },
+          "lastEvent": {
+            "properties": {
+              "datetime": {
+                "type": "string"
+              },
+              "horizon": {
+                "enum": [
+                  "east",
+                  "west"
+                ],
+                "type": "string"
+              },
+              "kalamsa": {
+                "type": "number"
+              },
+              "timeDegrees": {
+                "type": "number"
+              },
+              "type": {
+                "enum": [
+                  "udaya",
+                  "asta"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "type",
+              "horizon",
+              "datetime",
+              "timeDegrees",
+              "kalamsa"
+            ],
+            "type": [
+              "object",
+              "null"
+            ]
+          },
+          "longitudeSeparation": {
+            "type": "number"
+          },
+          "nextEvent": {
+            "properties": {
+              "datetime": {
+                "type": "string"
+              },
+              "horizon": {
+                "enum": [
+                  "east",
+                  "west"
+                ],
+                "type": "string"
+              },
+              "kalamsa": {
+                "type": "number"
+              },
+              "timeDegrees": {
+                "type": "number"
+              },
+              "type": {
+                "enum": [
+                  "udaya",
+                  "asta"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "type",
+              "horizon",
+              "datetime",
+              "timeDegrees",
+              "kalamsa"
+            ],
+            "type": [
+              "object",
+              "null"
+            ]
+          },
+          "retrograde": {
+            "type": "boolean"
+          },
+          "timeDegrees": {
+            "type": "number"
+          },
+          "visible": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "graha",
+          "visible",
+          "horizon",
+          "timeDegrees",
+          "kalamsa",
+          "retrograde",
+          "longitudeSeparation",
+          "lastEvent",
+          "nextEvent"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "date",
+    "grahas"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedAug 17, 2026

addedInput schema / examples

Added value: +[
+  {
+    "date": "2026-07-25",
+    "latitude": 19.076,
+    "longitude": 72.8777
+  }
+]

changedInput schema / properties / compact / description

Previous value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."

AddedAug 2, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety traits. It adds useful behavioral context: the calculation follows the Surya Siddhanta rule, the verdict is read at sunrise/sunset, and latitude is restricted to avoid polar horizon geometry. No contradiction with annotations.

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 description is verbose and includes a trailing keyword list (e.g., 'Graha asta API, Guru Asta Shukra Asta dates...') that adds no value for an agent. It front-loads the main purpose but could be trimmed significantly. It is structured with the core function first, but the extra SEO-like text detracts from conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description does not need to detail return formats. It explains what the tool returns, the underlying rule, and the distinction from birth chart combustion. The description is adequate for an agent to understand when and why to call it, though it could mention edge cases like invalid date or timezone handling.

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 descriptions cover 100% of parameters, so baseline is 3. The description text reinforces location-awareness and the classical rule but adds no new semantic meaning beyond what the schema already provides for date, latitude, longitude, timezone, and compact. The value comes from the schema, not the description.

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 calculates heliacal rising (udaya) and setting (asta) of the six visible grahas for any date and place, using the Surya Siddhanta rule. It explicitly lists the return values (whether graha clears solar glare, separation from Sun, visibility change dates) and differentiates itself from a birth chart combustion flag by being location-aware. This distinguishes it from sibling tools like planetary_positions or birth chart.

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 concrete usage context: it is the calculation behind Guru Asta and Shukra Asta, the periods classical muhurta withholds marriage and ceremonies. It also contrasts with a birth chart combustion flag, implying when to prefer this tool for location-aware heliacal visibility. However, it does not explicitly name sibling tools or state when not to use, leaving some inference required.

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

All Vedic Astrology and Kundli MCP Server by RoxyAPI 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?