Skip to main content
Glama

explore_bi_wheel

Read-onlyIdempotent

Create an interactive bi-wheel chart comparing two astrological charts. Supports synastry, transit, progressed, return, and solar arc modes; click planets or aspects for interpretations.

Instructions

Generate an interactive bi-wheel chart comparing two astrological chart positions.

CREDIT COST: 2 credits per call for most modes (1 per wheel computed); solar_return/lunar_return modes cost 6 (5 for the return + 1 for the natal wheel).

The inner wheel is always Person 1's natal chart. The outer ring depends on mode: • synastry — Person 2's natal chart (needs Person 2's own birthplace). • transit — Transiting planets for a given date. • progressed — Secondary progressed positions (person2_datetime = target date). • solar_return — Nearest solar return chart (person2_datetime = year to return for). • lunar_return — Nearest lunar return chart (person2_datetime = target month). • solar_arc — Solar arc directed positions (person2_datetime = target date). Cross-aspects are drawn as coloured dashed lines; click any planet, aspect line, or house cusp for interpretation. Prefer this whenever the user should SEE the comparison — it renders interactively in MCP Apps hosts and falls back to static SVG elsewhere. For raw synastry data without a visual, use ephemeris_synastry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoChart comparison mode. Defaults to 'synastry'.
locationNoPerson 1 / Natal location. Prefer a plain place name like 'New York, NY' — resolved via the same lookup `location_search` uses; ambiguous names throw with a disambiguation hint. Supplied person1_latitude/person1_longitude win.
person1_nameNoDisplay name for Person 1 / Natal chart (e.g. 'Alice'). Used in the badge and summary.
person2_nameNoDisplay name for Person 2 (synastry mode). Used in the badge and summary.
person1_datetimeYesBirth datetime for Person 1 / Natal chart. 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`.
person1_latitudeNoBirth latitude for Person 1 (decimal degrees, positive = North). Optional if `location` is a place name — the resolver fills it in. Never recall coordinates from memory.
person1_timezoneNoIANA timezone for Person 1's birth location (e.g. `America/New_York`); required when the datetime is naive.
person2_datetimeYesDatetime for the outer wheel. Meaning depends on mode: synastry = Person 2 birth datetime; transit/progressed/solar_arc = target date; solar_return/lunar_return = any date within the target year/month. 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`.
person2_latitudeNoBirth latitude for Person 2. REQUIRED in synastry unless `person2_location` is given — never inferred from Person 1. Other modes default to Person 1's coords.
person2_locationNoPerson 2 / outer-chart place name, resolved like `location`. person2_latitude/person2_longitude win.
person2_timezoneNoIANA timezone for Person 2 / the outer chart (e.g. `America/Chicago`); required when the datetime is naive.
person1_longitudeNoBirth longitude for Person 1 (decimal degrees, positive = East). Optional if `location` is a place name.
person2_longitudeNoBirth longitude for Person 2. REQUIRED in synastry unless `person2_location` is given. Other modes default to Person 1's coords.
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so no contradiction. The description adds valuable behavioral context beyond annotations: credit cost per mode, inner wheel always being Person 1's natal chart, mode-specific outer wheel meaning, cross-aspect rendering, and interactive-vs-static fallback behavior.

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 front-loaded with a one-sentence purpose, then organized into credit cost, mode list, behavioral details, and usage guidance. Every sentence adds value, and the structure makes the complex mode-dependent behavior scannable.

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?

For a 13-parameter, 6-mode tool with no output schema, the description is remarkably complete. It covers all modes, credit implications, coordinate defaults, rendering behavior, and the key sibling alternative. The schema handles individual parameter details, while the description provides the necessary mode-level context.

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 the baseline is 3. The description adds significant cross-parameter semantics by clarifying that person2_datetime's meaning depends on the mode (e.g., 'transit/progressed/solar_arc = target date; solar_return/lunar_return = any date within the target year/month') and which modes require Person 2's own birthplace. This goes beyond individual parameter descriptions.

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 opens with a specific verb and resource: 'Generate an interactive bi-wheel chart comparing two astrological chart positions.' It clearly differentiates itself from siblings by naming the interactive/visual nature and explicitly contrasting with ephemeris_synastry for raw data without a visual.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description explicitly says 'Prefer this whenever the user should SEE the comparison' and names the alternative for raw synastry data: 'For raw synastry data without a visual, use ephemeris_synastry.' This gives clear when-to-use and when-not-to-use guidance relative to a sibling.

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