Astro Agents - verifiable planetary timing data and astrology

Synastry

synastry

Read-onlyIdempotent

Western astrology synastry (relationship compatibility): compare two birth charts with cross-aspects, house overlays both ways and composite midpoints. Two natal charts compared: every cross-aspect with orbs, where each person's planets fall in the other's houses, harmonious/challenging counts, and composite (midpoint) positions and angles. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.12 per call via REST POST https://astro-agent.dev/v1/western/synastry (x402 or MPP); always paid, never a free call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "person_a": "<person_a>",
      "person_b": "<person_b>"
    },
    "name": "synastry"
  }
}

Input Schema

Name	Required	Description
`options`	No	Optional calculation settings; every default is the common Western convention.
`person_a`	Yes	First person's birth data.
`person_b`	Yes	Second person's birth data.

Output Schema

Name	Required	Description
`meta`	No	Provenance of the result.
`error`	No	x402 offer only: why payment is required.
`result`	No	The calculation result.
`accepts`	No	x402 offer only: the payment options (scheme, network, amount, asset, payTo, ...).
`endpoint`	No	The REST route that computed it, e.g. 'western/natal'.
`resource`	No	x402 offer only: the resource being paid for.
`extensions`	No	x402 offer only: protocol extensions (bazaar).
`x402Version`	No	x402 offer only: protocol version (2).

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 3, 2026

addedOutput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "endpoint",
+      "result",
+      "meta"
+    ]
+  },
+  {
+    "required": [
+      "x402Version",
+      "accepts"
+    ]
+  }
+]

addedOutput schema / properties / accepts

Added value: +{
+  "description": "x402 offer only: the payment options (scheme, network, amount, asset, payTo, ...).",
+  "items": {
+    "type": "object"
+  },
+  "minItems": 1,
+  "type": "array"
+}

addedOutput schema / properties / error

Added value: +{
+  "description": "x402 offer only: why payment is required.",
+  "type": "string"
+}

addedOutput schema / properties / extensions

Added value: +{
+  "description": "x402 offer only: protocol extensions (bazaar).",
+  "type": "object"
+}

addedOutput schema / properties / resource

Added value: +{
+  "description": "x402 offer only: the resource being paid for.",
+  "type": "object"
+}

addedOutput schema / properties / x402Version

Added value: +{
+  "description": "x402 offer only: protocol version (2).",
+  "type": "integer"
+}

removedOutput schema / required

Removed value: -[
-  "endpoint",
-  "result",
-  "meta"
-]

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": {
+        "aspect_counts": {
+          "description": "Number of harmonious, challenging and conjunction cross-aspects.",
+          "type": "object"
+        },
+        "composite_midpoints": {
+          "description": "Composite chart by midpoints: points, angles and the method used.",
+          "type": "object"
+        },
+        "cross_aspects": {
+          "description": "Aspects between a point of person A and a point of person B, with orb and exactness.",
+          "type": "array"
+        },
+        "house_overlays": {
+          "description": "Which house of the other chart each person's points fall in.",
+          "type": "object"
+        },
+        "person_a": {
+          "description": "First person's chart: subject, points and angles.",
+          "type": "object"
+        },
+        "person_b": {
+          "description": "Second person's chart: subject, points and angles.",
+          "type": "object"
+        },
+        "settings": {
+          "description": "Settings applied: zodiac, house system and the aspect set with its orbs.",
+          "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"
+        }
+      },
+      "required": [
+        "person_a",
+        "person_b",
+        "settings",
+        "cross_aspects",
+        "aspect_counts",
+        "house_overlays",
+        "composite_midpoints"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "endpoint",
+    "result",
+    "meta"
+  ],
+  "type": "object"
+}

Changed6 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 / person_a / description
```
Added value: +"First person's birth data."
```
addedInput schema / properties / person_b / description
```
Added value: +"Second person's birth data."
```

First observedOct 3, 2026

TDQS

A4/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 bar is covered; the description adds genuinely non-redundant behavior: deterministic JPL DE440 computation with no LLM, a verifiable meta.result_sha256 on every result, and a hard pricing/payment constraint ($0.12 per call, always paid, x402 or MPP). It does not mention that the hash can be checked against the verify_result_hash sibling, which is the one useful behavioral link left out.

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?

Three front-loaded sentences open with the operation and output set, then determinism/verification, then price and endpoint; nothing is filler. Minor redundancy between 'compare two birth charts' and 'Two natal charts compared', and the endpoint/payment detail could be tightened.

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 an output schema exists, the description need not explain return values, and with four annotations plus 100% schema coverage the remaining burden is cost, determinism, and verification — all of which are stated. Nothing an agent needs in order to invoke it correctly 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% and the nested person_a/person_b option schemas document every field, enum, default, and example themselves, so the description's obligations are already met by the structured data. The description only restates the output dimensions (orbs, house overlays, midpoints) rather than adding format or constraint meaning beyond what the schema says.

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?

Names a specific verb and resource ('Western astrology synastry... compare two birth charts') and enumerates the concrete outputs: cross-aspects with orbs, house overlays both ways, harmonious/challenging counts, and composite midpoints. The 'Western' qualifier implicitly separates it from the Vedic compatibility siblings (gun_milan, kundli), so an agent can route 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 Guidelines3/5

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

Usage is implied by the rich output enumeration and the 'relationship compatibility' framing, but there is no explicit when-to-use/when-not statement and no named alternative such as token_synastry (token-wheel variant) or gun_milan (Vedic compatibility) for the agent to choose between. The pricing/payment sentence is invocation guidance, not selection guidance.

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

All Astro Agents - verifiable planetary timing data and 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.