What can you do with this server?

Astral MCP is a local, stateless MCP server that provides precision-audited astrological computations for AI agents — no API keys or accounts required. Core Capabilities * Natal Charts: Generate full birth charts with planet positions, houses, aspects, retrogrades, and chart signature. Support for 7 house systems (Placidus, Whole Sign, etc.), tropical & sidereal zodiacs, dual-engine precision audit (<0.01°), and payload privacy modes (full/structured/summary). Output in markdown or JSON. * Current & Future Transits: Show planetary transits to a natal chart, including upcoming activation windows and moon phase. Specify any date/time. * Synastry: Compare two charts for compatibility, including inter-chart aspects and scored dimensions (harmony, chemistry, communication, growth) with a 0–100 overall score. * Moon Phase: Get the moon's phase, sign, illumination percentage, and sun–moon angle for any date/time — no birth data needed. * Geocoding: Convert place names to latitude, longitude, and IANA timezone via OpenStreetMap (no API key; optional, otherwise fully offline). Utility Tools * Demo Chart: Retrieve a sample natal chart with precision audit to preview the payload structure. * Capabilities & Data Inventory: Query supported features, house systems, zodiacs, bodies, aspects, and data domains. * Agent Manifest: Get setup instructions, tool list, agent rules, and troubleshooting. * Connection Health Check: Verify server operation by testing ephemeris engines with a sample chart. Key Features * Dual‑Engine Precision: Independent validation by two ephemerides; worst disagreement under 0.01°. * Privacy Modes: “full”, “structured”, or “summary” to control response size (up to ~80% smaller). * Local & Offline: Stateless; stores nothing, requires no credentials. Network only needed for optional geocoding. * Flexible Output: Choose between human‑readable markdown or structured JSON.

Which integrations are available for this server?

Provides geocoding services to convert place names into latitude, longitude, and timezone for astrology calculations.

Astral MCP

Q: Which integrations are available for this server?

Provides geocoding services to convert place names into latitude, longitude, and timezone for astrology calculations.

by davidmosiah

Overview Schema Related Servers Score Discussions

TypeScript

Local

⚡ Zero-setup install. Wire it into Claude Desktop / Cursor / Hermes and call it immediately — no API key, no OAuth, no account: npx -y astral-mcp

A local-first MCP server that turns birth data into a full, precision-audited astrological reading for AI agents. Stateless and computational — nothing is stored, no credentials exist, and every tool but optional geocoding runs fully offline.

Astral MCP is Delx's focused astrology product. See the Delx platform map for its boundary with the separate Protocol, Security, Wellness and Commerce properties.

Built by David Mosiah. The astrology engine is ported from the Alkhemia app.

New to the protocol pattern? Read What Is an Astrology MCP Server? for the separation between deterministic chart computation and model interpretation, the recommended agent workflow, and the precision/privacy boundaries.

Ready to calculate one? Follow How to Generate a Natal Chart with MCP for the exact birthplace, timezone, unknown birth-time, payload and precision-audit workflow.

Handling sensitive inputs? Read How to Protect Birth Data in Astrology Agent Workflows for payload minimization, local computation, the optional OpenStreetMap boundary and the limits of privacy_mode=summary.

Why this exists

Most astrology libraries are fragile single-engine wrappers, and most "astrology APIs" want a key and a subscription. Agents need something they can trust and call instantly. Astral MCP does two things differently:

It just works. npx -y astral-mcp and you're calling charts — no OAuth, no account, no birthplace database to install.
It checks itself. Every natal chart is computed with one ephemeris and then independently re-derived, planet by planet, with a second one. If they disagree beyond a tight tolerance, the chart is flagged review instead of silently returning a wrong placement.

Related MCP server: astroway-mcp

Setup in 60 seconds

Add it to your MCP client (Claude Desktop, Cursor, Hermes, …):

{
  "mcpServers": {
    "astral": {
      "command": "npx",
      "args": ["-y", "astral-mcp"]
    }
  }
}

That's the whole setup. There is nothing to authenticate.

Run it directly if you want:

npx -y astral-mcp                      # stdio (default)
ASTRAL_MCP_TRANSPORT=http npx -y astral-mcp   # streamable HTTP on 127.0.0.1:3000

See it before you connect

Call astral_demo for a fully-worked example chart (Greenwich, noon, Y2K) including its precision audit — no input, no network, no auth. It shows you the exact payload shape before you send real birth data.

Try it with your agent

"What's my natal chart? I was born 23 Feb 1989, 14:30, in Fortaleza, Brazil."

The agent calls astral_search_birthplace to resolve Fortaleza → lat/lon/timezone, then astral_compute_natal_chart.

"Any big transits hitting my chart this week?" → astral_current_transits "How compatible are we?" (two birth datas) → astral_synastry "What phase is the moon in today?" → astral_moon_phase

Precision

Astral MCP ships every natal chart with a precision audit. The primary engine (circular-natal-horoscope-js) computes the chart; the verifier (astronomy-engine) re-derives each planet's ecliptic longitude independently. A chart is verified only when every planet agrees within tolerance and lands in the same sign.

Across a built-in accuracy suite of charts spanning 1945–2010 and six timezones, the worst cross-engine disagreement is under 0.01°. Run it yourself:

npm run test:accuracy

Data availability

Capability	Supported
Planets (Sun…Pluto), Ascendant, MC/IC	✅
Houses (placidus, koch, campanus, regiomontanus, topocentric, equal-house, whole-sign)	✅
Major aspects with orb, strength, applying/separating	✅
Chart signature (dominant element/modality, pattern, stelliums, angular planets)	✅
Retrogrades · timezone/DST handling	✅
Transits (current + upcoming) · moon phase	✅
Synastry (two-chart comparison, scored)	✅
Tropical & sidereal zodiac	✅
Lunar nodes, Chiron, asteroids, fixed stars	⏳ planned
Minor aspects	⏳ planned
Interpretation text	❌ by design — astral-mcp returns structured data; your model writes the reading

Tools

astral_compute_natal_chart — full natal chart, precision-audited by default
astral_current_transits — current + upcoming transits to a chart, with moon phase
astral_synastry — compare two charts (harmony / chemistry / communication / growth)
astral_moon_phase — moon phase, sign and illumination for any date
astral_search_birthplace — geocode a place to latitude / longitude / timezone
astral_demo — worked example chart, no input needed
astral_capabilities — what this server supports and what it doesn't
astral_data_inventory — data domains and recommended first calls
astral_agent_manifest — install + usage rules for agents
astral_connection_status — health check via a sample chart + dual-engine audit

The three chart tools (astral_compute_natal_chart, astral_current_transits, astral_synastry) take a privacy_mode parameter — a payload-verbosity axis separate from response_format:

full (default) — the complete payload, including the per-planet precision audit
structured — same structure, redundant/derivable fields dropped
summary — only the high-signal essentials (luminaries + Ascendant, chart signature, top aspects)

A full Greenwich natal payload is ~6.9 KB; summary is ~1.2 KB (~80% smaller), so an agent that only needs a quick read can ask for less and spend fewer tokens.

Notes for accurate readings

Pass the birthplace timezone, not the caller's. astral_search_birthplace returns it.
birth_time is optional. Without it, noon is assumed: planet signs stay accurate, but the Ascendant and houses are unreliable.

Privacy & Security

Astral MCP stores nothing and holds no secrets. The only optional network call is astral_search_birthplace (OpenStreetMap), which sends just the place-name string you pass. See SECURITY.md.

Contributing

The computation core in src/engine/ is ported from Alkhemia — keep it framework-free. See AGENTS.md for the development rules and the test gate (npm test).

License

MIT — see LICENSE.

HTTP (v2 stateless)

Default is stdio. Optional Streamable HTTP — no session id, JSON responses, loopback only:

npx -y astral-mcp --http
# GET  http://127.0.0.1:3000/health
# POST http://127.0.0.1:3000/mcp   (sessionless)

Env: ASTRAL_MCP_HOST, ASTRAL_MCP_PORT, ASTRAL_MCP_TRANSPORT=http.

Skill or MCP

npx -y astral-mcp call astral_connection_status --json '{}'

Available Tools

10 tools

astral_agent_manifestAstral Agent ManifestA

Read-onlyIdempotent

Agent-oriented setup and usage guide: install command, recommended first calls, the full tool list, agent rules (resolve birthplace first, pass birthplace timezone, birth_time caveats) and troubleshooting. Call this to learn how to drive astral-mcp correctly.

ParametersJSON Schema

Name	Required	Description	Default
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`links`	Yes
`package`	Yes
`project`	Yes
`mcp_name`	Yes
`agent_rules`	Yes
`standard_tools`	Yes
`troubleshooting`	Yes
`data_access_model`	Yes
`recommended_first_calls`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, non-destructive operations. The description adds behavioral context by specifying it includes agent rules (e.g., 'resolve birthplace first') and troubleshooting, which go 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with key information. The first sentence efficiently lists contents; the second gives clear usage instruction. However, it could be slightly more concise by omitting redundant phrases like 'agent-oriented setup and usage guide' (two similar terms).

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 tool is a manifest/guide, the description fully covers what it provides (install, rules, troubleshooting) and mentions output formats. It is complete for an agent seeking an overview of how to use astral-mcp, especially with an output schema available.

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 coverage is 100% with clear descriptions for the enum parameter 'response_format'. The description adds high-level context about the tool being a 'guide' but doesn't elaborate on how parameter values affect output beyond what the schema states. Baseline score of 3 is appropriate.

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 clearly states it is an 'agent-oriented setup and usage guide' and lists specific contents (install command, recommended first calls, tool list, agent rules, troubleshooting). It distinguishes itself from sibling tools like astral_capabilities and astral_demo by being the entry point for learning how to drive the MCP.

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?

Explicitly advises 'Call this to learn how to drive astral-mcp correctly,' implying it should be invoked first. It lists what the guide covers, helping agents decide when to use it, though it doesn't explicitly state when not to use it or mention alternative tools for specific tasks.

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

astral_capabilitiesAstral CapabilitiesA

Read-onlyIdempotent

Explain what astral-mcp can compute: supported house systems, zodiacs, bodies, aspects and features, the dual-engine precision model, what is NOT included (nodes, Chiron, interpretations), and the recommended agent workflow. Read this first to plan a sequence of calls.

ParametersJSON Schema

Name	Required	Description	Default
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`links`	Yes
`creator`	Yes
`engines`	Yes
`project`	Yes
`mcp_name`	Yes
`supported`	Yes
`not_included`	Yes
`recommended_agent_flow`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about the content (e.g., no interpretations) and recommended workflow, which goes 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundancy. The first sentence lists key content, the second provides a directive. It is front-loaded and every sentence adds value.

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 tool is a capabilities overview, the description covers included/excluded items and workflow. Output schema handles return structure. The description is fully adequate for its purpose.

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 covers 100% of the single parameter with enum and description. The description adds meaning by explaining the difference between 'markdown' and 'json' outputs, helping the agent choose appropriately.

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 uses specific verb 'explain' and resource 'astral-mcp capabilities', listing included and excluded items. It clearly distinguishes from sibling tools by being the general overview.

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 'Read this first to plan a sequence of calls', providing clear when-to-use guidance. It also lists what is NOT included, helping avoid misuse. However, it does not explicitly state alternatives.

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

astral_compute_natal_chartCompute Natal ChartA

Read-onlyIdempotent

Compute a full natal (birth) chart from birth data: planet signs/degrees/houses, retrogrades, major aspects with orb and strength, the Ascendant/MC, and a derived signature (dominant element/modality, chart pattern, stelliums, angular planets). By default the chart is precision-audited by a second independent ephemeris. This is the primary tool. If you only have a city name, call astral_search_birthplace first to get latitude/longitude/timezone. Use privacy_mode to control payload size (a full chart is large): 'full' (default) returns everything; 'structured' drops redundant fields; 'summary' returns only the luminaries, Ascendant, chart signature and top aspects to save tokens.

ParametersJSON Schema

Name	Required	Description	Default
`zodiac`	No	Zodiac. 'tropical' (Western, season-anchored) or 'sidereal' (Vedic/constellation-anchored).	tropical
`latitude`	Yes	Birth latitude in decimal degrees, -90..90. Resolve from a city name with astral_search_birthplace if you don't have it.
`timezone`	Yes	IANA timezone of the BIRTHPLACE at birth, e.g. America/Fortaleza. Not the caller's timezone. astral_search_birthplace returns this for each match.
`longitude`	Yes	Birth longitude in decimal degrees, -180..180 (negative = West). Resolve with astral_search_birthplace if unknown.
`birth_date`	Yes	Birth date as YYYY-MM-DD, e.g. 1989-02-23. Years before 1900 and after 2100 are supported but less precise.
`birth_time`	No	Local birth time as 24h HH:MM, e.g. 14:30. Optional — if unknown, noon is assumed and house/ascendant accuracy drops (planets stay accurate).
`house_system`	No	House system. 'placidus' is the modern default; 'whole-sign' is common in traditional/Hellenistic work; others: koch, campanus, regiomontanus, topocentric, equal-house.	placidus
`privacy_mode`	No	Payload verbosity — how much of the chart to return, independent of response_format (which only picks markdown vs json). 'full' (default) returns the complete payload: every planet, house and aspect plus the per-planet precision audit. 'structured' keeps the full structure but drops redundant/derivable fields (absolute longitudes, element/modality, the precision audit rows) for a leaner machine payload. 'summary' returns only the high-signal essentials (luminaries + Ascendant, dominant element/modality, chart pattern, top aspects, precision status) to save tokens. Request 'summary' for a quick read, 'full' when you need every placement.	full
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown
`verify_precision`	No	When true (default), independently re-derives every planet with a second ephemeris and attaches a precision audit. Set false to skip the cross-check.

Output Schema

ParametersJSON Schema

Name	Required	Description
`meta`	Yes
`houses`	Yes
`aspects`	Yes
`context`	Yes
`planets`	Yes
`precision`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already mark the tool as read-only and idempotent. The description adds important behavioral details: by default a second ephemeris audits precision, and missing birth_time defaulting to noon reduces house accuracy. This adds value 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with front-loaded purpose and clear separation of key points. While it is somewhat long, every sentence contributes necessary information. Minor redundancy in parameter descriptions could be trimmed, but overall it earns its length.

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 tool has an output schema (indicated by context signals), the description does not need to detail return format. It covers all essential aspects: purpose, prerequisites (astral_search_birthplace), parameter behaviors, and privacy modes. This is fully adequate for a complex computational tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 10 parameters have descriptions in the schema, and the tool description adds meaningful context beyond the schema. For example, it explains how to resolve latitude/longitude/timezone via astral_search_birthplace, warns about date range precision, and details the effect of missing birth_time. The description of privacy_mode parameter is particularly thorough.

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 clearly states it computes a full natal chart from birth data, listing specific outputs like planet signs, aspects, and chart signature. It distinguishes itself from the sibling tool astral_search_birthplace by indicating that tool is for resolving location data before using this one.

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 provides explicit guidance: it is the primary tool, and if only a city name is available, astral_search_birthplace should be called first. It also explains when to use different privacy_mode settings (summary for quick read, full for detailed). However, it does not explicitly list situations where other tools should be used instead.

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

astral_connection_statusAstral Connection StatusA

Read-onlyIdempotent

Health check. The server is stateless and local, so this verifies the Node version and proves both bundled ephemerides load and agree by computing a sample chart and running the dual-engine precision audit. Call this to confirm the install is working before computing real charts.

ParametersJSON Schema

Name	Required	Description	Default
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`node`	Yes
`notes`	Yes
`ready`	Yes
`engines`	Yes
`next_steps`	Yes
`self_check`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds value by explaining the internal process (sample chart, dual-engine audit) and the stateless/local nature, which are not covered by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with 'Health check,' and each sentence adds value. No unnecessary words.

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?

The tool is simple with 0 required parameters and an output schema exists. The description covers purpose, behavior, and usage context adequately. No gaps.

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 coverage is 100%, and the parameter is simple. The description does not add additional meaning beyond the schema's description of response_format. Baseline score of 3 is appropriate as no extra parameter guidance is needed.

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 clearly identifies the tool as a health check with specific actions: verifying Node version, testing ephemerides, computing a sample chart, and running a precision audit. It distinguishes from sibling tools like astral_compute_natal_chart by being a diagnostic rather than a chart computation tool.

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 states when to use: 'Call this to confirm the install is working before computing real charts.' This provides clear context, though it does not list explicit alternatives or exclusions. The usage is well-defined.

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

astral_current_transitsCurrent TransitsA

Read-onlyIdempotent

Read the current (or a chosen date's) planetary transits against a natal chart. Returns the active transit aspects to the natal planets and angles, upcoming activation windows over the next days, and the current moon phase. Supply the same birth data you would for a natal chart; pass on_date/on_time to read a specific moment. Useful for 'what's happening for me astrologically' questions. Set privacy_mode=summary for just the moon phase and top transit aspects (omitting the full current-sky planet map), 'structured' for a leaner payload, or 'full' (default) for everything.

ParametersJSON Schema

Name	Required	Description	Default
`zodiac`	No	Zodiac. 'tropical' (Western, season-anchored) or 'sidereal' (Vedic/constellation-anchored).	tropical
`on_date`	No	Local date to read transits for as YYYY-MM-DD. Defaults to today.
`on_time`	No	Local time of the transit reading as 24h HH:MM. Defaults to noon.
`latitude`	Yes	Birth latitude in decimal degrees, -90..90. Resolve from a city name with astral_search_birthplace if you don't have it.
`timezone`	Yes	IANA timezone of the BIRTHPLACE at birth, e.g. America/Fortaleza. Not the caller's timezone. astral_search_birthplace returns this for each match.
`longitude`	Yes	Birth longitude in decimal degrees, -180..180 (negative = West). Resolve with astral_search_birthplace if unknown.
`birth_date`	Yes	Birth date as YYYY-MM-DD, e.g. 1989-02-23. Years before 1900 and after 2100 are supported but less precise.
`birth_time`	No	Local birth time as 24h HH:MM, e.g. 14:30. Optional — if unknown, noon is assumed and house/ascendant accuracy drops (planets stay accurate).
`house_system`	No	House system. 'placidus' is the modern default; 'whole-sign' is common in traditional/Hellenistic work; others: koch, campanus, regiomontanus, topocentric, equal-house.	placidus
`privacy_mode`	No	Payload verbosity — how much of the chart to return, independent of response_format (which only picks markdown vs json). 'full' (default) returns the complete payload: every planet, house and aspect plus the per-planet precision audit. 'structured' keeps the full structure but drops redundant/derivable fields (absolute longitudes, element/modality, the precision audit rows) for a leaner machine payload. 'summary' returns only the high-signal essentials (luminaries + Ascendant, dominant element/modality, chart pattern, top aspects, precision status) to save tokens. Request 'summary' for a quick read, 'full' when you need every placement.	full
`include_angles`	No	Include transits to the Ascendant and Midheaven. Requires an accurate birth_time to be meaningful.
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`moon`	Yes
`note`	No
`abridged`	No
`timezone`	Yes
`upcoming`	Yes
`localDate`	Yes
`localTime`	Yes
`highlights`	Yes
`generatedAt`	Yes
`privacy_mode`	No
`currentPlanets`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds valuable context such as return contents (aspects, windows, moon phase), behavior of on_date/on_time, and effect of privacy_mode levels. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with front-loaded purpose, followed by output details, data requirements, use case, and parameter options. Efficiently uses sentences without redundancy.

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 tool's complexity (12 parameters, enums, output schema exists), the description covers all key aspects: input requirements, output nature, parameter nuances, and use case. Output schema covers return values, so additional details are not necessary.

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 covers all 12 params with descriptions (100% coverage). The tool description adds extra semantic value by explaining how privacy_mode levels affect payload and the use of on_date/on_time for specific moments, going beyond 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?

Description clearly states verb 'Read' and resource 'planetary transits against a natal chart'. It distinguishes from siblings by focusing on transits specifically, citing use case 'what's happening for me astrologically'.

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?

Explicitly says tool is for transit questions and provides guidance on privacy_mode. Does not explicitly mention when to use alternatives like astral_compute_natal_chart, but the sibling list and context make it clear.

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

astral_data_inventoryAstral Data InventoryA

Read-onlyIdempotent

Inventory the data domains this server exposes (natal, transits, relationship, geocoding), which tools serve each, and the recommended first calls. Does not compute anything or take any input beyond response_format.

ParametersJSON Schema

Name	Required	Description	Default
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`notes`	Yes
`mcp_name`	Yes
`categories`	Yes
`first_tools`	Yes
`generated_at`	Yes
`data_access_model`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds beyond annotations: 'Does not compute anything or take any input beyond response_format' reinforces the read-only, no-side-effect behavior. It also clarifies the scope of what is inventoried.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The main action ('Inventory...') is front-loaded. Every sentence adds essential information about purpose, scope, and constraints.

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 low parameter count (1, optional, with full schema coverage), rich annotations, and existence of an output schema (though not provided), the description is complete. It explains what the tool returns (domains and tools), that it's read-only, and that it requires no substantive input.

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 coverage is 100%, so baseline is 3. The description mentions that the tool 'take any input beyond response_format', which repeats the schema. The description of the parameter in the schema already explains the output shape. The description adds little new semantic value beyond what the schema provides.

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?

Description clearly states the tool's purpose: 'Inventory the data domains this server exposes (natal, transits, relationship, geocoding), which tools serve each, and the recommended first calls.' It uses a specific verb ('Inventory') and resource ('data domains'), differentiating it from sibling tools like astral_compute_natal_chart or astral_current_transits which perform computations. The added clarification 'Does not compute anything' further distinguishes it.

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 implies usage for understanding server capabilities and recommended initial calls. It explicitly states 'Does not compute anything,' signaling when not to use it. However, it does not explicitly mention alternative tools or when to prefer this over others, though the context makes it clear it's a meta tool.

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

astral_demoAstral DemoA

Read-onlyIdempotent

Return a fully-worked example natal chart (Greenwich, noon, 2000-01-01) including a precision audit, so you can see the exact payload shape before sending real birth data. The returned 'input' is a ready-to-send argument object for astral_compute_natal_chart — copy it and swap in real birth data; 'chart' is exactly what that call returns at the default privacy_mode=full. No input, no network, no auth.

ParametersJSON Schema

Name	Required	Description	Default
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`note`	Yes
`chart`	Yes
`input`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, the description adds important behavioral context: no network, no auth, no required input, and a clear mapping between the returned 'input' and 'chart' fields. This gives the agent a precise mental model of what will happen when invoked.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every clause earns its place: it front-loads the purpose, gives the example details, explains the output structure, and finishes with cost/access characteristics. There is no filler or repetition.

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 zero-required-parameter demo tool with an output schema, the description is complete: it explains what the example contains, how it relates to the real compute tool, and that no network or auth is needed. Nothing essential 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% for the single optional response_format parameter, including its enum and default. The description does not need to restate that; it adds no extra parameter-level meaning, which matches the baseline 3 for fully-schema-covered parameters.

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 states a specific verb ('Return') and resource ('fully-worked example natal chart'), and explains exactly what the demo provides: a precision audit and exact payload shape. It clearly distinguishes itself from astral_compute_natal_chart by framing this as a pre-flight example rather than a real computation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly tells the agent when to use this tool: before sending real birth data, to inspect the payload shape. It also names the alternative (astral_compute_natal_chart) and explains how to use the output as a template for that call, which is strong usage guidance.

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

astral_moon_phaseMoon PhaseA

Read-onlyIdempotent

Get the moon phase (new, waxing, full, waning, etc.), the moon's sign, illumination percentage and sun–moon angle for now or a chosen local date/time. Location-independent — no birth data needed. Good for ritual timing, journaling prompts, or 'what phase is the moon in' questions.

ParametersJSON Schema

Name	Required	Description	Default
`on_date`	No	Local date as YYYY-MM-DD. Defaults to today.
`on_time`	No	Local time as 24h HH:MM. Defaults to noon.
`timezone`	No	IANA timezone for interpreting on_date/on_time, e.g. America/New_York. Defaults to UTC.	UTC
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`angle`	Yes
`phase`	Yes
`moonSign`	Yes
`timezone`	Yes
`generatedAt`	Yes
`illumination`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, making safety clear. The description adds that it's location-independent and requires no birth data, providing additional behavioral context. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with zero wasted words. It front-loads the main action and outputs, follows with uniqueness (location-independence), and ends with use cases. Every sentence earns its place.

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 read-only lookup tool with 4 optional parameters and an output schema, the description covers purpose, inputs, uniqueness, and use cases. No critical gaps remain.

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%, so the input schema already documents each parameter's purpose. The description does not add new parameter-specific information beyond summarizing the overall functionality. It meets the baseline but does not exceed it.

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 clearly states the verb 'Get' and the resource 'moon phase' with specific attributes (phase, sign, illumination, angle). It differentiates from siblings by highlighting 'Location-independent — no birth data needed', distinguishing it from tools like astral_compute_natal_chart. Use cases are explicitly listed.

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 provides clear context: 'for now or a chosen local date/time' and 'location-independent'. It lists use cases (ritual timing, journaling prompts) but does not explicitly state when not to use this tool or mention alternative siblings. Nonetheless, the context is sufficient for most scenarios.

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

astral_search_birthplaceSearch BirthplaceA

Read-onlyIdempotent

Geocode a city or place name into latitude, longitude and IANA timezone using OpenStreetMap (free, no key). Call this FIRST whenever you only have a place name, then pass the chosen match's coordinates and timezone to the chart tools. Returns several matches; pick the one whose displayName matches the intended birthplace.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	City or place name to geocode, e.g. 'Fortaleza, Brazil'. Minimum 3 characters. Call this first when you only have a place name, then pass the returned latitude/longitude/timezone to the chart tools.
`language`	No	Preferred language for returned place names (ISO code), e.g. en, pt, es.	en
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`query`	Yes
`results`	Yes

TDQS

A4.5/5.0

Behavior4/5

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 that the tool is free and requires no API key, and that it returns multiple matches to choose from. This goes beyond annotations but could still elaborate on error cases or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all essential, no fluff. The most critical information (what it does, free, call first) is front-loaded. Every sentence adds value.

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?

The description covers the tool's purpose, workflow integration, and expected output selection. Given the presence of an output schema and low tool complexity, this is fully sufficient for an AI agent to use correctly.

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 coverage is 100% with good descriptions. The tool description adds little beyond the schema: it mentions the query example 'Fortaleza, Brazil' and the response_format values. Given high schema coverage, baseline 3 is appropriate.

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 clearly states the tool geocodes a place name into latitude, longitude, and IANA timezone using OpenStreetMap. It specifies the verb 'geocode' and the resource 'city or place name'. It also distinguishes this tool from sibling chart tools by indicating this should be called first.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Call this FIRST' and instructs to pass the returned coordinates/timezone to chart tools. It also notes that several matches are returned and the agent should pick the one matching the intended birthplace. This provides clear when-to-use and how-to-process instructions.

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

astral_synastrySynastry (Two-Chart Comparison)A

Read-onlyIdempotent

Compare two birth charts (synastry). Returns the inter-chart aspects between the two people's planets and angles, plus scored dimensions (harmony, chemistry, communication, growth) and an overall 0–100 score with a tone. Provide both people's birth data under 'person' and 'partner'. Resolve any city names with astral_search_birthplace first. Set privacy_mode=summary for just the score, tone, dimensions and strongest aspects; 'full' (default) returns the complete aspect list.

ParametersJSON Schema

Name	Required	Description	Default
`person`	Yes	First person's birth data.
`zodiac`	No	Zodiac. 'tropical' (Western, season-anchored) or 'sidereal' (Vedic/constellation-anchored).	tropical
`partner`	Yes	Second person's birth data.
`house_system`	No	House system. 'placidus' is the modern default; 'whole-sign' is common in traditional/Hellenistic work; others: koch, campanus, regiomontanus, topocentric, equal-house.	placidus
`privacy_mode`	No	Payload verbosity — how much of the chart to return, independent of response_format (which only picks markdown vs json). 'full' (default) returns the complete payload: every planet, house and aspect plus the per-planet precision audit. 'structured' keeps the full structure but drops redundant/derivable fields (absolute longitudes, element/modality, the precision audit rows) for a leaner machine payload. 'summary' returns only the high-signal essentials (luminaries + Ascendant, dominant element/modality, chart pattern, top aspects, precision status) to save tokens. Request 'summary' for a quick read, 'full' when you need every placement.	full
`response_format`	No	Output shape. 'markdown' is a readable briefing for display; 'json' returns the full structured chart for further processing.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`tone`	Yes
`score`	Yes
`aspects`	Yes
`abridged`	No
`dimensions`	Yes
`privacy_mode`	No

TDQS

A4.8/5.0

Behavior5/5

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

Discloses behavioral traits beyond annotations: mentions that missing birth_time reduces house/ascendant accuracy, and describes privacy_mode levels. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with clear structure: main purpose, then prerequisites, then options. No redundant information; every sentence earns its place.

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 tool with 6 parameters, nested objects, and output schema, the description covers prerequisite resolution, optional parameters, and edge cases (missing birth_time). Complete given available context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and description adds value by explaining usage (e.g., resolve with astral_search_birthplace, privacy_mode meanings, response_format options). Enhances understanding beyond schema alone.

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 clearly states the tool compares two birth charts (synastry) and returns inter-chart aspects, scored dimensions, and an overall score. It distinguishes from sibling tools like astral_compute_natal_chart (single chart) and astral_current_transits.

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?

Explicitly instructs to resolve city names with astral_search_birthplace first and provides guidance on privacy_mode options. Lacks explicit when-not-to-use scenarios, but the context is generally clear.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation3/5

The four computational tools (natal chart, transits, synastry, moon phase) are clearly distinct, but the three informational tools (capabilities, data inventory, agent manifest) overlap in purpose and could confuse an agent choosing which to call. The remaining support tools (birthplace search, demo, connection status) are well-separated.

Naming Consistency4/5

All tools share the consistent astral_ prefix and use snake_case, giving the set a unified look. However, naming style is mixed: some use verb_noun (compute_natal_chart, search_birthplace) while most are plain nouns (synastry, moon_phase, demo, capabilities), which is a minor inconsistency.

Tool Count4/5

Ten tools is a reasonable count for an astrology server, and each core capability has a dedicated tool. However, five of the ten are meta/informational tools (capabilities, inventory, manifest, demo, status), which feels slightly heavy relative to the five functional tools, though still within an acceptable range.

Completeness4/5

The server covers the main astrological workflows: natal charts, transits, synastry, moon phase, and geocoding prerequisites. Missing advanced features like progressions or solar returns are acknowledged omissions rather than dead ends, so agents can complete typical tasks without gaps.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Divine API - Western Astrology
com.divineapi
Official Divine API MCP for Western Astrology: Natal, Synastry, Transit, Composite, Progressions.
Research & Data
2
caelus-mcp A
io.github.heavyblotto
34-tool Caelus MCP for validated astrology: charts, transits, Vedic, facts, sky view, synthetic.
Research & Data
352
VedaVisor Vedic Astrology MCP A
io.github.dchhill
Professional Vedic astrology tools for AI agents via MCP.
Entertainment & Media
3
FreeAstroAPI Astrology
io.github.GabrielRw
Western, Vedic, and Chinese astrology calculations, charts, forecasts, and geocoding.
Location Services Data Visualization Research & Data
1

Related MCP Servers

Open Ephemeris
Databases Education & Learning Tools Entertainment & Media
openephemeris
A
license
A
quality
A
maintenance
Open Ephemeris is a high-precision astrology API with an MCP server exposing 116+ endpoints across natal charts, transits, synastry, Human Design, BaZi, solar returns, and much more.
Updated a day ago (2026-09-03 20:27 UTC)
39
3
MIT
astroway-mcpofficial
AI & Machine Learning
astroway
A
license
C
quality
B
maintenance
Comprehensive astrology MCP exposing every endpoint of the AstroWay Calculation API — natal charts, synastry, transits, Vedic dashas, Tarot, Numerology, Human Design. Sub-arcsecond Swiss Ephemeris precision, 10 000 free credits per month.
Updated 3 days ago (2026-09-02 13:10 UTC)
100
261
4
MIT
Astro MCP Server
Research & Data
aryaminus
F
license
Not graded
quality
C
maintenance
Multi-tradition astrology engine that computes real birth charts, transits, and synastry for AI agents via MCP tools.
Updated 3 months ago (2026-06-08 02:54 UTC)
6
-
auseklis
Research & Data
igmizo
A
license
A
quality
A
maintenance
Astrology MCP server that computes natal charts, transits, synastry, progressions, returns, eclipses, retrogrades, and moon phases from a real ephemeris, enabling AI agents to provide accurate astrological calculations without hallucination.
Updated 2 months ago (2026-07-10 11:06 UTC)
12
72
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidmosiah/astral-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Core Capabilities

Utility Tools

Key Features

Why this exists

Setup in 60 seconds

See it before you connect

Try it with your agent

Precision

Data availability

Tools

Notes for accurate readings

Privacy & Security

Contributing

License

HTTP (v2 stateless)

Skill or MCP

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

astroway-mcpofficial

Latest Blog Posts

MCP directory API