Auseklis is a full-featured astrology MCP server that computes real planetary positions, charts, and astrological events from a local ephemeris — no API keys required.
Get Planet Position: Look up the zodiac position (sign, degree, speed, retrograde state) of any planet, lunar node, or Black Moon Lilith at any moment in time.
Compute Natal Charts: Generate a complete birth chart with 13 celestial points, house cusps, Ascendant, Midheaven, Part of Fortune, and all major aspects.
Calculate Transits: Find how current or historical sky positions aspect a natal chart.
Compute Secondary Progressions: Calculate a progressed chart using the day-for-a-year method, showing symbolic chart evolution over time.
Analyze Synastry: Compute cross-chart aspects between two people's natal charts to assess relationship compatibility.
Compute Composite Charts: Build a midpoint composite chart representing a relationship, requiring both birth locations.
Find Returns: Locate exact moments when a planet returns to its natal longitude (solar, lunar, Saturn returns, etc.).
Get Moon Phase: Retrieve the current phase name, angle, illumination percentage, Moon sign, and the next four quarter events.
Find Eclipses: Search for lunar and solar eclipses within a date range (up to 30 years), with local visibility data for solar eclipses.
Find Retrograde Periods: Identify exact station-retrograde and station-direct moments for any planet within a date range.
Find Sign Ingresses: Determine when a planet crosses into a new zodiac sign, including retrograde crossings.
Find Aspect Times: Pinpoint the exact moment a transiting planet perfects an aspect to a natal position, including all retrograde passes.
Additional features:
Supports tropical and sidereal zodiacs (Lahiri, Fagan/Bradley) and multiple house systems (whole-sign, equal, Porphyry, Placidus)
Handles local birth times with full IANA timezone and historical DST support
Includes built-in AI prompts for natal chart readings and current sky reports, plus a glossary resource
Accuracy of ±1 arcminute for dates 1700–2200; event searches refined to ~1 second
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@auseklis What's transiting my Sun this month?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Astrology MCP server — natal charts, transits, synastry, progressions, returns, eclipses, retrogrades, moon phases. Computed from a real ephemeris, so AI agents stop hallucinating planet positions.
Named after the Latvian morning star. MIT-licensed with no AGPL ephemeris data — see Licensing.
Tool | What it does |
| Position of one body/point at a moment (sign, degree, speed, retrograde) |
| Full birth chart: 13 points, houses, angles, Part of Fortune, aspects |
| Aspects from the current (or any) sky to a natal chart |
| Secondary progressions (day-for-a-year) |
| Cross-chart aspects between two people |
| Midpoint composite chart of a relationship |
| Solar/lunar/planetary returns (exact moments) |
| Phase, illumination, Moon sign, next four quarters |
| Lunar/solar eclipses with signs, incl. local visibility |
| Station retrograde/direct moments for any planet |
| When a body changes signs (equinoxes, Saturn ingresses, …) |
| Exact moment a transit perfects ("when does Saturn square my Sun?") |
Plus two prompts (natal_chart_reading, current_sky_report) and a glossary resource (auseklis://glossary).
Features: local birth times with IANA timezones (full historical DST handling) · tropical and sidereal (Lahiri, Fagan/Bradley) zodiacs · whole-sign, equal, Porphyry, and Placidus houses · mean lunar nodes and Black Moon Lilith · Part of Fortune (classical day/night formula).
Related MCP server: Astro MCP Server
claude mcp add auseklis -- npx -y auseklis{
"mcpServers": {
"auseklis": {
"command": "npx",
"args": ["-y", "auseklis"]
}
}
}No API keys, no configuration — the ephemeris is computed locally.
Download auseklis.mcpb from the releases page and double-click to install in Claude Desktop. Or build it yourself: npm run bundle.
The same server runs as a Cloudflare Worker speaking Streamable HTTP. Deploy it to your own account:
npm run deploy # wrangler deploy
claude mcp add --transport http auseklis https://auseklis.<your-subdomain>.workers.dev/mcpSet the MCP_SHARED_SECRET secret to require a bearer token.
The ephemeris core (everything under src/ephemeris/) is importable directly — no MCP client or subprocess needed. This is the right shape for serverless runtimes (Vercel, Workers), where spawning npx auseklis per request is not an option:
import { computeNatalChart } from "auseklis/ephemeris";
import { findRetrogradePeriods } from "auseklis/ephemeris/events";
import { findEclipses } from "auseklis/ephemeris/eclipses";
const chart = computeNatalChart({
utc: "1990-03-15T13:45:00Z",
location: { latitude: 56.95, longitude: 24.11 }, // Riga
houseSystem: "placidus",
});auseklis/ephemeris carries the chart math (natal, transits, synastry, composite, progressions, single positions, angles) plus resolveInstant for local-time → UTC conversion; …/events and …/eclipses carry the time-domain searches. Fully typed, ESM only, no data files.
"Compute my natal chart — born 15 March 1990, 15:45 in Riga."
"What's transiting my Sun this month?"
"When exactly is my Saturn return?"
"Synastry between me and my partner?" (two birth date/times)
"When is Mercury retrograde in 2027, and in which signs?"
"Is tonight's full moon visible as an eclipse from here?"
The model handles place-name → coordinates; the server handles local-time → UTC via the IANA timezone database.
Positions come from astronomy-engine (VSOP87 + NOVAS C 3.1): ±1 arcminute for 1700–2200, far below the 1° resolution astrological interpretation uses. Event searches (stations, ingresses, returns, quarters) are refined to ~1 second of time. Verified in CI against published eclipse dates, the 2026 equinox, NOVAS Sun positions, and an independent Placidus implementation.
src/
├── ephemeris/ Astrology core — backend-agnostic
│ ├── engine.ts EphemerisBackend interface + astronomy-engine adapter (the swap seam)
│ ├── index.ts Charts, aspects, synastry, composite, progressions
│ ├── events.ts Time searches: returns, stations, ingresses, aspect times, moon phases
│ ├── eclipses.ts Eclipse searches with astrological context
│ ├── houses.ts Whole-sign, equal, Porphyry, Placidus (semi-arc solver)
│ ├── points.ts Mean lunar nodes, Black Moon Lilith
│ ├── sidereal.ts Ayanamsa (Lahiri, Fagan/Bradley)
│ └── time.ts IANA timezone → UTC conversion (no dependencies, uses Intl)
├── mcp/ Tool/prompt/resource definitions on @modelcontextprotocol/sdk
├── stdio.ts Local entry — `npx auseklis`
└── index.ts Remote entry — Cloudflare Worker, Streamable HTTP via @hono/mcpThe EphemerisBackend interface in engine.ts is the deliberate swap seam: a future Rust/WASM clean-room ephemeris only needs to reimplement that one interface.
npm install
npm run typecheck # strict TS
npm test # 23-check smoke suite (ephemeris references + MCP end-to-end)
npm run build # emit dist/
npm run dev # local Cloudflare Worker on :8787
npx @modelcontextprotocol/inspector node dist/stdio.js # poke tools interactivelySee docs/tools.md for the full tool reference and docs/architecture.md for design notes.
MIT. This project deliberately avoids the Swiss Ephemeris (.se1/.se2 data files and the sweph bindings): those are AGPL-licensed, which would impose AGPL obligations on any network service built on them. Everything here is computed from MIT-licensed code with no external data files — safe to embed, fork, and deploy commercially. Details in NOTICE.
The trade-off: no Chiron or asteroids (they need ephemeris data files). They are on the roadmap via public-domain JPL-derived data.
v1: Rust/WASM clean-room ephemeris backend behind the same EphemerisBackend seam
Chiron + major asteroids from public-domain JPL data
Koch houses, declination/parallel aspects
Compute a midpoint composite chart for two people: a single chart describing the relationship itself, built from the shorter-arc midpoints of the two natal charts' positions and angles.
Both birth locations are required (the composite angles derive from each chart's Ascendant/Midheaven).
Example:
{ datetime_a: "1990-03-15T15:45", timezone_a: "Europe/Riga", latitude_a: 56.95, longitude_a: 24.11, datetime_b: "1992-07-22T08:30", timezone_b: "America/New_York", latitude_b: 40.71, longitude_b: -74.01 }
| Name | Required | Description | Default |
|---|---|---|---|
| zodiac | No | Zodiac frame: tropical (Western default), sidereal-lahiri (Vedic), or sidereal-fagan-bradley (Western sidereal). | tropical |
| datetime_a | Yes | Person A's birth date and time. | |
| datetime_b | Yes | Person B's birth date and time. | |
| latitude_a | Yes | Person A's birth latitude. | |
| latitude_b | Yes | Person B's birth latitude. | |
| timezone_a | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. | |
| timezone_b | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. | |
| longitude_a | Yes | Person A's birth longitude. | |
| longitude_b | Yes | Person B's birth longitude. | |
| house_system | No | House system: whole-sign (default), equal, porphyry, or placidus. | whole-sign |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| houses | Yes | |
| zodiac | Yes | |
| aspects | Yes | |
| positions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds behavioral context (composite angles derive from Ascendant/Midheaven) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear definition and an illustrative example, no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and existence of output schema, the description covers the core functionality, requirements, and provides an example. It is sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value through an example showing exact parameter formats and emphasizing the requirement of both locations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a midpoint composite chart for two people, describing the relationship itself. It uses specific verb ('compute') and resource ('composite chart'), and the context of sibling tools like 'compute_synastry' implies differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (for two people) and notes that both birth locations are required. It provides an example but does not explicitly state when not to use or compare with alternatives like compute_synastry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a complete natal (birth) chart: the ten classical bodies plus lunar nodes, Lilith, and Chiron, house cusps, Ascendant and Midheaven, the Part of Fortune, and all aspects.
Accepts local birth time directly when given the IANA timezone — no manual UTC conversion needed. Supports tropical (Western) and sidereal (Vedic/Lahiri, Fagan-Bradley) zodiacs.
Examples:
"Chart for 15 March 1990, 3:45pm in Riga" -> { datetime: "1990-03-15T15:45", timezone: "Europe/Riga", latitude: 56.95, longitude: 24.11 }
Vedic chart: add { zodiac: "sidereal-lahiri" }
Returns: positions (13 points), houses (12 cusps + angles), the Part of Fortune (classical day/night formula, with the dayChart flag showing which applied), aspects, and the ayanamsa applied (0 for tropical).
| Name | Required | Description | Default |
|---|---|---|---|
| zodiac | No | Zodiac frame: tropical (Western default), sidereal-lahiri (Vedic), or sidereal-fagan-bradley (Western sidereal). | tropical |
| datetime | Yes | Birth date and time. | |
| latitude | Yes | Geographic latitude in degrees, positive north (-90 to 90). | |
| timezone | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. | |
| longitude | Yes | Geographic longitude in degrees, positive east (-180 to 180). | |
| house_system | No | House system: whole-sign (default), equal, porphyry, or placidus. | whole-sign |
| Name | Required | Description |
|---|---|---|
| utc | Yes | |
| houses | Yes | |
| zodiac | Yes | |
| aspects | Yes | |
| ayanamsa | Yes | |
| location | Yes | |
| positions | Yes | |
| partOfFortune | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by detailing output components like the Part of Fortune formula and ayanamsa, but does not introduce new behavioral traits beyond what annotations suggest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, details, and examples. It is front-loaded with the main purpose. While slightly long, every sentence conveys useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a natal chart and the presence of an output schema, the description thoroughly covers all input options, output components, and includes an example. It is fully adequate for an AI agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description includes an example usage but does not add significant new meaning to individual parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a complete natal chart with specific bodies, house cusps, angles, Part of Fortune, and aspects. It distinguishes from siblings like compute_synastry by focusing on a single birth chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples and explains how to input local time with IANA timezone, but does not explicitly state when to use this tool versus alternatives like compute_transits or compute_progressions. The sibling tool names implicitly differentiate the use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a secondary-progressed chart: the natal chart advanced one ephemeris day per year of life (the standard "day-for-a-year" method). Shows how the chart has symbolically evolved by a given date.
Examples:
"My progressed chart for today, born 1990-03-15 15:45 Riga" -> { natal_datetime: "1990-03-15T15:45", natal_timezone: "Europe/Riga" } (target_datetime defaults to now)
Returns progressed positions and the aspects progressed bodies make to natal bodies. The progressed Moon (~1 sign per 2.5 years) and progressed Sun (~1° per year) carry the most interpretive weight.
| Name | Required | Description | Default |
|---|---|---|---|
| zodiac | No | Zodiac frame: tropical (Western default), sidereal-lahiri (Vedic), or sidereal-fagan-bradley (Western sidereal). | tropical |
| natal_datetime | Yes | Birth date and time. | |
| natal_timezone | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. | |
| target_datetime | No | Date to progress to. Defaults to now. | |
| target_timezone | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. |
| Name | Required | Description |
|---|---|---|
| ageYears | Yes | |
| natalUtc | Yes | |
| positions | Yes | |
| targetUtc | Yes | |
| progressedUtc | Yes | |
| aspectsToNatal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, destructive, idempotent, and openWorld hints. The description adds behavioral context by detailing return values (progressed positions and aspects) and interpretive weight of the Moon and Sun, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, front-loads the main purpose, and uses a clear example structure. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and presence of an output schema, the description adequately explains the concept and usage. It could mention timezone handling more explicitly, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value through a concrete usage example, clarifying default target_datetime behavior, and explaining the zodiac parameter, elevating semantics slightly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes secondary progressions and explains the 'day-for-a-year' method. It distinguishes from siblings like compute_natal_chart and compute_transits by specifying it advances the natal chart symbolically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through examples and explanation of default behavior, but no explicit when-to-use or when-not-to-use guidance is provided. Siblings exist for different astrological computations, yet no comparisons are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the cross-chart aspects between two people's natal charts — the classic relationship-compatibility technique. Every aspect from person A's bodies/points to person B's is returned, along with both sets of positions.
Locations are not needed: synastry aspects depend only on planetary positions. (House overlays would need both birth locations — compute the two natal charts separately for that.)
Example:
{ datetime_a: "1990-03-15T15:45", timezone_a: "Europe/Riga", datetime_b: "1992-07-22T08:30", timezone_b: "America/New_York" }
| Name | Required | Description | Default |
|---|---|---|---|
| zodiac | No | Zodiac frame: tropical (Western default), sidereal-lahiri (Vedic), or sidereal-fagan-bradley (Western sidereal). | tropical |
| datetime_a | Yes | Person A's birth date and time. | |
| datetime_b | Yes | Person B's birth date and time. | |
| timezone_a | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. | |
| timezone_b | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. |
| Name | Required | Description |
|---|---|---|
| aspects | Yes | |
| positionsA | Yes | |
| positionsB | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that the tool returns aspects from person A to B and positions, and that locations are not needed. No contradictions, but could disclose more about aspect calculation details like orbs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: opens with a clear purpose, then key details, conditions, and ends with a concrete example. Every sentence is informative and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich schema, annotations, and output schema, the description covers what the tool does, parameters, return values (aspects + positions), exclusions (locations), and provides an example. It is complete for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. Description adds value by explaining datetime and timezone usage, providing an example, and describing the zodiac enum with three options. It goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes cross-chart aspects between two natal charts for relationship compatibility, specifying it returns aspects and positions. It distinguishes itself from sibling tools like compute_natal_chart (single chart) and compute_composite_chart (composite chart) by focusing on synastry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Locations are not needed' and when not to: for house overlays, compute natal charts separately. Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the aspects from a transiting sky to a natal chart — how the planets at one moment relate to the planets at a birth moment.
Examples:
"What's transiting my chart today, born 1990-03-15 15:45 Riga time?" -> { natal_datetime: "1990-03-15T15:45", natal_timezone: "Europe/Riga" } (transit_datetime defaults to now)
For the exact date a specific transit perfects, use find_aspect_times instead.
| Name | Required | Description | Default |
|---|---|---|---|
| natal_datetime | Yes | Birth date and time. | |
| natal_timezone | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. | |
| transit_datetime | No | Moment of the transiting sky. Defaults to now. | |
| transit_timezone | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. |
| Name | Required | Description |
|---|---|---|
| transits | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that transit_datetime defaults to 'now', which is valuable behavioral context beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: a single line defining the tool, a clear example, and a pointer to an alternative. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (4 params, 1 required) and an output schema, the description covers the core use, provides an example, and mentions default behavior. Slightly incomplete regarding output details, but output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description provides an example showing how parameters are used but adds no extra meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes aspects from a transiting sky to a natal chart, with a specific verb and resource. It distinguishes from the sibling tool 'find_aspect_times' by mentioning its use for exact dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case with examples and explicitly names an alternative tool for when a specific perfecting date is needed. However, no explicit 'when not to use' or comparison to all siblings like compute_synastry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the exact moments a transiting body perfects an aspect to a natal position — "when exactly does Saturn square my Sun?" Retrograde loops produce multiple hits (typically three) and each is returned.
The natal position can be given two ways:
natal_datetime (+ natal_timezone) and natal_body — computed for you
natal_longitude directly, if already known
Examples:
"When does transiting Saturn square my natal Sun (born 1990-03-15 15:45 Riga)?" -> { transiting_body: "Saturn", aspect: "square", natal_datetime: "1990-03-15T15:45", natal_timezone: "Europe/Riga", natal_body: "Sun", from_datetime: "2026-01-01", to_datetime: "2030-01-01" }
| Name | Required | Description | Default |
|---|---|---|---|
| aspect | Yes | Which classical aspect to search for. | |
| natal_body | No | Which natal body/point is aspected. | |
| to_datetime | Yes | End of the search window (max 120 years after start). | |
| from_datetime | Yes | Start of the search window. | |
| natal_datetime | No | Birth date/time (with natal_body). | |
| natal_timezone | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. | |
| natal_longitude | No | Natal longitude in degrees, as an alternative to natal_datetime + natal_body. | |
| transiting_body | Yes | The moving body. |
| Name | Required | Description |
|---|---|---|
| hits | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds key behavioral context: retrograde loops produce multiple hits (typically three) and explains the two ways to specify the natal position, going beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded. It states the purpose, explains modes, and provides an example without extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters, 4 required, and presence of an output schema, the description covers core behavior, input alternatives, and retrograde loop behavior adequately. The output schema handles return values, so no further detail needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds meaning by explaining the two usage modes (natal_datetime + natal_body vs. natal_longitude) and providing an example, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically states 'Find the exact moments a transiting body perfects an aspect to a natal position', using a specific verb and resource. It clearly differentiates from sibling tools like compute_transits and compute_synastry by focusing on aspect timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with examples and explains two input methods. It implicitly guides when to use the tool, but does not explicitly mention when not to use it or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find lunar and solar eclipses in a date range (max 30 years), with the sign and longitude of the eclipsed luminary — the astrologically relevant datum.
When latitude/longitude are provided, each solar eclipse also reports whether it is visible from that location and how much of the Sun is obscured there.
Examples:
"Eclipses in 2026" -> { from_datetime: "2026-01-01", to_datetime: "2027-01-01" }
"Will I see the August 2026 eclipse from Riga?" -> add latitude: 56.95, longitude: 24.11
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Restrict to lunar or solar eclipses. Default: both. | |
| latitude | No | Observer latitude for local solar-eclipse visibility. | |
| longitude | No | Observer longitude for local solar-eclipse visibility. | |
| to_datetime | Yes | End of the search window (max 30 years after start). | |
| from_datetime | Yes | Start of the search window. |
| Name | Required | Description |
|---|---|---|
| eclipses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds important operational details: maximum 30-year range, and solar eclipse visibility when latitude/longitude are provided. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences) and well-structured: opening with purpose, then constraints, optional parameter behavior, and examples. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (eclipses, visibility, astrological relevance) and the presence of a complete schema and annotations, the description covers all necessary aspects: main function, constraints, optional features, and usage examples. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by explaining the purpose of latitude/longitude for visibility and providing concrete examples that clarify parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds lunar and solar eclipses within a date range and mentions the astrological relevance (sign and longitude of eclipsed luminary). This distinguishes it from sibling tools which compute charts, transits, or aspects, not eclipses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (finding eclipses in a date range) and gives examples that illustrate typical queries. However, it does not explicitly state when not to use it or mention alternatives among siblings, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a planet's retrograde periods in a date range: exact station-retrograde and station-direct moments, with the longitude and sign at each end. Periods overlapping the range edges are included whole.
Examples:
"When is Mercury retrograde in 2026?" -> { body: "Mercury", from_datetime: "2026-01-01", to_datetime: "2027-01-01" }
The Sun and Moon never retrograde and are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Which planet (not Sun/Moon). | |
| to_datetime | Yes | End of the search window (max 50 years after start). | |
| from_datetime | Yes | Start of the search window. |
| Name | Required | Description |
|---|---|---|
| periods | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly and idempotent. The description adds behavioral context: inclusive range edges, exact moments, and rejection of Sun/Moon, providing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: 4 sentences and an example, front-loaded with purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and clear annotations, the description covers behavior at range edges, rejection cases, and return content, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds an example showing exact parameter format and clarifies the 'body' rejection of Sun/Moon, which is already in schema, but the example enhances usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds a planet's retrograde periods with specific details (station-retrograde and station-direct moments, longitude, sign). It distinguishes from siblings like find_eclipses or compute_transits by focusing solely on retrograde periods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (e.g., for retrograde periods) and includes an example and note about Sun/Moon rejection. However, it does not explicitly state when not to use or mention alternative tools, though siblings are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the exact moments a body returns to its natal longitude — solar returns (the astrological "birthday", one per year), lunar returns (one per ~27.3 days), or any planetary return (e.g. Saturn return, one per ~29.5 years).
Examples:
"My solar return in 2026, born 1990-03-15 15:45 Riga" -> { body: "Sun", natal_datetime: "1990-03-15T15:45", natal_timezone: "Europe/Riga", from_datetime: "2026-01-01", to_datetime: "2027-01-01" }
"When is my Saturn return?" -> body: "Saturn" with a multi-year window around ages 27–31.
To cast the full chart for a return moment, pass the returned datetime to compute_natal_chart with the person's current location.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Which body's return to find, e.g. "Sun", "Saturn". | |
| to_datetime | Yes | End of the search window (max 120 years after start). | |
| from_datetime | Yes | Start of the search window. | |
| natal_datetime | Yes | Birth date and time. | |
| natal_timezone | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. |
| Name | Required | Description |
|---|---|---|
| returns | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, ensuring safety. The description adds behavioral context: it computes exact moments of return and notes the 120-year window in the schema. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, includes concise examples, and avoids waste. Slight redundancy in examples, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (astrological returns, 5 parameters, annotations, output schema), the description covers purpose, example usage, and chaining with other tools. It does not explain output schema, but that is provided separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by explaining the body enum with examples, providing guidance on natal_timezone usage, and showing datetime formatting. This surpasses baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find the exact moments a body returns to its natal longitude'. It specifies types (solar, lunar, planetary) and distinguishes from sibling tools by focusing on returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context through examples and mentions using compute_natal_chart for full charts. It lacks explicit when-not or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find when a body crosses sign boundaries in a date range. Retrograde crossings (backing into the previous sign) are flagged. The Sun's Aries ingress is the March equinox; Sun ingresses mark the astrological "seasons".
Examples:
"When does Saturn change signs in the next 3 years?" -> { body: "Saturn", from_datetime: "2026-01-01", to_datetime: "2029-01-01" }
"When does the Sun enter Aries in 2027?" -> body: "Sun", window covering March 2027
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Which body's ingresses to find. | |
| to_datetime | Yes | End of the search window (max 120 years after start). | |
| from_datetime | Yes | Start of the search window. |
| Name | Required | Description |
|---|---|---|
| ingresses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds behavioral details: retrograde crossings are flagged, Sun's Aries ingress is the March equinox, and ingresses mark astrological seasons. This context enriches understanding beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs and two examples. It front-loads the core purpose and uses examples effectively. Minor improvement could be more structured formatting, but it's efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but stated) and moderate complexity, the description covers the essential: what it does, retrograde handling, and usage examples. It is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, but the description adds practical meaning with examples (e.g., body: 'Saturn', from_datetime: '2026-01-01'). The examples clarify how to format dates and choose bodies, which the schema alone does not fully convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool finds when a body crosses sign boundaries (ingresses) in a date range, with specific verb 'find' and resource 'sign ingresses'. It distinguishes from sibling tools like find_retrograde_periods and get_planet_position by focusing on sign changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context through examples (e.g., 'When does Saturn change signs in the next 3 years?') and implicit alternatives (e.g., retrograde crossings are flagged, distinguishing from find_retrograde_periods). However, no explicit when-not or direct comparison to siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moon phase at a moment: phase angle, common name (e.g. "Waxing Gibbous"), illuminated fraction, the Moon's sign, and the next four quarter events (new moon, first quarter, full moon, last quarter) with exact times.
Example:
"What's the moon phase tonight, and when is the next full moon?" -> {} (datetime defaults to now)
| Name | Required | Description | Default |
|---|---|---|---|
| datetime | No | Moment to compute for. Defaults to now. | |
| timezone | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. |
| Name | Required | Description |
|---|---|---|
| moonSign | Yes | |
| phaseName | Yes | |
| phaseAngle | Yes | |
| illumination | Yes | |
| nextQuarters | Yes | |
| moonLongitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by specifying the exact output fields, that datetime defaults to now, and the nature of computation. No contradictions, and provides clear context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an example. No redundant information. Front-loaded with key output details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, annotations, and presence of output schema, the description is complete. It covers return values, parameter behavior, and provides an example usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds clarity by explaining that 'datetime' defaults to now and that 'timezone' should be omitted if datetime carries UTC offset. This practical guidance goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get' and resource 'moon phase', lists specific return fields (phase angle, common name, illuminated fraction, moon sign, next four quarter events), and provides an example. Distinguishes from sibling tools which are other astrological computations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for moon phase queries via example, but does not explicitly state when to use versus alternatives among siblings (e.g., get_planet_position, find_eclipses). No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the zodiac position of a single body or point at a single moment.
Returns the geocentric ecliptic longitude, sign and degree within sign, daily motion, and retrograde state. Use for "where is X" questions rather than a full chart. Bodies: Sun through Pluto, plus NorthNode, SouthNode (mean lunar nodes), Lilith (mean lunar apogee / Black Moon Lilith), and Chiron (n-body from public JPL initial conditions).
Examples:
"Where is Mars right now?" -> { body: "Mars" } (datetime defaults to now)
"Was Mercury retrograde on 2026-01-01?" -> inspect retrograde in the result
"Moon sign at 14:30 in Riga on 3 May 1985" -> { body: "Moon", datetime: "1985-05-03T14:30", timezone: "Europe/Riga" }
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Which body or point to locate. | |
| zodiac | No | Zodiac frame: tropical (Western default), sidereal-lahiri (Vedic), or sidereal-fagan-bradley (Western sidereal). | tropical |
| datetime | No | Moment to compute for. Defaults to now. | |
| timezone | No | IANA timezone the datetime is local to, e.g. "Europe/Riga" or "America/New_York". Omit when the datetime already carries Z or a UTC offset. |
| Name | Required | Description |
|---|---|---|
| body | Yes | |
| sign | Yes | |
| speed | Yes | |
| longitude | Yes | |
| retrograde | Yes | |
| degreeInSign | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnly, idempotent, non-destructive) are consistent. Description adds behavioral details: geocentric ecliptic coordinate system, defaulting datetime to now, timezone handling, and supported bodies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
First sentence states the core purpose, followed by return values, usage comparison, body list, and examples. No redundant sentences; all content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers all necessary aspects: purpose, usage guidance, parameter behavior, and examples. No gaps for this single-body, single-moment tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value with examples showing parameter usage (e.g., leaving datetime empty, combining with timezone). The default behavior for datetime and the meaning of 'zodiac' options are clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the zodiac position of a single body/point at a single moment, listing return fields. It explicitly distinguishes from siblings ('rather than a full chart').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use for "where is X" questions rather than a full chart.' Includes three examples covering common scenarios, though no explicit when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.0compute_natal_chart2 fields changedOutput schema / properties / partOfFortuneAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "dayChart": {
+ "type": "boolean"
+ },
+ "degreeInSign": {
+ "type": "number"
+ },
+ "longitude": {
+ "type": "number"
+ },
+ "sign": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "longitude",
+ "sign",
+ "degreeInSign",
+ "dayChart"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "utc",
- "location",
- "zodiac",
- "ayanamsa",
- "positions",
- "houses",
- "aspects"
-]New value: +[
+ "utc",
+ "location",
+ "zodiac",
+ "ayanamsa",
+ "positions",
+ "houses",
+ "partOfFortune",
+ "aspects"
+]find_aspect_times1 field changedInput schema / properties / natal_body / enumPrevious value: -[
- "Sun",
- "Moon",
- "Mercury",
- "Venus",
- "Mars",
- "Jupiter",
- "Saturn",
- "Uranus",
- "Neptune",
- "Pluto",
- "NorthNode",
- "SouthNode",
- "Lilith"
-]New value: +[
+ "Sun",
+ "Moon",
+ "Mercury",
+ "Venus",
+ "Mars",
+ "Jupiter",
+ "Saturn",
+ "Uranus",
+ "Neptune",
+ "Pluto",
+ "NorthNode",
+ "SouthNode",
+ "Lilith",
+ "Chiron"
+]get_planet_position1 field changedInput schema / properties / body / enumPrevious value: -[
- "Sun",
- "Moon",
- "Mercury",
- "Venus",
- "Mars",
- "Jupiter",
- "Saturn",
- "Uranus",
- "Neptune",
- "Pluto",
- "NorthNode",
- "SouthNode",
- "Lilith"
-]New value: +[
+ "Sun",
+ "Moon",
+ "Mercury",
+ "Venus",
+ "Mars",
+ "Jupiter",
+ "Saturn",
+ "Uranus",
+ "Neptune",
+ "Pluto",
+ "NorthNode",
+ "SouthNode",
+ "Lilith",
+ "Chiron"
+]v0.2.0compute_composite_chartcompute_natal_chartcompute_progressionscompute_synastrycompute_transitsfind_aspect_timesfind_eclipsesfind_retrograde_periodsfind_returnsfind_sign_ingressesget_moon_phaseget_planet_positionEach tool targets a distinct astrological computation or query (e.g., natal chart, synastry, transits, aspects, eclipses). Descriptions clearly differentiate them, leaving no ambiguity.
All tools follow a consistent verb_noun pattern in lowercase snake_case (compute_*, find_*, get_*). The naming is predictable and systematic.
With 12 tools, the server covers the full scope of astrological calculations without overloading or underrepresenting core functionalities. This is well within the ideal range.
The tool set includes all major astrological techniques: natal, synastry, composite, transits, progressions, returns, eclipses, retrogrades, ingresses, and single body positions. No obvious gaps for a comprehensive astrology API.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Professional Vedic astrology tools for AI agents via MCP.
Official Divine API MCP for Western Astrology: Natal, Synastry, Transit, Composite, Progressions.
Real astrology for AI agents: cosmic weather, synastry, timing, astrocartography, and divination.
Western natal charts, horoscopes, transits and synastry for AI agents, verified vs NASA JPL.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/igmizo/auseklis'
If you have feedback or need assistance with the MCP directory API, please join our Discord server