Astro Agents - deterministic Western + Vedic astrology

Aspects

aspects

Read-onlyIdempotent

Western astrology aspects: find the aspects between planets at a moment, or between longitudes you supply, with orb, exactness and applying or separating. Either give a moment (datetime, optional place) and get the aspects among all planets, or give 'longitudes' {name: degrees} and get the pure geometry. Orbs are explicit and overridable. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.02 per call via REST POST https://astro-agent.dev/v1/western/aspects (x402 or MPP); your first 3 calls are free here.

Input Schema

Name	Required	Description	Default
`date`	No	YYYY-MM-DD (use with 'time' instead of 'datetime').
`time`	No	HH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning).
`options`	No	Optional calculation settings; every default is the common Western convention.
`datetime`	No	Local birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'.
`latitude`	No	Decimal degrees, north positive.
`timezone`	No	IANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date.
`longitude`	No	Decimal degrees, east positive.
`longitudes`	No	Optional {name: degrees} or {name: {longitude, speed}}; when given, no ephemeris is used.
`time_basis`	No	What the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time.	civil
`ambiguous_time`	No	Which occurrence to use when a local time happens twice (DST fall-back).	earlier

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": {
+        "aspects": {
+          "description": "Aspects between two points: point_a, point_b, aspect name, exact angle, orb, allowed orb, exactness percentage and whether it is applying or separating.",
+          "type": "array"
+        },
+        "settings": {
+          "description": "The aspect set and orbs applied, and where the longitudes came from.",
+          "type": "object"
+        }
+      },
+      "required": [
+        "settings",
+        "aspects"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "endpoint",
+    "result",
+    "meta"
+  ],
+  "type": "object"
+}

Changed4 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')."

First observedOct 3, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-derivable behavior: deterministic JPL DE440 computation with no LLM, a meta.result_sha256 on every result, and the billing model ($0.02/call via REST with x402 or MPP, first 3 calls free) — cost and payment behavior an agent cannot infer from 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 core capability and the mode split are front-loaded in the first two sentences, and the remaining details (determinism, hash, pricing) are compact. The pricing/endpoint tail is somewhat dense but each clause carries actionable information, so little is wasted.

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-value shape need not be explained. With 10 optional params, nested option objects, and two modes, the description supplies the missing operational context (mode selection, determinism, hash, cost) needed to invoke it correctly; only sibling routing is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so a baseline of 3 applies. The description adds meaning the schema does not: it establishes that 'longitudes' bypasses the ephemeris entirely ('pure geometry'), and that orbs are 'explicit and overridable', clarifying the relationship between the two input families and the options.orbs field.

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+resource ('find the aspects between planets') and immediately scopes it as Western astrology, which distinguishes it from the Vedic siblings (kundli, doshas, vimshottari_dasha). It also enumerates the two distinct operating modes (moment-based vs supplied longitudes), so an agent can tell exactly what the tool computes without opening the 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?

It gives explicit routing between the two modes: 'Either give a moment (datetime, optional place) ... or give longitudes {name: degrees} and get the pure geometry.' That is strong internal usage guidance. It stops short of naming when to prefer a sibling (e.g. synastry for cross-chart aspects), so it is clear context without exclusions.

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.