Skip to main content
Glama

Astro Agents - deterministic Western + Vedic astrology

Western natal chart

natal_chart
Read-onlyIdempotent

Western astrology natal chart (birth chart, horoscope): planets in zodiac signs and houses, sun sign, moon sign and rising sign (ascendant), MC, aspects and a summary. Everything a natal reading needs, computed exactly: positions, house cusps (Placidus by default; Koch, Whole Sign, Equal, Porphyry, Regiomontanus, Campanus, Topocentric, Alcabitius, Morinus, Meridian), ascendant/MC/DSC/IC, aspects with orbs and applying/separating state, element and modality balance, chart ruler, sect and Part of Fortune. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.06 per call via REST POST https://astro-agent.dev/v1/western/natal (x402 or MPP); your first 3 calls are free here.

Input Schema

NameRequiredDescriptionDefault
dateNoYYYY-MM-DD (use with 'time' instead of 'datetime').
timeNoHH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning).
optionsNoOptional calculation settings; every default is the common Western convention.
datetimeNoLocal birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'.
latitudeYesDecimal degrees, north positive.
timezoneNoIANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date.
longitudeYesDecimal degrees, east positive.
time_basisNoWhat the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time.civil
ambiguous_timeNoWhich occurrence to use when a local time happens twice (DST fall-back).earlier

Output Schema

NameRequiredDescriptionDefault
metaYesProvenance of the result.
resultYesThe calculation result.
endpointYesThe REST route that computed it, e.g. 'western/natal'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "endpoint": {
      +      "description": "The REST route that computed it, e.g. 'western/natal'.",
      +      "type": "string"
      +    },
      +    "meta": {
      +      "description": "Provenance of the result.",
      +      "properties": {
      +        "astronomy_library": {
      +          "description": "Astronomy library and version.",
      +          "type": "string"
      +        },
      +        "compute_ms": {
      +          "description": "Computation time in milliseconds.",
      +          "type": "number"
      +        },
      +        "computed_at": {
      +          "description": "When it was computed (UTC, ISO 8601).",
      +          "type": "string"
      +        },
      +        "deterministic": {
      +          "description": "Always true: same input, same result.",
      +          "type": "boolean"
      +        },
      +        "engine": {
      +          "description": "Engine name and version.",
      +          "type": "string"
      +        },
      +        "ephemeris": {
      +          "description": "Ephemeris used (NASA/JPL DE440).",
      +          "type": "string"
      +        },
      +        "frame": {
      +          "description": "Reference frame of the positions.",
      +          "type": "string"
      +        },
      +        "input_sha256": {
      +          "description": "SHA-256 of the canonical input.",
      +          "type": "string"
      +        },
      +        "llm_used": {
      +          "description": "Always false: no language model is involved.",
      +          "type": "boolean"
      +        },
      +        "payment": {
      +          "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
      +          "type": "object"
      +        },
      +        "reproducibility": {
      +          "description": "How to reproduce and check this result.",
      +          "type": "string"
      +        },
      +        "result_sha256": {
      +          "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "engine",
      +        "deterministic",
      +        "llm_used",
      +        "input_sha256",
      +        "result_sha256"
      +      ],
      +      "type": "object"
      +    },
      +    "result": {
      +      "description": "The calculation result.",
      +      "properties": {
      +        "angles": {
      +          "description": "Ascendant, midheaven, descendant and imum coeli, each with longitude and sign.",
      +          "type": "object"
      +        },
      +        "aspects": {
      +          "description": "Aspects between two points: point_a, point_b, aspect name, exact angle, orb, allowed orb, exactness percentage and whether it is applying or separating.",
      +          "type": "array"
      +        },
      +        "houses": {
      +          "description": "The twelve house cusps: longitude, sign, degree in sign, element and modality.",
      +          "type": "array"
      +        },
      +        "points": {
      +          "description": "One entry per body or point (Sun to Pluto, lunar nodes, Chiron...): ecliptic longitude, sign, degree in sign, element, modality, latitude, daily speed, retrograde flag, distance in AU and, with a location, the house.",
      +          "type": "array"
      +        },
      +        "settings": {
      +          "description": "Settings applied: zodiac, house system and the aspect set with its orbs.",
      +          "type": "object"
      +        },
      +        "sidereal_time": {
      +          "description": "Local sidereal time as ARMC (degrees) and the true obliquity of the ecliptic.",
      +          "type": "object"
      +        },
      +        "subject": {
      +          "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
      +          "type": "object"
      +        },
      +        "summary": {
      +          "description": "Key facts: Sun, Moon and rising signs, element and modality balance, retrograde planets, chart ruler, day or night chart (sect) and the Part of Fortune.",
      +          "type": "object"
      +        },
      +        "warnings": {
      +          "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
      +          "type": "array"
      +        }
      +      },
      +      "required": [
      +        "subject",
      +        "settings",
      +        "angles",
      +        "houses",
      +        "sidereal_time",
      +        "points",
      +        "aspects",
      +        "summary"
      +      ],
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "endpoint",
      +    "result",
      +    "meta"
      +  ],
      +  "type": "object"
      +}
  2. Changed4 schema fields changed
    • addedInput schema / properties / options / description
      Added value: +"Optional calculation settings; every default is the common Western convention."
    • addedInput schema / properties / options / properties / house_system / description
      Added value: +"House system for cusps and planet houses, e.g. 'placidus' (default) or 'whole_sign'."
    • addedInput schema / properties / options / properties / luminary_orb_bonus / description
      Added value: +"Extra orb in degrees for aspects involving the Sun or the Moon. Example: 2."
    • addedInput schema / properties / options / properties / zodiac / description
      Added value: +"'tropical' (Western, default) or 'sidereal' (pair it with 'ayanamsa')."
  3. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely useful behavior beyond them: determinism via JPL DE440 with no LLM, a meta.result_sha256 for verification, and a $0.06/call price with x402/MPP payment and a free tier. These are things an agent needs but cannot get from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with a clear purpose sentence, but the second sentence is a very long enumerated feature list and the closing sentence packs in pricing, endpoint, and payment protocols. Some of the feature enumeration is marketing padding rather than selection-relevant information.

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?

With an output schema present, the description needn't explain return values, and it adds operational context (determinism, hash, pricing). The only gap is routing guidance versus sibling chart tools, which slightly limits completeness for an agent choosing among many astrology endpoints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 9 parameters including enums and defaults. The description restates house systems and aspect/orb behavior but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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?

States a specific verb+resource: computes a Western astrology natal chart, and enumerates the exact outputs (planets in signs/houses, sun/moon/rising, MC, aspects). This clearly distinguishes it from Vedic siblings like kundli or specialized tools like planet_positions and aspects.

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

Usage Guidelines3/5

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

The description implies usage ('Everything a natal reading needs') but never states when to choose this over siblings such as planet_positions, aspects, or the Vedic kundli family, nor any preconditions. Usage must be inferred from the tool name and output list.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.