Skip to main content
Glama

Vedic Astrology and Kundli MCP Server by RoxyAPI

by com.roxyapi
OverviewDiscussionsAdmin

Monthly Planetary Aspects - Major and minor aspect events for a month

post_vedic_astrology_aspects_monthly
Read-only

Calculate all planetary aspect events (excluding Moon) for a given month. Detects 22 aspect types. 5 major (conjunction, opposition, trine, square, sextile) and 17 minor (vigintile, semi-sextile, undecile, semi-quintile, novile, semi-square, septile, quintile, binovile, centile, biseptile, tredecile, sesqui-square, bi-quintile, quincunx, triseptile, quadranovile). Returns exact date and time of closest approach using ternary search refinement. Uses degree-based aspect methodology on sidereal positions (Lahiri ayanamsa). Omit year and month to get the month in progress, so a published aspect calendar stays current without a redeploy. For Moon-specific aspects, use the /aspects/lunar endpoint. Essential for transit timing, muhurta selection, and monthly astrological forecasting. Monthly planetary aspects API, graha drishti calendar, mutual aspect ephemeris, minor aspects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoResponse language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.en
yearNoYear for monthly analysis (1551 to 2649). Defaults to the current year (UTC).
monthNoMonth number (1-12). Defaults to the current month (UTC).
compactNoSet 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.
timezoneNoTimezone: an IANA name (e.g. "America/New_York", "Europe/London", or `cities[0].timezone` from /location/search) or decimal hours from UTC (e.g. -5 for EST, 5.5 for IST). An IANA name is resolved once, at the start of the window, and that offset applies to every time in the response. Output times are converted to this timezone. Defaults to 0 (UTC).
coordinateSystemNoCoordinate system for longitude output. "sidereal" (Nirayana) uses Lahiri ayanamsa, the standard for Vedic astrology. "tropical" (Sayana) uses raw ecliptic longitude matching Western astrology. Defaults to "sidereal".sidereal

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearYes
monthYes
eventsYes
timezoneYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / year / description
      Previous value: -"Year for monthly analysis (1900-2100). Defaults to the current year (UTC)."New value: +"Year for monthly analysis (1551 to 2649). Defaults to the current year (UTC)."
    • changedInput schema / properties / year / maximum
      Previous value: -2100New value: +2649
    • changedInput schema / properties / year / minimum
      Previous value: -1900New value: +1551
  2. Changed1 schema field changed
    • changedInput schema / properties / timezone / description
      Previous value: -"Timezone offset from UTC in hours. Output times are converted to this timezone. Defaults to 0 (UTC)."New value: +"Timezone: an IANA name (e.g. \"America/New_York\", \"Europe/London\", or `cities[0].timezone` from /location/search) or decimal hours from UTC (e.g. -5 for EST, 5.5 for IST). An IANA name is resolved once, at the start of the window, and that offset applies to every time in the response. Output times are converted to this timezone. Defaults to 0 (UTC)."
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "events": {
+      "items": {
+        "properties": {
+          "aspect": {
+            "type": "string"
+          },
+          "date": {
+            "type": "string"
+          },
+          "datetime": {
+            "type": "string"
+          },
+          "distance": {
+            "type": "number"
+          },
+          "orb": {
+            "type": "number"
+          },
+          "planet1": {
+            "type": "string"
+          },
+          "planet1Localized": {
+            "type": "string"
+          },
+          "planet1Longitude": {
+            "type": "number"
+          },
+          "planet2": {
+            "type": "string"
+          },
+          "planet2Localized": {
+            "type": "string"
+          },
+          "planet2Longitude": {
+            "type": "number"
+          },
+          "time": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "planet1",
+          "planet2",
+          "aspect",
+          "date",
+          "time",
+          "datetime",
+          "orb",
+          "distance",
+          "planet1Longitude",
+          "planet2Longitude"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "month": {
+      "type": "number"
+    },
+    "timezone": {
+      "type": "number"
+    },
+    "year": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "year",
+    "month",
+    "timezone",
+    "events"
+  ],
+  "type": "object"
+}
  4. Changed1 schema field changed
    • changedInput schema / properties / coordinateSystem / description
      Previous value: -"Coordinate system for longitude output. \"sidereal\" (Nirayana) uses Lahiri ayanamsa - standard for Vedic astrology. \"tropical\" (Sayana) uses raw ecliptic longitude matching Western astrology. Defaults to \"sidereal\"."New value: +"Coordinate system for longitude output. \"sidereal\" (Nirayana) uses Lahiri ayanamsa, the standard for Vedic astrology. \"tropical\" (Sayana) uses raw ecliptic longitude matching Western astrology. Defaults to \"sidereal\"."
  5. Changed2 schema fields changed
    • changedInput schema / properties / lang / description
      Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."
    • changedInput schema / properties / lang / enum
      Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]
  6. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
+  {}
+]
    • 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."
  7. Changed4 schema fields changed
    • addedInput schema / properties / lang
      Added value: +{
+  "default": "en",
+  "description": "Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English.",
+  "enum": [
+    "en",
+    "tr",
+    "de",
+    "es",
+    "hi",
+    "pt",
+    "fr",
+    "ru"
+  ],
+  "example": "en",
+  "type": "string"
+}
    • changedInput schema / properties / month / description
      Previous value: -"Month number (1-12)."New value: +"Month number (1-12). Defaults to the current month (UTC)."
    • changedInput schema / properties / year / description
      Previous value: -"Year for monthly analysis (1900-2100)."New value: +"Year for monthly analysis (1900-2100). Defaults to the current year (UTC)."
    • removedInput schema / required
      Removed value: -[
-  "year",
-  "month"
-]
  8. Changed1 schema field changed
    • changedInput schema / properties / compact / description
      Previous value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New 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."
  9. Changed1 schema field changed
    • addedInput schema / properties / compact
      Added value: +{
+  "default": false,
+  "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.",
+  "type": "boolean"
+}
  10. Changed1 schema field changed
    • changedInput schema / properties / timezone / anyOf
      Previous value: -[
-  {
-    "maximum": 14,
-    "minimum": -14,
-    "type": "number"
-  },
-  {
-    "pattern": "^[A-Za-z_]+(?:\\/[A-Za-z0-9_+-]+){0,2}$",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "maximum": 14,
+    "minimum": -14,
+    "type": "number"
+  },
+  {
+    "type": "string"
+  }
+]
  11. First observed

TDQS

A4.2/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 safety is covered; the description adds genuinely new behavior: ternary-search refinement for closest approach, degree-based methodology on Lahiri sidereal positions, and the default-to-current-month behavior. It stops short of noting rate limits or response size characteristics, but the additions are substantive.

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 core is front-loaded and readable, but the enumeration of all 17 minor aspect names adds bulk with little decision value, and the closing keyword tail ('Monthly planetary aspects API, graha drishti calendar, mutual aspect ephemeris, minor aspects') is SEO padding that earns no place in an agent-facing definition.

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, return-shape explanation is not required, and annotations plus the full-coverage input schema cover the structured fields. The description supplies scope, methodology, and defaulting behavior, leaving only sibling selection against the non-monthly aspects tool under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description earns above baseline by explaining the defaulting rule for year/month ('Omit year and month to get the month in progress') and by tying output to sidereal Lahiri positions, which clarifies the coordinateSystem default beyond the schema text.

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 and resource ('Calculate all planetary aspect events ... for a given month') and explicitly carves out scope with '(excluding Moon)'. It names the aspect count (22) and the lunar sibling endpoint, so an agent can distinguish it from post_vedic_astrology_aspects_lunar and the non-monthly aspects tool 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit alternative ('For Moon-specific aspects, use the /aspects/lunar endpoint') and a clear operational context ('Essential for transit timing, muhurta selection, and monthly astrological forecasting'). It does not, however, say when to prefer this monthly variant over the sibling post_vedic_astrology_aspects, leaving that boundary to inference.

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 toolsInspect
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