Asterwise

Western Natal Chart

asterwise_get_western_natal

Read-onlyIdempotent

Calculate a complete Western natal chart using the tropical zodiac and Swiss Ephemeris. Returns 10 planet positions with Placidus (or chosen) house placements, sign-level dignities plus Lilly essential-dignity scores, all active aspects, and element/modality/hemisphere balance statistics.

WORKFLOW: BEFORE: None — this tool is standalone. AFTER: asterwise_get_western_transits_daily — layer current transits over this natal chart. AFTER: asterwise_get_western_synastry — compare this chart against a partner's chart. AFTER: asterwise_get_western_solar_return — annual return chart for the current year.

INPUT CONTRACT: birth.date — YYYY-MM-DD. Example: '1985-11-12' birth.time — HH:MM (24-hour local time). Example: '06:45' birth.lat — Decimal degrees, north positive. Example: 19.076 (Mumbai) birth.lon — Decimal degrees, east positive. Example: 72.8777 (Mumbai) birth.timezone — IANA timezone string. Example: 'Asia/Kolkata', 'America/New_York', 'Europe/Rome', 'UTC'. Default: UTC. IMPORTANT: Timezone defaults to UTC — always supply the correct local timezone for accurate house cusps. An incorrect timezone shifts the Ascendant. birth.house_system — 'placidus' (default, most common), 'koch', 'equal', 'whole_sign'. Placidus is standard for most Western traditions. Whole sign is traditional/Hellenistic. NOTE: house_system is accepted here but silently ignored by return, synastry, composite, and progression endpoints — those always use the birth location coordinates without house-system selection. ayanamsa — always tropical regardless of any value supplied; field is not present.

DO NOT CONFUSE WITH: asterwise_get_natal_chart — Vedic sidereal chart using Lahiri ayanamsa; different zodiac, different house system, different planet set (9 grahas vs 10 tropical planets). asterwise_get_western_aspects — takes raw longitudes as input; use when you already have positions and don't need full chart computation.

Full output and error contract: https://docs.asterwise.com/mcp/tools/get-western-natal/

Input Schema

Name	Required	Description	Default
`birth`	Yes	Birth data for Western astrology tools (tropical zodiac).
`response_format`	No	Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.	markdown

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 5, 2026

addedInput schema / properties / response_format / description

Added value: +"Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload."

Changed2 schema fields changedSep 4, 2026
- addedInput schema / properties / response_format / default
```
Added value: +"markdown"
```
- changedInput schema / required
```
Previous value: -[
-  "birth",
-  "response_format"
-]New value: +[
+  "birth"
+]
```
AddedMay 1, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes further by enumerating what is computed (10 planets, Placidus houses, Lilly dignity scores, aspects, balance stats) and by warning that timezone defaults to UTC and that an incorrect value shifts the Ascendant, plus that house_system is silently ignored on downstream endpoints. That last point is real behavioral disclosure; only return/pagination detail is absent, and an output schema exists.

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?

The description is long but every block (purpose, WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH) is separately headed and front-loaded, with the core purpose in the first sentence. Slightly verbose in the parameter examples, but no sentence is pure filler.

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 computation tool with nested birth objects and an output schema, the definition covers inputs, defaults, footguns, output contents, and sibling routing. An agent has everything needed to call it correctly on the first attempt without consulting the external doc link.

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, but the description adds genuine meaning: the timezone default being a correctness hazard ('An incorrect timezone shifts the Ascendant'), the guidance that Placidus is standard while whole sign is Hellenistic, and the note that ayanamsa is not present because the chart is always tropical.

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 first sentence states a specific verb and resource ('Calculate a complete Western natal chart') plus the underlying method (tropical zodiac, Swiss Ephemeris). The DO NOT CONFUSE WITH block explicitly distinguishes it from asterwise_get_natal_chart (Vedic sidereal) and asterwise_get_western_aspects (raw longitudes), so an agent can disambiguate without opening any schema.

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 WORKFLOW block gives explicit before/after routing to transits_daily, synastry, and solar_return, and the DO NOT CONFUSE WITH section names the conditions under which each alternative should be used instead. Both when-to-use and when-to-use-something-else are stated.

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

All Asterwise tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?