Skip to main content
Glama
openephemeris

Open Ephemeris

by openephemeris
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

ephemeris_synastry

Read-onlyIdempotent

Compare two natal charts to reveal planetary inter-aspects and relationship indicators for compatibility analysis.

Instructions

Calculate a synastry chart comparing two people's natal charts. Returns inter-aspects (planetary connections between the two charts), composite points, and relationship indicators. Use this for compatibility analysis, relationship timing, or partnership insights.

CREDIT COST: 3 credits per call.

EXAMPLE: Compare two people's charts (local birth times, each with its zone): person_a_datetime='1990-04-15T14:30:00', person_a_timezone='America/Chicago', person_a_latitude=41.8781, person_a_longitude=-87.6298, person_b_datetime='1988-09-22T08:15:00', person_b_timezone='America/Los_Angeles', person_b_latitude=34.0522, person_b_longitude=-118.2437

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoOutput format. 'llm' is compact and token-efficient (available on all tiers).
house_systemNoHouse system for both charts. Defaults to 'placidus'.
visual_configNoOptional rendering preferences (only used when include_visual=true).
include_visualNoWhen 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.
person_a_datetimeYesISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`.
person_a_latitudeYesPerson A birth latitude. Resolve from a place name with location_search; never recall coordinates from memory.
person_a_timezoneNoIANA timezone for Person A's birth location (e.g. `America/Chicago`); required when the datetime is naive.
person_b_datetimeYesISO 8601 datetime; zone required — a `Z`/±HH:MM suffix or the `timezone` argument. Date-only resolves to 12:00 UTC. Full rule: server `instructions`.
person_b_latitudeYesPerson B birth latitude.
person_b_timezoneNoIANA timezone for Person B's birth location (e.g. `America/Los_Angeles`); required when the datetime is naive.
person_a_longitudeYesPerson A birth longitude.
person_b_longitudeYesPerson B birth longitude.

Tool Definition Quality

A4.4/5.0
Behavior4/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds credit cost (3 credits), extra cost for visuals, and the fact that visual output displays in conversation. It also gives a detailed example demonstrating timezone handling, which is a useful behavioral disclosure.

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?

The description is well-structured: purpose, output, use cases, cost, then a concrete example. Every sentence serves a purpose, and the example is compact but informative. No fluff or repetition.

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?

The tool is complex (12 parameters, nested visual_config, no output schema), but the description covers purpose, output categories, usage, cost, and an example. It does not detail every output field, but that is acceptable given the high-level summary provided.

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 coverage is 100%, so baseline is 3. The description goes beyond by providing a full example with all parameters populated, clarifying how to pass datetimes with timezone info and coordinates. This adds practical context not present in the schema.

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?

Description clearly states it calculates a synastry chart comparing two people's natal charts, with specific output types (inter-aspects, composite points, relationship indicators). This distinguishes it from sibling tools like natal chart (single chart) or transits by the comparative/compatibility angle.

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?

Explicitly states use cases: 'compatibility analysis, relationship timing, or partnership insights.' It does not name alternatives or exclusions, but the context is clear enough for an agent to infer when to choose this tool over single-chart or transit tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/openephemeris/openephemeris-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server