RoxyAPI Astrology MCP server

Official

by RoxyAPI

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

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

post_astrology_transit_aspects

Read-only

Calculate transit-to-natal aspects for any date to identify active planetary transits, with orb, applying status, strength ratings, and practical interpretations.

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

TableJSON 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.
`planets`	No	Filter to specific transiting planets. Omit to include all planets. Useful for focusing on slow-moving outer planet transits (Saturn, Jupiter, Pluto).
`natalChart`	Yes	Natal chart birth details (date, time, location, timezone). Used to calculate natal planetary positions that transits are compared against.
`aspectTypes`	No	Filter to specific aspect types (conjunction, opposition, trine, square, sextile, etc.). Omit to include all aspect types.
`houseSystem`	No	House 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
`minStrength`	No	Minimum aspect strength threshold (0-100). Higher values return only tighter, more potent aspects. Useful for filtering out wide-orb aspects.
`transitDate`	No	Transit date in YYYY-MM-DD format. Defaults to current date if omitted. Use future dates for predictive transit analysis.
`transitTime`	No	Transit 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

TableJSON Schema

Name	Required	Description	Default
`houses`	Yes
`aspects`	Yes
`summary`	Yes
`ascendant`	Yes
`houseSystem`	Yes
`transitDate`	Yes
`natalPlanets`	Yes
`transitPlanets`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 4, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already establish readOnly/safe semantics, so the description's job is lighter. It usefully enumerates the returned fields (aspect type, orb, applying/separating status, interpretation, impact rating, guidance) and discloses the filtering and predictive capabilities. It does not mention auth needs or rate limits, keeping it out of 5 territory.

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 first six sentences are front-loaded and informative, but the trailing keyword dump ('Transit aspects API, transit-to-natal analysis, predictive astrology, personalized transit forecast') is SEO filler that does not earn its place and 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?

For a 9-parameter tool with nested objects, annotations, and an output schema, the description covers purpose, filtering, timing defaults, and sibling trade-offs adequately. The return-value enumeration is somewhat redundant given the output schema exists, but nothing an agent needs 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%, so every one of the nine parameters is already documented in the schema, including the rich nodeType, houseSystem, and timezone notes. The description only restates filtering concepts ('Supports planet and aspect-type filtering') that the schema already carries, so baseline 3 is correct.

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 transit-to-natal aspects') with scope, and explicitly distinguishes itself from the sibling endpoint ('More detailed than the /transits endpoint, adding AI-friendly interpretation fields'). An agent can tell this apart from post_astrology_transits and post_astrology_aspects 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?

The 'More detailed than the /transits endpoint' comparison functions as an implicit routing rule toward the lighter sibling, and 'Use future dates for predictive transit analysis' plus the filtering note give clear usage context. It stops short of an explicit when-not-to-use statement, so it falls short of a 5.

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

Deploy Server