Skip to main content
Glama
0xctx

astrolog-mcp

by 0xctx

Composite of two charts

get_composite_data
Read-onlyIdempotent

Compute a composite or Davison midpoint chart from two birth charts, returning planetary positions, houses, angles, and major or all aspects.

Instructions

Call this when someone asks how two people's charts combine, as one merged composite chart or as a Davison midpoint chart. Why: both charts come from the configured engine with fixed settings, so the same two people always give the same numbers. With ENGINE=stub they are placeholders, and the text starts with a PLACEHOLDER line. Returns: the composite's bodies with sign, degree, minute, retrograde flag and house; the twelve house cusps; the four angles (ASC, MC, DSC, IC); the aspects, which are by default the 8 tightest of the five major aspects between its bodies, with the total count and a truncated flag; and the kind, the two birth moments in UT, the Davison midpoint moment when the kind is davison, the house system and the engine's version. Aspects: "aspects" chooses the set. "major" (default) reads the five major aspects between the bodies, and nothing else; its output is unchanged. "all" reads the 17 vibrational aspects, such as semisquare, quincunx, quintile, septile and novile, between the bodies and the angles ASC and MC, with each orb 16 degrees divided by the aspect's harmonic, and the five major ones at the wider of that and their major orb (trine 6, square 6, sextile 4), so the "all" set holds every major aspect (with aspect_limit 0, every one is listed). Only "all" reads the angles as targets and adds a strength to each item and set to the list. "aspect_limit" is how many to list, 8 by default; 0 lists every aspect. A composite has no moment of its own: it uses the two birth moments and places. Input ayanamsa sets the zodiac of the composite: tropical by default, or lahiri, fagan_bradley, raman or krishnamurti for sidereal longitudes; a sidereal result names the ayanamsa in meta. Gives positions and facts only, with no interpretation. Give each person as place, or as latitude, longitude and timezone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes"composite" merges the two charts into one chart. "davison" casts one chart for the midpoint of the two moments, in UT.
aspectsNoWhich aspects to list. "major" (default) lists the five major aspects between the bodies. "all" lists the 17 vibrational aspects, such as semisquare, quincunx, quintile, septile and novile, between the bodies and the angles ASC and MC. Each orb is 16 degrees divided by the harmonic, and the five major aspects take the wider of that and their major orb (trine 6, square 6, sextile 4), so the "all" set holds every "major" aspect. For example, quintile has an orb of 3.2 and semisquare 2. 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
person_aYesThe first person: birth date, time and place, as a natal chart takes them.
person_bYesThe second person: birth date, time and place, as a natal chart takes them.
aspect_limitNoHow many aspects to list, tightest orb first for major, and by strength for all. Leave out for 8. 0 lists every aspect. The result always gives the total and whether the list was cut.
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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaYesThe kind, the input moments, the house systems and the provenance behind the numbers.
anglesYesThe four angles of the composite: ASC, MC, DSC and IC.
bodiesYesThe composite's bodies in object-code order.
housesYesThe twelve house cusps of the composite, house 1 to 12.
aspectsYesAspects between the composite's bodies. Only when aspects is all, also aspects between them and the angles ASC and MC, each item with a strength, and set says all. The total and whether the list was cut are always given.
missingYesObject codes the engine did not compute. Empty when all were computed.
headlineYesThe Sun, Moon and Ascendant positions of the composite as plain text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/closed-world, so the bar is low, yet the description adds real behavioral context: the engine uses fixed settings so identical inputs always yield identical numbers, and with ENGINE=stub results are placeholders marked with a leading PLACEHOLDER line. It also flags that a composite has no moment of its own and that output is positions and facts with no interpretation.

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?

The trigger and the "why" about engine determinism are correctly front-loaded, but the single dense block then re-derives large parts of the schema (full aspect-name lists, orb arithmetic, ayanamsa aliases) at length. Several sentences do not earn their place because they duplicate structured fields.

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?

For a 7-parameter tool with nested person objects and four enums, the description supplies enough to invoke it correctly and warns about the stub/placeholder case. An output schema exists, so its return-value prose is redundant rather than necessary, but nothing critical is missing.

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% and the schema descriptions are themselves extremely detailed, so the baseline is 3. Much of the description's parameter prose (ayanamsa values and aliases, aspect_limit default, the harmonic orb rule, the "all" set containing all "major" aspects) repeats what the schema already states verbatim, adding little beyond structure.

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 names a specific verb+resource (combine two people's charts) and enumerates the two supported modes, a merged composite and a Davison midpoint chart, which is exactly the discriminating fact versus the single-chart siblings. An agent can tell this apart from get_chart_data or get_harmonic_midpoints without opening a 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?

It opens with an explicit trigger: "Call this when someone asks how two people's charts combine." That is a clear usage condition. It never states when NOT to use it or names a sibling as the alternative (e.g. for a single natal chart), so it stops short of a 5.

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