Skip to main content
Glama

Interactive Chart Wheel Explorer

explore_natal_chart
Read-onlyIdempotent

Generate an interactive natal or birth chart from date, time and place, then explore it by clicking planets, houses and aspects for interpretation and switching house systems.

Instructions

Use this when the user asks 'make my natal chart', 'show me my birth chart', 'what's my rising sign', 'my big 3', 'what's my sun, moon and rising', 'what sign is my Moon / Venus / Mars in', 'what does my chart say about my career / love', 'read my chart', or shares birth details and wants to explore them — any natal / birth-chart / astrology-chart request. Returns an interactive chart wheel rendered inline (Claude and ChatGPT; text summary elsewhere) where any planet, house or aspect line can be clicked for interpretation, with switchable house systems. The birthplace can be given as location (a place name — resolved server-side) or as coordinates, with the birth date, local time and zone.

CREDIT COST: 1 credit per call (+1 to resolve a place name).

Input Schema

NameRequiredDescriptionDefault
bodiesNoDefault 13 (Sun–Pluto, Chiron, Nodes); ['all'] adds Liliths, asteroids, TNOs, Uranian points. E.g. ['sun','lilith','lilith_true','sedna'].
ayanamsaNoDefault lahiri; sidereal only.
datetimeYesISO 8601; zone required (`Z`/offset, or local time plus `timezone`).
latitudeNoBirth latitude (optional with `location`).
locationNoBirth place name, e.g. 'New York, NY'; geocoded. Coordinates win if given.
timezoneNoIANA zone for a local datetime.
longitudeNoBirth longitude (optional with `location`).
zodiac_typeNoDefault tropical.
house_systemNoDefault placidus.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv4.29.0
    • changedInput schema / properties / bodies / description
      Previous value: -"Optional list of body names to include. Defaults to 13 classical bodies (Sun through Pluto + Chiron + Nodes). Use 'all' as a single item to include every available body (the three Liliths — mean, true and interpolated — Ceres, Juno, Vesta, Pallas, Pholus, the 8 trans-Neptunian objects — eris, sedna, makemake, haumea, quaoar, orcus, ixion, varuna — and the 8 Uranian/Hamburg-School points — cupido, hades, zeus, kronos, apollon, admetos, vulkanus, poseidon). Lilith slugs: 'lilith' (mean), 'lilith_true', 'lilith_interpolated'. Example: ['sun','moon','lilith','sedna']."New value: +"Default 13 (Sun–Pluto, Chiron, Nodes); ['all'] adds Liliths, asteroids, TNOs, Uranian points. E.g. ['sun','lilith','lilith_true','sedna']."
    • changedInput schema / properties / 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 / house_system / description
      Previous value: -"House system to use (default: placidus)."New value: +"Default placidus."
    • changedInput schema / properties / latitude / description
      Previous value: -"Birth latitude in decimal degrees (positive = North). Optional if `location` is a place name — the resolver fills it in. Takes decimal degrees, not a place name."New value: +"Birth latitude (optional with `location`)."
    • changedInput schema / properties / location / description
      Previous value: -"Birth location as a plain place name like 'New York, NY'; the server resolves it to coordinates and timezone (ambiguous names are rejected with a disambiguation hint). Supplied coordinates take precedence over it."New value: +"Birth place name, e.g. 'New York, NY'; geocoded. Coordinates win if given."
    • changedInput schema / properties / longitude / description
      Previous value: -"Birth longitude in decimal degrees (positive = East). Optional if `location` is a place name."New value: +"Birth longitude (optional with `location`)."
    • changedInput schema / properties / timezone / description
      Previous value: -"IANA timezone (e.g. `America/Chicago`); required when the datetime is naive, ignored otherwise."New value: +"IANA zone for a local datetime."
  2. Changed2 schema fields changedv4.27.0
    • addedInput schema / properties / ayanamsa
      Added value: +{
      +  "description": "Default lahiri; sidereal only.",
      +  "enum": [
      +    "lahiri",
      +    "fagan_bradley",
      +    "krishnamurti",
      +    "raman",
      +    "yukteshwar"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / zodiac_type
      Added value: +{
      +  "description": "Default tropical.",
      +  "enum": [
      +    "tropical",
      +    "sidereal"
      +  ],
      +  "type": "string"
      +}
  3. Changed4 schema fields changedv4.24.2
    • changedInput schema / properties / bodies / description
      Previous value: -"Optional list of body names to include. Defaults to 13 classical bodies (Sun through Pluto + Chiron + Nodes). Use 'all' as a single item to include every available body (Lilith, Ceres, Juno, Vesta, Pallas, Vertex, etc.). Example: ['sun','moon','lilith','vertex']."New value: +"Optional list of body names to include. Defaults to 13 classical bodies (Sun through Pluto + Chiron + Nodes). Use 'all' as a single item to include every available body (the three Liliths — mean, true and interpolated — Ceres, Juno, Vesta, Pallas, Pholus, the 8 trans-Neptunian objects — eris, sedna, makemake, haumea, quaoar, orcus, ixion, varuna — and the 8 Uranian/Hamburg-School points — cupido, hades, zeus, kronos, apollon, admetos, vulkanus, poseidon). Lilith slugs: 'lilith' (mean), 'lilith_true', 'lilith_interpolated'. Example: ['sun','moon','lilith','sedna']."
    • changedInput schema / properties / 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 / latitude / description
      Previous value: -"Birth latitude in decimal degrees (positive = North). Optional if `location` is a place name — the resolver fills it in. If you supply lat/lon directly, resolve them with location_search first; never recall coordinates from memory."New value: +"Birth latitude in decimal degrees (positive = North). Optional if `location` is a place name — the resolver fills it in. Takes decimal degrees, not a place name."
    • changedInput schema / properties / location / description
      Previous value: -"Birth location. Prefer a plain place name like 'New York, NY' — the server resolves it via the same lookup `location_search` uses (unambiguous names → coords + timezone; ambiguous names throw with a disambiguation hint). If you already have coords, either omit this or use it as a display caption; supplied coords always win."New value: +"Birth location as a plain place name like 'New York, NY'; the server resolves it to coordinates and timezone (ambiguous names are rejected with a disambiguation hint). Supplied coordinates take precedence over it."
  4. Changed7 schema fields changedv4.8.0
    • addedInput schema / properties / bodies
      Added value: +{
      +  "description": "Optional list of body names to include. Defaults to 13 classical bodies (Sun through Pluto + Chiron + Nodes). Use 'all' as a single item to include every available body (Lilith, Ceres, Juno, Vesta, Pallas, Vertex, etc.). Example: ['sun','moon','lilith','vertex'].",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / datetime / description
      Previous value: -"ISO 8601 datetime string, e.g. '1990-04-15T14:30:00'. Include timezone offset if known, e.g. '1990-04-15T14:30:00-05:00'."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 / latitude / description
      Previous value: -"Birth latitude in decimal degrees (positive = North)."New value: +"Birth latitude in decimal degrees (positive = North). Optional if `location` is a place name — the resolver fills it in. If you supply lat/lon directly, resolve them with location_search first; never recall coordinates from memory."
    • changedInput schema / properties / location / description
      Previous value: -"Location name for display only (e.g. 'New York, NY')."New value: +"Birth location. Prefer a plain place name like 'New York, NY' — the server resolves it via the same lookup `location_search` uses (unambiguous names → coords + timezone; ambiguous names throw with a disambiguation hint). If you already have coords, either omit this or use it as a display caption; supplied coords always win."
    • changedInput schema / properties / longitude / description
      Previous value: -"Birth longitude in decimal degrees (positive = East)."New value: +"Birth longitude in decimal degrees (positive = East). Optional if `location` is a place name."
    • changedInput schema / properties / timezone / description
      Previous value: -"IANA timezone name (e.g. 'America/New_York'). Used if datetime has no UTC offset."New value: +"IANA timezone (e.g. `America/Chicago`); required when the datetime is naive, ignored otherwise."
    • changedInput schema / required
      Previous value: -[
      -  "datetime",
      -  "latitude",
      -  "longitude"
      -]New value: +[
      +  "datetime"
      +]
  5. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the read-only/idempotent annotations: discloses the interactive chart wheel rendered inline, that it degrades to a text summary outside Claude/ChatGPT, that planets/houses/aspect lines are clickable, that house systems are switchable, and the credit cost including the extra charge for place-name resolution. The 100%-coverage annotations mean this description only needed to add value, and it does substantially.

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?

Front-loads the trigger phrases, then return behavior, then input modes, then cost — a sensible order. The long quoted-utterance list is slightly redundant once 'any natal / birth-chart request' is stated, but it is high-signal for routing and nothing is padding.

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?

With 9 parameters, no output schema and no annotations covering output, the description carries the return-value burden and does so: interactive wheel with clickable elements and switchable house systems, with an explicit text fallback per client. Input modes (place name vs coordinates vs timezone) and cost are all addressed, leaving nothing an agent needs missing.

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 already 100%, yet the description still adds decision-relevant meaning: `location` is geocoded server-side, coordinates win when both are supplied, and only a place name incurs the extra credit. It does not explain the `bodies`/`ayanamsa` interplay (e.g. sidereal-only ayanamsa) beyond what the schema says.

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 concrete verb+resource (explore natal chart) and enumerates realistic user phrasings ('my big 3', 'what's my rising sign'). It does not distinguish itself from siblings such as ephemeris_natal_chart, explore_vedic_chart or human_design_chart, and in fact claims 'any natal / birth-chart / astrology-chart request', which blurs the boundary rather than sharpening it.

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?

Gives strong positive routing cues — quoted user utterances plus 'any natal / birth-chart / astrology-chart request' — so an agent knows when to pick it. It stops short of exclusions: it never says to use explore_vedic_chart for a sidereal/Vedic reading or ephemeris_natal_chart when raw data (not an interactive wheel) is wanted, despite overlap in the sibling list.

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