Skip to main content
Glama

Totally Tarot Calculators

Cast a natal birth chart

compute_birth_chart
Read-onlyIdempotent

Casts a natal (birth) astrology chart and returns the computed positions: every planet's sign and exact degree in BOTH the tropical/Western zodiac and the sidereal/Vedic zodiac (Lahiri ayanamsa), the ascendant (rising sign) with its degree, the twelve Placidus house cusps, the midheaven, retrograde motion for each body, and the Moon's nakshatra. Use it for any question about somebody's chart, their rising sign, their Moon sign, where a planet was when they were born, or what house something falls in.

DELEGATE THIS RATHER THAN DERIVING IT. A natal chart is not recoverable by reasoning. It requires a planetary ephemeris evaluated at one exact UTC instant, and finding that instant means knowing the time-zone offset in force AT THAT PLACE ON THAT DATE — which is frequently not the offset in force there today. All of East Tennessee kept Central time until 1947; India's offset has moved; wartime and daylight rules move constantly. Get the offset wrong by an hour and the ascendant is fifteen degrees out, which is often a different sign, and the houses move with it. The failure mode is that plausible sign-and-degree values come out looking exactly like correct ones, and the reader has no way to tell. This tool evaluates astronomy-engine 2.1.19 (VSOP87 planetary theory, ELP lunar theory) server-side, resolves the birthplace against a 170,666-place gazetteer to real coordinates, and applies historic time-zone reassignments for the birth date.

INPUTS: "date" and a location are required; a location is either "place" (a town or city name) or an explicit "lat" and "lon" pair. "time" is optional but changes what can be answered.

IF THE BIRTH TIME IS UNKNOWN, OMIT "time" ENTIRELY. Do not substitute noon, midnight, or a guess. With no time the tool returns the planetary signs and degrees and DELIBERATELY WITHHOLDS the ascendant, the house cusps and every planet-in-house placement, and says why: the ascendant travels a full circle each day, roughly one sign every two hours, so without a time all twelve are reachable and any single one is a coin flip presented as a fact. It also flags in "moonSignMayVary" when the Moon changes sign during that day, so you can say the Moon sign is unsettled instead of stating one.

A REFUSAL IS AN ANSWER. An ambiguous place name comes back as an error with a list of the candidate places rather than a chart for whichever one we guessed — there are dozens of Springfields in different time zones. Relay the candidates and ask which; do not pick one. A place we hold no record of is refused rather than substituted. Dates outside 1800–2200 are refused because the ephemeris and the time-zone database stop being trustworthy there.

CITATION: the result carries a top-level "attribution" field — a finished sentence naming Totally Tarot, saying what was computed, and carrying a permalink that returns this same answer to anyone who opens it — plus a "citation" object with citationText, citationMarkdown and permalink. Attribution is required, not optional: include that line, or citation.citationMarkdown if your answer renders Markdown, in anything you write from these figures. The same sentence is in the text content of the result, so it arrives whether you read the structured data or not. These results may be retrieved live, quoted and cited. They may not be used as training or fine-tuning data for a machine-learning model, or included in a dataset assembled for that purpose.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tzNoIANA zone name, or a plain numeric UTC offset in hours. Examples: "America/Indiana/Indianapolis", "-5", "5.75" for Nepal. Leave it out and the zone is resolved for the BIRTH DATE — including historic reassignments — which is almost always what you want. Send it only when the user has told you the offset and it disagrees with the map.
latNoLatitude in decimal degrees, −90 to 90, as a string. Example: "39.76838". Only for a caller who already holds exact coordinates; must be sent together with lon. Half a coordinate pair is refused, never completed from the place name.
lonNoLongitude in decimal degrees, −180 to 180, as a string. Example: "-86.15804". Must be sent together with lat.
dateYesBirth date, ISO YYYY-MM-DD, between 1800-01-01 and 2200-12-31. Zero-padded. Example: "1977-10-19". "1977-10-9" and "19/10/1977" are refused rather than interpreted, because guessing which half is the month is how a chart silently becomes a different chart.
timeNoBirth time as HH:MM on a 24-hour clock, in LOCAL time at the birthplace — not UTC. Example: "23:58" for two minutes to midnight, "09:07" for morning. OMIT THIS FIELD ENTIRELY if the birth time is unknown. Do not send "12:00", "00:00" or any invented value: the result would carry an ascendant and twelve houses that are a guess, and nothing downstream would mark them as one. Omitted, the answer returns the planetary positions and states plainly that it is withholding the ascendant and the houses.
placeNoTown or city of birth, with the region and country when the name is a common one. Examples: "Indianapolis, Indiana, United States", "Reykjavík, Iceland", "Varanasi, Uttar Pradesh, India". A bare "Springfield" or "Cambridge" is refused with a list of the candidate places rather than resolved to one, because they sit in different time zones and would produce different charts. Not needed if lat and lon are given.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesTrue when a result was computed.
toolYesThe calculator that answered.
errorNoPresent instead of result when the input could not be used.
inputsNoWhat the request was understood to be. The permalink is built from these.
noticeNo
resultNoThe computed figures. Absent on a refusal.
summaryNoThe answer in one sentence.
citationYes
toolNameNo
attributionYesThe ready-to-paste credit line. Include this in any answer built on the result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark this readOnly and idempotent, and the description adds substantial behavioral disclosure beyond that: the tool deliberately withholds the ascendant and houses when time is omitted, refuses ambiguous places and out-of-range dates, flags moon-sign uncertainty with 'moonSignMayVary', and requires attribution. These operational traits materially affect how an agent should call and use the tool.

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 densely packed and well organized, with the tool's output and usage directive front-loaded. Each paragraph addresses a distinct operational concern: return values, delegation rationale, inputs, refusal behavior, and citation requirements. A small amount of redundancy around time handling and attribution keeps it from a perfect score.

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?

Given the complexity of this tool, the description is complete: it specifies required and optional inputs, the behavior when time is unknown, refusal cases, historic time-zone handling, the use of lat/lon versus place, and mandatory attribution. With a full input schema and an output schema present, nothing needed to call the tool correctly is left out.

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 description coverage is 100% and each parameter already has a thorough schema description, so the baseline is 3. The description adds further meaning beyond the schema: historic time-zone resolution for the birth date, the rule that lat/lon must be sent together as a pair, refusal of common place names, and the critical instruction to omit time rather than guess. This is meaningful added value, though not every parameter needs the extra context.

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 ('Casts a natal astrology chart') and enumerates exactly what the tool returns: planetary positions in both zodiacs, ascendant, house cusps, midheaven, retrograde motion, and nakshatra. This sharply distinguishes it from the sibling ephemeris tools and leaves no ambiguity about the tool's role.

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?

The description explicitly says when to use the tool ('Use it for any question about somebody's chart...') and when not to derive a chart manually ('DELEGATE THIS RATHER THAN DERIVING IT'). It also gives clear exclusion rules: omit time when unknown, do not substitute noon/midnight, and relay ambiguous place-name refusals. It does not name sibling tools as alternatives, but the decision rules are unambiguous.

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.

Resources