Skip to main content
Glama
RoxyAPI

RoxyAPI Astrology MCP server

Official
by RoxyAPI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Transit Aspects - Detailed transit-to-natal aspect analysis with interpretations

post_astrology_transit_aspects
Read-only

Calculate transit-to-natal aspects with strength ratings, timing, and practical interpretations. Compare current or future planets to a natal chart to find active transits.

Instructions

Calculate all transit-to-natal aspects with detailed interpretations, strength ratings, and timing guidance. Compares current (or future) planetary positions against your natal chart to identify active transits. Returns aspect type, orb, applying/separating status, narrative interpretation, impact rating, and practical guidance for each transit. Supports planet and aspect-type filtering. More detailed than the /transits endpoint, adding AI-friendly interpretation fields. Transit aspects API, transit-to-natal analysis, predictive astrology, personalized transit forecast.

Input 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
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.
planetsNoFilter to specific transiting planets. Omit to include all planets. Useful for focusing on slow-moving outer planet transits (Saturn, Jupiter, Pluto).
natalChartYesNatal chart birth details (date, time, location, timezone). Used to calculate natal planetary positions that transits are compared against.
aspectTypesNoFilter to specific aspect types (conjunction, opposition, trine, square, sextile, etc.). Omit to include all aspect types.
houseSystemNoHouse system used to divide the natal chart into 12 houses. Every house number in the response is read against these natal cusps, for the natal bodies and the transiting bodies alike. Placidus (default) is time sensitive and the most widely used in Western astrology. Whole Sign assigns one sign per house. Equal divides into 30 degree segments from the Ascendant. Koch emphasizes higher latitudes. Quadrant systems fall back to Whole Sign above the polar circle.placidus
minStrengthNoMinimum aspect strength threshold (0-100). Higher values return only tighter, more potent aspects. Useful for filtering out wide-orb aspects.
transitDateNoTransit date in YYYY-MM-DD format. Defaults to current date if omitted. Use future dates for predictive transit analysis.
transitTimeNoTransit time in HH:MM:SS format, read on the clock of the natal chart timezone at the transit date (an IANA zone takes the offset in force on that date, daylight saving included). Defaults to 12:00:00 (noon) if omitted.

Output Schema

NameRequiredDescriptionDefault
housesYes
aspectsYes
summaryYes
ascendantYes
houseSystemYes
transitDateYes
natalPlanetsYes
transitPlanetsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.2
    • changedInput schema / examples
      Previous value: -[
-  {
-    "natalChart": {
-      "date": "1990-07-15",
-      "latitude": 40.7128,
-      "longitude": -74.006,
-      "time": "14:30:00",
-      "timezone": -5
-    }
-  }
-]New value: +[
+  {
+    "natalChart": {
+      "date": "1990-07-15",
+      "latitude": 40.7128,
+      "longitude": -74.006,
+      "time": "14:30:00",
+      "timezone": "America/New_York"
+    }
+  }
+]
    • changedInput schema / properties / natalChart / properties / timezone / example
      Previous value: --5New value: +"America/New_York"
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the comparison behavior and enumerates return fields, but since an output schema exists those returns are already documented, so the added behavioral context is modest. No mention of rate limits, cost, or latency.

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 sentences are front-loaded and efficient, but the trailing keyword string ('Transit aspects API, transit-to-natal analysis, predictive astrology, personalized transit forecast.') is SEO padding that adds no information for an agent. That final sentence dilutes an otherwise tight description.

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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. The description covers what the tool computes, its inputs' role, and filtering options, which is adequate for a 9-parameter read-only analytical tool; only alternative-routing detail is thin.

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%, so the schema carries the parameter documentation burden and the baseline is 3. The description only restates that planet and aspect-type filtering exist, adding no syntax, defaults, or edge-case guidance beyond the schema.

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?

Specific verb+resource ('Calculate all transit-to-natal aspects') with scope (current or future positions vs. natal chart) and explicit differentiation from a sibling ('More detailed than the /transits endpoint, adding AI-friendly interpretation fields'). An agent can distinguish this from post_astrology_transits 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 clear context for use (comparing current or future planetary positions against a natal chart, predictive analysis) and a comparative routing hint against the /transits endpoint. It never states when NOT to use it or how to choose among the many siblings (transits_monthly, aspects, aspects_monthly), so it stops short of a full 5.

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

Deploy Server

Other Tools