Skip to main content
Glama
0xctx

astrolog-mcp

by 0xctx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Harmonic midpoint structures

get_harmonic_midpoints
Read-onlyIdempotent

Calculate midpoint structures in a birth chart for a chosen harmonic, such as harmonic 5 or 7, from birth date, time, and place, ranked by orb.

Instructions

Call this when someone asks which midpoint structures a birth chart has in one harmonic, such as harmonic 5 or 7, for a birth date, time and place. Why: the chart is cast once by the configured engine, each longitude is multiplied by the harmonic, and the classic midpoint method tests every pair of points, so the same input always gives the same structures. With ENGINE=stub they are placeholders, and the text starts with a PLACEHOLDER line. Returns: a headline with the structure count and the tightest structure; the harmonic positions of the bodies, Ascendant and Midheaven; up to limit structures (default 12, at most 50) ranked by orb, each with its focus point, the two points whose midpoint it is, the aspect, orb, strength and the midpoint's sign and degree; the total count; and the harmonic, house system, UT moment, place and provenance. Input ayanamsa sets the zodiac the longitudes are multiplied in: 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. Pass either place, or latitude, longitude and timezone. One harmonic per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many midpoint structures to return, tightest orb first, from 1 to 50. Leave out for 12.
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.
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
harmonicYesHarmonic H, a whole number from 1 to 10000, for example 5. Every longitude is multiplied by H before the midpoints are read; 1 is the natal chart.
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.
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
metaYesSettings and provenance behind the numbers.
missingYesObject codes the engine did not compute, so no structure uses them. Empty when all were computed.
headlineYesThe harmonic, the number of midpoint structures and the tightest one, as plain text.
structuresYesClassic midpoint structures in this harmonic, ranked by orb.
harmonic_positionsYesPositions in the harmonic chart: each longitude is the natal longitude times the harmonic.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior5/5

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

With annotations already covering read-only/idempotent/closed-world, the description still adds substantial behavior: determinism ('the same input always gives the same structures'), the ENGINE=stub placeholder mode with a PLACEHOLDER line, provenance/meta reporting, and the ayanamsa-subtraction behavior for sidereal. This is a good example of adding value beyond structured fields.

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 the trigger, which is good, but the long 'Returns:' enumeration duplicates the output schema verbatim and bloats a single dense paragraph. Useful content, but the return-value inventory does not earn its space given a separate output schema.

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 10-parameter engine-backed tool, the description covers the trigger, determinism, stub caveat, coordinate-vs-place input choice, harmonic semantics, and ayanamsa behavior, with the output schema carrying the return shape. Nothing an agent needs in order to call it correctly 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 includes inline enum explanations, so the schema already carries the parameter semantics. The description restates the ayanamsa zodiac effect and harmonic multiplication but adds no syntax or format detail the schema lacks. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource+scope: 'which midpoint structures a birth chart has in one harmonic, such as harmonic 5 or 7', and adds 'One harmonic per call'. An agent can tell this apart from a generic chart or transit call. It never names or contrasts the siblings (get_chart_data, get_transit_data), so it stops short of a 5.

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 gives an explicit trigger ('Call this when someone asks which midpoint structures...') and a scoping rule ('One harmonic per call'), plus the place-vs-coordinates input condition. No exclusions or named alternatives are given, so it is clear context without routing guidance.

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

Deploy Server

Other Tools