Astro Agents - deterministic Western + Vedic astrology

Transits

transits

Read-onlyIdempotent

Western astrology transits: the transits to a natal chart at a moment, and the exact dates transiting aspects perfect over a window of up to a year. 'transit': aspects from the sky at a moment to every natal point, with the natal house each transiting planet occupies. 'window': the exact UTC minute every transiting planet perfects each aspect to each natal point over up to 366 days (62 with the Moon), retrograde passes included. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.08 per call via REST POST https://astro-agent.dev/v1/western/transits (x402 or MPP); your first 3 calls are free here.

Input Schema

Name	Required	Description
`natal`	Yes	Birth data.
`window`	No	UTC dates YYYY-MM-DD, at most 366 days apart.
`options`	No	Optional calculation settings; every default is the common Western convention.
`transit`	No	The transit moment. A bare local time is read in the natal place's zone.

Output Schema

Name	Required	Description
`meta`	Yes	Provenance of the result.
`result`	Yes	The calculation result.
`endpoint`	Yes	The REST route that computed it, e.g. 'western/natal'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "endpoint": {
+      "description": "The REST route that computed it, e.g. 'western/natal'.",
+      "type": "string"
+    },
+    "meta": {
+      "description": "Provenance of the result.",
+      "properties": {
+        "astronomy_library": {
+          "description": "Astronomy library and version.",
+          "type": "string"
+        },
+        "compute_ms": {
+          "description": "Computation time in milliseconds.",
+          "type": "number"
+        },
+        "computed_at": {
+          "description": "When it was computed (UTC, ISO 8601).",
+          "type": "string"
+        },
+        "deterministic": {
+          "description": "Always true: same input, same result.",
+          "type": "boolean"
+        },
+        "engine": {
+          "description": "Engine name and version.",
+          "type": "string"
+        },
+        "ephemeris": {
+          "description": "Ephemeris used (NASA/JPL DE440).",
+          "type": "string"
+        },
+        "frame": {
+          "description": "Reference frame of the positions.",
+          "type": "string"
+        },
+        "input_sha256": {
+          "description": "SHA-256 of the canonical input.",
+          "type": "string"
+        },
+        "llm_used": {
+          "description": "Always false: no language model is involved.",
+          "type": "boolean"
+        },
+        "payment": {
+          "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
+          "type": "object"
+        },
+        "reproducibility": {
+          "description": "How to reproduce and check this result.",
+          "type": "string"
+        },
+        "result_sha256": {
+          "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "engine",
+        "deterministic",
+        "llm_used",
+        "input_sha256",
+        "result_sha256"
+      ],
+      "type": "object"
+    },
+    "result": {
+      "description": "The calculation result.",
+      "properties": {
+        "natal": {
+          "description": "The natal chart the transits are measured against: subject, settings, points and angles.",
+          "type": "object"
+        },
+        "settings": {
+          "description": "The aspect set and orbs applied.",
+          "type": "object"
+        },
+        "transit": {
+          "description": "The transit moment: its time, the transiting points and their aspects to the natal chart.",
+          "type": "object"
+        },
+        "warnings": {
+          "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
+          "type": "array"
+        },
+        "window": {
+          "description": "Exact transit hits over the requested window: start, end, whether the Moon is included, precision, count and the list of hits with their exact dates.",
+          "type": "object"
+        }
+      },
+      "required": [
+        "natal",
+        "settings",
+        "transit",
+        "window"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "endpoint",
+    "result",
+    "meta"
+  ],
+  "type": "object"
+}

Changed7 schema fields changedOct 5, 2026

addedInput schema / properties / options / description

Added value: +"Optional calculation settings; every default is the common Western convention."

addedInput schema / properties / options / properties / house_system / description

Added value: +"House system for cusps and planet houses, e.g. 'placidus' (default) or 'whole_sign'."

addedInput schema / properties / options / properties / luminary_orb_bonus / description

Added value: +"Extra orb in degrees for aspects involving the Sun or the Moon. Example: 2."

addedInput schema / properties / options / properties / zodiac / description

Added value: +"'tropical' (Western, default) or 'sidereal' (pair it with 'ayanamsa')."

addedInput schema / properties / window / properties / end / description

Added value: +"Last UTC date, YYYY-MM-DD, at most 366 days after start."

addedInput schema / properties / window / properties / include_moon / description

Added value: +"Also time the fast Moon transits; the window is then limited to 62 days."

addedInput schema / properties / window / properties / start / description
```
Added value: +"First UTC date, YYYY-MM-DD. Example: '2026-10-01'."
```

First observedOct 3, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description adds substantial behavioral detail beyond annotations: determinism via JPL DE440, no LLM involvement, inclusion of retrograde passes in window mode, the 62-day Moon limit, and the meta.result_sha256 hash in every result. It also discloses pricing ($0.08/call, first 3 free) and auth methods (x402 or MPP), which are crucial operational details not covered by the readOnly/idempotent annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured, front-loading the tool's purpose and then detailing each mode and technical guarantees. Every sentence carries information, though it could be slightly tighter by merging the pricing and determinism statements without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity — nested parameters, two modes, output hash — the description covers all critical aspects: what each mode does, temporal limits, determinism, output integrity via hash, pricing, and authentication. With a rich output schema already present, no essential information is missing for correct invocation.

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 coverage is 100%, so the schema already documents all four parameter groups thoroughly. The description mentions modes ('transit' vs 'window') and the Moon limitation, which links to the window.include_moon parameter, but does not add syntax or format details beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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 specifies a precise verb+resource — computing transits to a natal chart, with two clearly named modes ('transit' and 'window') — and explains what each mode returns. It distinguishes itself from sibling tools like natal_chart and synastry by emphasizing transits over time, not just a static chart or relationship comparison.

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?

It clearly states when to use 'transit' (aspects at one moment) vs 'window' (exact timing over up to a year), giving context for mode selection. It does not explicitly exclude or contrast with other siblings like aspects or planet_positions, so a minor gap remains.

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

All Astro Agents - deterministic Western + Vedic astrology tools Inspect

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.