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

Calculates current or future transit-to-natal aspects with interpretations, strength ratings, and timing guidance, helping identify active transits and filter by planet, aspect type, or strength.

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. Like /astrology/transits with a natalChart, returns summary, timing, impact, guidance, and keywords for each aspect. Adds planet, aspect-type, and minStrength filtering plus summary.strongest and summary.byType rollups. Transit aspects API, transit-to-natal analysis, predictive astrology, personalized transit forecast.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "natalChart": {
        "date": "1990-07-15",
        "time": "14:30:00",
        "latitude": 40.7128,
        "timezone": "America/New_York",
        "longitude": -74.006
      }
    },
    "name": "post_astrology_transit_aspects"
  }
}

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.
`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

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.

Changed2 schema fields changedv1.1.2Oct 5, 2026

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"
```

First observedv0.1.0Oct 4, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish that this is a safe, read-only operation, so the bar is lower; the description still adds real context by enumerating the per-aspect outputs (aspect type, orb, applying/separating status, narrative interpretation, impact rating, practical guidance) and the summary rollups. It does not mention auth, rate limits, or cost despite being a POST compute-heavy endpoint, which keeps it short of a 5.

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 three sentences are information-dense and front-loaded, but the closing string "Transit aspects API, transit-to-natal analysis, predictive astrology, personalized transit forecast" is keyword stuffing that adds no selection signal. The middle sentence partly duplicates the return-value sentence immediately before it (summary, timing, impact, guidance listed twice).

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 100% schema coverage, an output schema, and read-only annotations, the description needs only to establish purpose and the distinguishing feature set, which it does. The remaining gap is routing: nothing tells the agent why to choose this over post_astrology_transits or post_astrology_transits_monthly, which is a real risk given how many near-identical siblings exist.

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 already documents all nine parameters in depth, establishing a baseline of 3. The description only restates that planet, aspect-type, and minStrength filtering exist; it adds no format or syntax detail beyond what the schema provides, so it neither compensates nor detracts.

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 states a specific verb and resource ("Calculate all transit-to-natal aspects") and then scopes it precisely: it explains that it compares current or future planetary positions against a natal chart, and that it adds planet/aspect-type/minStrength filtering plus summary.strongest and byType rollups on top of the base transits behavior. That contrast is enough to separate it 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 Guidelines3/5

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

Usage is only implied through the "Like /astrology/transits with a natalChart... Adds filtering" framing and the parenthetical "(or future)" positions. There is no explicit when-to-use or when-not-to-use statement picking between this tool, post_astrology_transits, and post_astrology_transits_monthly, so the agent must infer the choice from feature differences.

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

Deploy Server