Open Ephemeris

Synastry Chart

ephemeris_synastry

Read-onlyIdempotent

Compute cross-aspects with orbs between two birth charts for relationship analysis. Returns synastry aspects plus both natal charts as JSON from each person's birth datetime, timezone and coordinates.

Instructions

Use this when the relationship comparison is wanted as data — 'list our inter-aspects with orbs', 'what aspects does their Mars make to my Venus', 'our synastry as JSON'. Returns the cross-aspects between the two charts plus both natal charts; needs each person's birth datetime, zone and coordinates.

CREDIT COST: 3 credits per call.

Input Schema

Name	Required	Description
`format`	No	'llm' = compact.
`house_system`	No	Default placidus.
`visual_config`	No	Rendering options for include_visual.
`include_visual`	No	Embed a bi-wheel SVG. +2 credits.
`person_a_datetime`	Yes	ISO 8601; zone required (`Z`/offset, or local time plus `timezone`).
`person_a_latitude`	Yes	Person A birth latitude.
`person_a_timezone`	No	IANA zone for Person A's birth location (local datetime).
`person_b_datetime`	Yes	ISO 8601; zone required (`Z`/offset, or local time plus `timezone`).
`person_b_latitude`	Yes	Person B birth latitude.
`person_b_timezone`	No	IANA zone for Person B's birth location (local datetime).
`person_a_longitude`	Yes	Person A birth longitude.
`person_b_longitude`	Yes	Person B birth longitude.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv4.29.0Oct 28, 2026

changedInput schema / properties / format / description

Previous value: -"Output format. 'llm' is compact and token-efficient (available on all tiers)."New value: +"'llm' = compact."

changedInput schema / properties / house_system / description

Previous value: -"House system for both charts. Defaults to 'placidus'."New value: +"Default placidus."

changedInput schema / properties / include_visual / description

Previous value: -"When true, renders a bi-wheel SVG comparing both charts and embeds it in the response. Costs 2 additional credits on top of the base call cost."New value: +"Embed a bi-wheel SVG. +2 credits."

changedInput schema / properties / person_a_datetime / description

Previous value: -"ISO 8601 datetime. A datetime with no zone is rejected; give a `Z` or ±HH:MM suffix, or a local time with the `timezone` argument. Date-only resolves to 12:00 UTC."New value: +"ISO 8601; zone required (`Z`/offset, or local time plus `timezone`)."

changedInput schema / properties / person_a_timezone / description

Previous value: -"IANA timezone for Person A's birth location (e.g. `America/Chicago`); required when the datetime is naive."New value: +"IANA zone for Person A's birth location (local datetime)."

changedInput schema / properties / person_b_datetime / description

Previous value: -"ISO 8601 datetime. A datetime with no zone is rejected; give a `Z` or ±HH:MM suffix, or a local time with the `timezone` argument. Date-only resolves to 12:00 UTC."New value: +"ISO 8601; zone required (`Z`/offset, or local time plus `timezone`)."

changedInput schema / properties / person_b_timezone / description

Previous value: -"IANA timezone for Person B's birth location (e.g. `America/Los_Angeles`); required when the datetime is naive."New value: +"IANA zone for Person B's birth location (local datetime)."

changedInput schema / properties / visual_config / description

Previous value: -"Optional rendering preferences (only used when include_visual=true)."New value: +"Rendering options for include_visual."

changedInput schema / properties / visual_config / properties / size / description

Previous value: -"Canvas size in pixels, 200–4000. Default: 800."New value: +"Pixels, 200–4000. Default 800."

changedInput schema / properties / visual_config / properties / theme / description
```
Previous value: -"Color theme. Default: light."New value: +"Default light."
```

Changed4 schema fields changedv4.24.2Oct 24, 2026

changedInput schema / properties / include_visual / description

Previous value: -"When true, renders a bi-wheel SVG comparing both charts and embeds it in the response. The chart image will display in the conversation alongside the data. Costs 2 additional credits on top of the base call cost."New value: +"When true, renders a bi-wheel SVG comparing both charts and embeds it in the response. Costs 2 additional credits on top of the base call cost."

changedInput schema / properties / person_a_datetime / description

Previous value: -"ISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`."New value: +"ISO 8601 datetime. A datetime with no zone is rejected; give a `Z` or ±HH:MM suffix, or a local time with the `timezone` argument. Date-only resolves to 12:00 UTC."

changedInput schema / properties / person_a_latitude / description

Previous value: -"Person A birth latitude. Resolve from a place name with location_search; never recall coordinates from memory."New value: +"Person A birth latitude."

changedInput schema / properties / person_b_datetime / description

Previous value: -"ISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`."New value: +"ISO 8601 datetime. A datetime with no zone is rejected; give a `Z` or ±HH:MM suffix, or a local time with the `timezone` argument. Date-only resolves to 12:00 UTC."

Changed5 schema fields changedv4.8.0Aug 3, 2026

changedInput schema / properties / person_a_datetime / description

Previous value: -"Person A birth datetime (ISO 8601)."New value: +"ISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`."

changedInput schema / properties / person_a_latitude / description

Previous value: -"Person A birth latitude."New value: +"Person A birth latitude. Resolve from a place name with location_search; never recall coordinates from memory."

addedInput schema / properties / person_a_timezone

Added value: +{
+  "description": "IANA timezone for Person A's birth location (e.g. `America/Chicago`); required when the datetime is naive.",
+  "type": "string"
+}

changedInput schema / properties / person_b_datetime / description

Previous value: -"Person B birth datetime (ISO 8601)."New value: +"ISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`."

addedInput schema / properties / person_b_timezone

Added value: +{
+  "description": "IANA timezone for Person B's birth location (e.g. `America/Los_Angeles`); required when the datetime is naive.",
+  "type": "string"
+}

First observedv0.1.0Apr 24, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description adds value by disclosing the credit cost (3 per call, with +2 noted in the schema for visuals) and what the response contains (cross-aspects + both natal charts). It doesn't mention latency, caching, or failure modes, keeping 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.

Conciseness5/5

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

Front-loaded trigger condition, then what is returned, then required inputs, then cost — each sentence earns its place with no redundancy.

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 no output schema, the description carries the return-value burden and does so ('cross-aspects... plus both natal charts'), and it discloses cost for a 12-parameter tool. Minor gap: the json vs llm format option and visual embedding are never mentioned in prose, so an agent must read the schema to know they 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 coverage is 100%, so the schema already documents all 12 parameters, including timezone, house_system and the format enum. The description only restates the required birth datetime/zone/coordinates and adds no guidance on format choice, house system, or when to spend the extra credits on include_visual — so baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific operation and output: returns cross-aspects between two charts plus both natal charts. The 'wanted as data' framing implicitly separates it from the visual/LLM-oriented siblings (e.g. explore_bi_wheel), though no sibling is named explicitly.

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?

'Use this when the relationship comparison is wanted as data' gives a clear selection condition, reinforced by concrete example utterances ('list our inter-aspects with orbs', 'our synastry as JSON'). It lacks an explicit when-not clause or a named alternative tool for the non-data case.

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

Deploy Server

Synastry Chart

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools