Skip to main content
Glama
0xctx

astrolog-mcp

by 0xctx

Daily transits for a birth chart

get_daily_transits
Read-onlyIdempotent

Calculate ranked daily transits and midpoint contacts for a birth chart on one local day, including exact times, sign and house changes, retrograde shifts, and Moon events.

Instructions

Call this when someone asks what one whole local day holds for a birth chart, such as today's transits for a person: the transits and midpoint contacts ranked highest by score on one local day, when each goes exact, which transiting objects change sign or natal house, which change retrograde direction, and what the Moon does that day. Why: the natal chart comes from the configured engine, and the sky is read at local midnight, at the middle of the day and at the next midnight, as three engine reads in parallel with the same zodiac. Aspects, midpoints, exact times and the ranking are arithmetic on those positions, so the same input always gives the same numbers. With ENGINE=stub they are placeholders. Returns: a headline, the day's bounds and length, and the aspect hits across the pairings T to N, T to Nm, Tm to N and Tm to Nm, ranked by score, each with its orb, score, applying or separating, and its exact time, to the minute, or null; the sign and natal house changes with their times; the retrograde changes with their times; and the Moon's sign changes and its aspects that day, including a transiting midpoint that holds the Moon. Each list is up to limit (default 10, at most 50) with its total and a truncated flag. It also gives the codes the engine did not compute, the house system, the natal moment, the place and the provenance. Inputs: birth_date, birth_time and place, or latitude, longitude and timezone; date, the local day; day_timezone, the day's IANA zone, which defaults to the natal timezone; house_system; ayanamsa (tropical by default, or lahiri, fagan_bradley, raman or krishnamurti for sidereal longitudes), applied to the natal chart and every sky sample; aspects, "major" (default) or "all"; harmonic, from 1 up to 432 divided by the day's hours, rounded down; limit; and min_strength, which keeps only hits whose score, to two places, is at least that. The score is orb tightness times weight, divided by 1.5 (weight 1 plus 0.25 for an outer transiting body plus 0.25 for a key natal point). Tightness is 1 at exact and 0 at the edge of the orb. Gives positions and facts only, with no interpretation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesLocal calendar day to read, as YYYY-MM-DD, for example 2026-10-14. The day runs from its local midnight to the next one.
limitNoHow many items to list in each of hits, ingresses, stations, Moon sign changes and Moon aspects, from 1 to 50. Leave out for 10. Each list states its total and whether it was cut.
placeNoBirth place to look up, as a name like 'Austin, TX', or one of these shorthands, which stand alone with no region or country: 'NYC', 'New York', 'LA', 'L.A.', 'SF', 'San Fran', 'DC', 'Philly', 'Vegas', 'Peking' or 'Saigon'. Give this or latitude, longitude and timezone, not both. Anything else must be a place name in the GeoNames table, or latitude, longitude and time zone given directly.
aspectsNoWhich aspects to rank. "major" (default) ranks the five major aspects: conjunction, sextile, square, trine and opposition, with the midpoint pairings built on them. "all" ranks the 17 vibrational aspects, such as semisquare, quintile, septile and novile, as well. A pair of points takes the lesser of 16 degrees divided by the aspect's harmonic and 2 degrees (1 degree above harmonic 4). A pair with a midpoint takes the midpoint orb: 1.5 degrees at harmonics 1 and 2, and 3 divided by the harmonic above. The aspect names results use, with other names people use and the angle (no input takes an aspect name): "major" has conjunction (conj, 0°), opposition (opp, 180°), trine (tri, 120°), square (sqr, quartile, 90°), sextile (sex, 60°); "all" adds quintile (qtl, 72°), biquintile (bi-quintile, 144°), septile (sep, 51°26′), biseptile (bi-septile, 102°51′), triseptile (tri-septile, 154°17′), semisquare (semi-square, octile, 45°), sesquiquadrate (sesquisquare, sesqui-square, trioctile, 135°), novile (nonile, 40°), binovile (bi-novile, 80°), quadnovile (quadri-novile, 160°), semisextile (semi-sextile, 30°), quincunx (inconjunct, 150°).major
ayanamsaNoZodiac for the positions: tropical, lahiri, fagan_bradley, raman, krishnamurti. Leave out for tropical. A sidereal value such as lahiri gives sidereal longitudes, with the ayanamsa subtracted from the tropical ones. Pass the value even when a person uses another name for it: tropical is also called Western or sayana; lahiri is also called Lahiri, Chitra Paksha or Indian national ayanamsa; fagan_bradley is also called Fagan-Bradley, Fagan/Bradley or Western sidereal; raman is also called Raman or B. V. Raman; krishnamurti is also called Krishnamurti, KP or K.P..tropical
harmonicNoHarmonic to read the chart and the sky in, a whole number from 1 up to the day's maximum: 432 divided by the day's hours, rounded down, so 18 on a 24-hour day and 17 on a 25-hour day. 1 is the ordinary daily reading; above 1, the natal chart and every sky sample are multiplied by it (longitude times harmonic, mod 360).
latitudeNoBirth latitude in signed decimal degrees, north positive, for example 30.2672. Give with longitude and timezone instead of place.
timezoneNoIANA time zone name for the birth time, such as America/Chicago, America/New_York, America/Los_Angeles, or Europe/London. Give with latitude and longitude instead of place.
longitudeNoBirth longitude in signed decimal degrees, east positive, for example -97.7431. Give with latitude and timezone instead of place.
birth_dateYesBirth date in the local calendar of the birth place, as YYYY-MM-DD, for example 1990-06-15.
birth_timeYesBirth clock time in the local time of the birth place, 24-hour HH:MM, for example 19:30.
day_timezoneNoIANA time zone of the day, such as America/New_York. Leave out for the natal timezone: the birth place's zone, from place or from timezone.
house_systemNoHouse system that sets the house cusps: one of placidus, koch, equal, campanus, regiomontanus, porphyry, whole_sign. Leave out for placidus. Pass the value even when a person uses another name for it: placidus is also called Placidus or Plac; koch is also called Koch, birthplace houses or GOH; equal is also called Equal house or equal from the Ascendant; campanus is also called Campanus or Camp; regiomontanus is also called Regiomontanus or Regio; porphyry is also called Porphyry or Porph; whole_sign is also called Whole Sign, whole-sign houses, sign houses or WSH.placidus
min_strengthNoKeep an aspect hit only when its score, not its tightness, is at least this, from 0 to 1, compared at the two places the score shows. The score is as the tool description says; the transit tool's min_strength compares its tightness instead. Leave out for 0, which keeps every hit.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayYes
hitsYes
metaYesSettings and provenance behind the numbers.
moonYes
missingYesObject codes an engine call did not compute, so the day leaves them out. Empty when all were computed.
headlineYesThe date, the zone, the counts and the Moon's sign changes, as plain text. A harmonic above 1 starts with Harmonic N:.
stationsYes
ingressesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses real behavioral traits: the natal chart comes from the configured engine, the sky is sampled at local midnight, midday and the next midnight as three parallel reads, results are deterministic ('the same input always gives the same numbers'), and ENGINE=stub yields placeholders. That is material operational context an agent cannot get from the 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 correctly (trigger first, then why, returns, inputs), but it is a single enormous run-on paragraph, and the long Returns enumeration largely duplicates what the existing output schema already specifies. The algorithmic 'Why' section earns its place; the restated input list does not.

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 14-parameter tool with a complex ranked output, the description covers the trigger, the computation model, determinism and engine caveats, scoring semantics, and the zodiac/house/ayanamsa scoping. Even though an output schema exists, nothing an agent needs to call this correctly is 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 100%, so the baseline is 3, but the description adds the ranking model that the schema does not state: score = orb tightness times weight divided by 1.5, weight bonuses for outer transiting bodies and key natal points, and tightness 1 at exact / 0 at orb edge. It also restates the harmonic cap and ayanamsa scope. This is genuine added meaning on top of a fully documented schema.

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 precise trigger and scope: a full local day of transits and midpoint contacts for a birth chart, ranked by score, with exact times, sign/house changes, retrograde stations and Moon behavior. That scope ('one whole local day') implicitly separates it from the sibling get_transit_data, which is not day-scoped. An agent knows exactly what this tool produces without opening the schema.

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?

'Call this when someone asks what one whole local day holds for a birth chart, such as today's transits for a person' is an explicit, testable trigger condition. However, the description never names an alternative tool or states a when-not condition (the contrast with the transit tool's min_strength appears only in the schema, not the description), so routing guidance is clear but incomplete.

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