RoxyAPI Astrology MCP server

Official

by RoxyAPI

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Lunar Return Chart - Monthly emotional forecast with Moon cycle chart

post_astrology_lunar_return

Read-only

Generate a lunar return chart for monthly astrological forecasting. Reveals emotional patterns, domestic focus, and intuitive themes for the coming month.

Instructions

Generate a lunar return chart for any month, cast for the exact moment the transiting Moon returns to its natal ecliptic longitude. The Moon completes one sidereal orbit every ~27.3 days, making this the primary technique for monthly astrological forecasting. Returns full tropical zodiac chart with planetary positions, house cusps, aspects, Ascendant, and Midheaven. Reveals emotional patterns, domestic focus, and intuitive themes for the coming month. Lunar return chart API, monthly horoscope forecast, Moon cycle chart, emotional astrology prediction.

Input Schema

Name	Required	Description	Default
`lang`	No	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.	en
`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	Latitude of the lunar return location in decimal degrees (-90 to 90). Affects the Ascendant and house cusps of the return chart.
`timezone`	Yes	Decimal hours from UTC OR IANA name (e.g. "America/New_York"). IANA resolved to the DST-correct offset for the birthDate. Output datetime is adjusted to this timezone.
`birthDate`	Yes	Original birth date in YYYY-MM-DD format. Used to determine natal Moon longitude for the lunar return calculation.
`birthTime`	Yes	Original birth time in 24-hour HH:MM:SS format. Determines exact natal Moon position for monthly return timing.
`longitude`	Yes	Longitude of the lunar return location in decimal degrees (-180 to 180). Determines local sidereal time for house calculations.
`returnDate`	Yes	Approximate date near the desired lunar return (YYYY-MM-DD). The Moon returns to its natal position every ~27.3 days, so provide a date within a few days of the expected return.
`houseSystem`	No	House system for the lunar return chart. Placidus (default), Whole Sign, Equal, or Koch.	placidus

Output Schema

Name	Required	Description	Default
`chart`	Yes
`location`	Yes
`birthDate`	Yes
`interpretation`	Yes
`lunarReturnDate`	Yes
`natalMoonPosition`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.2Oct 5, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "birthDate": "1990-07-15",
-    "birthTime": "14:30:00",
-    "latitude": 40.7128,
-    "longitude": -74.006,
-    "returnDate": "2026-02-12",
-    "timezone": -5
-  }
-]New value: +[
+  {
+    "birthDate": "1990-07-15",
+    "birthTime": "14:30:00",
+    "latitude": 40.7128,
+    "longitude": -74.006,
+    "returnDate": "2026-02-12",
+    "timezone": "America/New_York"
+  }
+]

changedInput schema / properties / timezone / example

Previous value: --5New value: +"America/New_York"

First observedv0.1.0Oct 4, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare this is a safe read (readOnlyHint=true, destructiveHint=false), so the safety profile is covered. The description adds the underlying astronomy (~27.3-day sidereal orbit) and the fact that output is a full tropical chart, but says nothing about authentication, rate limits, or accuracy caveats around the approximate returnDate.

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 body sentences are informative and front-loaded, leading with the verb and the precise astronomical condition. However, the trailing keyword list ('Lunar return chart API, monthly horoscope forecast, Moon cycle chart, emotional astrology prediction') is SEO padding that adds no actionable content and dilutes the 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, the description need not detail return values, yet it still summarizes the chart components and the interpretive themes, which is helpful. Combined with 100% schema coverage and annotations, an agent has enough to call the tool correctly; only explicit sibling differentiation 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 an output schema exists, so the schema already documents all nine parameters including latitude/longitude effects, timezone resolution, and returnDate tolerance. The description adds no parameter-level meaning beyond what the schema states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Generate a lunar return chart') and pins down the technical trigger precisely: the moment the transiting Moon returns to its natal ecliptic longitude. It is clearly a natal-chart-based return calculation, but it never names the most confusable sibling, post_astrology_solar_return, so the agent must infer the lunar-vs-solar distinction from domain knowledge.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The phrase 'primary technique for monthly astrological forecasting' implies when this tool is appropriate, but there are no explicit when-to-use/when-not-to-use rules and no routing to alternatives such as post_astrology_solar_return (yearly) or post_astrology_horoscope_sign_monthly. Usage context is present but left to inference.

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

Deploy Server