Natal chart MCP · step-by-step
How to generate a natal chart with MCP
A reproducible path from a place name to structured chart data — with the timezone, birth-time, precision and privacy boundaries kept attached.
Direct answer
To generate a natal chart with MCP, connect Astral MCP to an MCP-compatible client, inspect astral_capabilities, resolve the birthplace with astral_search_birthplace, and pass the selected latitude, longitude and birthplace timezone to astral_compute_natal_chart. Keep verify_precision enabled, choose a privacy_mode, and inspect the precision status before asking the model to explain the structured chart.
Chart computation runs locally and stores no reading history. The optional birthplace lookup is the only network step.
Seven bounded steps
Compute first. Explain second.
The MCP client calls named tools and carries their structured results into model context. The model should explain those fields, not invent or recalculate placements.
- Connect Astral MCPAdd
npx -y astral-mcpto the MCP client. Callastral_connection_statusandastral_demobefore sending real birth data. - Inspect the contractCall
astral_capabilitiesfor supported house systems, zodiacs, bodies, aspects and exclusions. - Resolve the birthplaceCall
astral_search_birthplace, inspect every returned display name and preserve the selected latitude, longitude and timezone together. - Compute the chartCall
astral_compute_natal_chartwith the birth date, optional time, coordinates and the birthplace timezone. - Choose the payloadStart with
privacy_mode: "summary"; expand only when the question needs more fields. - Inspect the evidenceKeep
verify_precisiontrue and preserveverifiedorreviewstatus. - Explain the resultAsk the model to interpret the returned data while disclosing unknown birth time and non-advice boundaries.
The official MCP tools specification defines the client-to-server tool discovery and call pattern used here.
Core tool input
Keep the birthplace fields together.
The timezone is the IANA timezone of the birthplace, not the caller's current timezone. If the birth time is unknown, omit it instead of inventing precision.
{
"birth_date": "1989-02-23",
"birth_time": "14:30",
"latitude": -3.7319,
"longitude": -38.5267,
"timezone": "America/Fortaleza",
"house_system": "placidus",
"zodiac": "tropical",
"verify_precision": true,
"privacy_mode": "summary",
"response_format": "json"
}Optional network boundary
Place search is useful, not unlimited.
astral_search_birthplace sends the place-name string to the public OpenStreetMap Nominatim service. If you already know the coordinates and historical IANA timezone, skip this call.
Inspect the complete display name rather than accepting the first same-named city.
The official policy sets an absolute maximum of one request per second and prohibits autocomplete and systematic or bulk queries.
Use deliberate, user-triggered place searches only. Never put personal or confidential material in the query.
Read the current Nominatim Usage Policy. Astral MCP sends an identifying User-Agent, but callers remain responsible for attribution, rate and acceptable use.
Precision boundary
Verified means computational agreement.
Astral MCP computes the chart with its primary engine and independently re-derives planetary longitudes with Astronomy Engine. Checked placements must agree within tolerance and remain in the same sign for a verified result.
A disagreement becomes review instead of being silently accepted.
The audit measures computational agreement. It does not validate astrology, prove an interpretation or turn a reading into scientific or predictive fact.
Unknown birth time
Missing data must stay visible.
When birth_time is omitted, noon is assumed. Planetary signs remain usable within the documented boundary, but the Ascendant and houses are not reliable. The result exposes meta.birthTimeKnown so an agent can keep that disclosure attached.
Context economy
Start with the smallest useful payload.
summary
Luminaries, Ascendant, chart signature, top aspects and precision status.
structured
Full structure with redundant and derivable fields removed.
full
Every placement, house, aspect and per-planet precision row.
Failure modes
Eight mistakes to avoid.
- Wrong timezonePassing the caller's timezone instead of the birthplace timezone.
- Wrong citySelecting the first geocoder result without reading its full display name.
- Invented timeCreating an exact birth time when the source does not provide one.
- False angle confidenceTreating the Ascendant and houses as reliable after a noon assumption.
- Hidden skipped auditDisabling
verify_precisionwithout telling the user. - Oversized contextRequesting
fullwhensummaryanswers the question. - Model recomputationAsking the model to guess placements instead of reading tool output.
- Geocoder misuseUsing public Nominatim for autocomplete, bulk or confidential queries.
Astral MCP is not financial, medical, legal or psychological advice. Do not use a chart as evidence for consequential decisions.
Frequently asked
Short answers for agents and builders.
Can an agent generate a birth chart without an astrology API key?
Yes. Astral MCP runs locally through an MCP client and requires no astrology API account. The optional public geocoder also has no key, but its usage policy applies.
What happens when the birth time is missing?
Noon is assumed and the output records that the time was unknown. The Ascendant and houses must not be treated as reliable.
Does verified mean the reading is scientifically validated?
No. It means the two computational paths agreed within tolerance. It does not validate astrology or the model's interpretation.
Is birth data stored?
No. The server is stateless and stores no reading history. Only an optional birthplace lookup sends the place-name string to OpenStreetMap.
Continue learning
Understand the pattern behind the workflow.
Read What Is an Astrology MCP Server? for the protocol-level separation between computation, transport and interpretation. For a field-by-field privacy review, see How to Protect Birth Data in Astrology Agent Workflows.