How do I use deepnatal?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@deepnatal Verify ascendant Scorpio 23.0 for 1988-07-15 14:30 Asia/Shanghai" 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.

deepnatal

by breezefeng

Overview Schema Related Servers Score Discussions

TypeScript

Local

deepnatal

A natal chart engine that cross-verifies every result three independent ways — and refuses to answer when it can't.

Ships as both a TypeScript library and an MCP server for Claude, Cursor, Codex, Cline and other agents.

npx -y deepnatal-mcp

npm test license

Why this exists

Ask any astrology site for a birth chart and you get an answer. You almost never get a way to check it.

That matters more than it sounds, because the ascendant — the rising sign — moves about one degree every four minutes. Get the UTC instant wrong by an hour and it shifts by roughly half a sign. The result still looks completely plausible. Nothing about it announces that it's wrong.

And an hour is easy to lose. Taiwan observed daylight saving in 1945–1961 and again in 1974–1979. Mainland China did from 1986 to 1991. Japan did from 1948 to 1951. Plenty of tools quietly apply today's UTC offset to a 1988 birth date and hand back a chart that's off by exactly one hour.

This package is built around the opposite assumption: a result you can't check is not a result.

Related MCP server: auseklis

How it verifies

Three independent paths compute every chart. Disagreement is an error, not something to average away.

Layer	Primary	Independent check
Timezone	Explicit IANA zone, Node ICU historical `tzdata`	Coordinate-derived zone lookup
Planets	`circular-natal-horoscope-js`	`astronomy-engine`
Ascendant	Astrology-library house calculation	Pure spherical geometry — ecliptic × eastern horizon, no astrology library involved

Typical agreement in practice is under one arcminute. Past tolerance, the call throws rather than returning a chart.

It also degrades honestly where the math genuinely breaks down:

Above 66° latitude, Placidus houses are undefined. The engine falls back to whole-sign and tells you it did, instead of emitting silent nonsense.
Without a birth time, the ascendant, midheaven and houses are simply omitted with reasons. No substituting noon. If the Moon changed sign that day — which happens on nearly half of all dates — that's reported too.
Inside a DST transition gap, where a local time either doesn't exist or happens twice, it throws and asks you to disambiguate.

Verify it yourself

A README asserting "cross-verified" is worth nothing on its own. The suite ships inside the published package, so you can run it against the exact bytes you installed:

npm i deepnatal
node node_modules/deepnatal/dist/selftest.js

✅ PASS — 21/21 boundary cases + 11/11 external cross-checks
   All three paths agree, and they agree with an outside source.

The 21 boundary cases are chosen to be the ones that break things, not the ones that are easy: China's 1986–1991 DST window and a same-year winter control, Taiwan 1979, Japan's 1948–1951 GHQ period, a time that never existed because a DST jump skipped it, and latitudes inside the Arctic Circle where Placidus is undefined.

The 11 external checks compare against values captured from astro-seek. Those exist because the three internal paths share assumptions — tropical zodiac, apparent geocentric positions, true ecliptic of date — and if an assumption itself were wrong, all three would agree on the same wrong answer. Only an outside source catches that.

CI runs the suite on Node 20/22/24 under a deliberately non-UTC system clock, so any accidental dependence on the host timezone fails loudly.

Quick start

npm install deepnatal

import { calculateNatalChart, verifyAscendant } from 'deepnatal';

const birth = {
  date: '1988-07-15',
  time: '14:30',
  timezone: 'Asia/Shanghai',   // the BIRTHPLACE's zone, never the user's current one
  latitude: 31.23,
  longitude: 121.47,
};

const chart = calculateNatalChart(birth);
chart.ascendant;             // { sign: 'scorpio', degreeInSign: 10.37, ... }
chart.crossCheckMaxArcmin;   // 0.467 — how far the two engines disagreed

Checking somebody else's answer

The reason this package exists. Pass a result from any other tool as claim:

verifyAscendant(birth, 'Scorpio 23.0');

{
  "computed":  { "sign": "scorpio", "degreeInSign": 10.37 },
  "geometric": { "sign": "scorpio", "degreeInSign": 10.37 },  // independent path
  "internalAgreementArcmin": 0,
  "oneHourOffsetTest": {
    "minusOneHour": { "sign": "libra",   "degreeInSign": 27.66 },
    "plusOneHour":  { "sign": "scorpio", "degreeInSign": 22.98 },
    "degreesPerHour": 12.66
  },
  "claim": {
    "verdict": "off-by-one-hour",
    "likelyCause": "Measured, not guessed: the supplied value matches this engine's
                    ascendant for a birth instant one hour LATER than the one given..."
  }
}

Note degreesPerHour: 12.66. The usual rule of thumb says an hour is 15° — that's the Earth's rotation rate, not the ascendant's rate of travel along the ecliptic, and the two only agree near the equator. This library measures it per chart instead of assuming it.

MCP server

npx -y deepnatal-mcp

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

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

claude mcp add deepnatal -- npx -y deepnatal-mcp

Tools

Tool	What it does
`calculate_natal_chart`	Ten planets with sign, degree, house, retrograde; ascendant, midheaven, twelve cusps. Fails rather than returning a chart the two engines disagree on.
`calculate_chart_without_birth_time`	Only what's knowable without a time. Lists what's missing and why. Flags an ambiguous moon sign.
`verify_ascendant`	Recomputes via pure geometry and adjudicates a value from another tool. Accepts `Virgo`, `處女座`, `12 Leo`, `Leo 12°34'`, or a bare longitude.
`inspect_historical_timezone`	What the historical tzdata actually did on that date, and whether DST was in effect.

Everything runs locally in the agent's own process. Birth data is about as sensitive as personal data gets, and none of it leaves the machine — there is no network call anywhere in this package.

Why let an agent call this instead of reasoning it out? Because a language model asked to work out a rising sign will produce a confident, plausible, wrong answer, and nothing downstream can detect that. This server returns computed facts and its own uncertainty. It never interprets.

中文說明

deepnatal 是一套會自我驗算的本命盤計算引擎——算不出來時它會拒絕回答，而不是給你一個看起來合理的答案。

上升星座每四分鐘移動約一度。時區算錯一小時，上升就偏掉大半個星座，而結果看起來完全正常，不會有任何地方提示你它是錯的。

而一小時很容易丟。台灣在 1945–1961、1974–1979 實施過夏令時間，中國大陸是 1986–1991，日本是 1948–1951。不少工具會把今天的時區偏移直接套到 1988 年的出生日期上。

三條獨立路徑同時計算，彼此不一致就報錯：

時區層　明確 IANA 時區 + Node ICU 歷史 tzdata，與座標反查時區交叉核對
行星層　circular-natal-horoscope-js × astronomy-engine 兩套獨立演算法
上升層　純球面幾何第三條路（黃道與東方地平線交點），完全不依賴任何占星函式庫

實測吻合度在 1 角分以內。超過容許值就丟出錯誤，不回傳星盤。

verifyAscendant() 可以用來檢查任何其他工具算出的上升是否正確。它不猜原因——而是實際重算前後各一小時的上升點，如果對方的答案正好落在那裡，就能證明差異來自時區處理而非天文計算。

完整工具與說明見 deepnatal.com。

What this does not prove

Being straight about the boundaries is part of the point.

Cross-verification catches implementation bugs and drift. It cannot prove the shared conventions are the right ones — all three paths assume the tropical zodiac, apparent geocentric positions and the true ecliptic of date.
A reproducible chart says nothing about whether astrology predicts anything. This package computes positions. It makes no claim about meaning.
Two tools can legitimately differ over house system, zodiac (tropical vs sidereal), ephemeris, node convention or rounding. verify_ascendant distinguishes a one-hour offset from these, but it doesn't declare a winner in matters of convention.
Wrong birth data still produces a technically correct chart of the wrong moment. Nothing downstream can rescue that.

Licensing

MIT. The dependency chain is deliberately kept clear for redistribution:

Package	License
`circular-natal-horoscope-js`	Unlicense (public domain)
`astronomy-engine`	MIT

Notably not Swiss Ephemeris (sweph / swisseph). Its dual AGPL-3.0-or-later OR LGPL-3.0-or-later listing is misleading: the LGPL option requires purchasing an Astrodienst commercial license first. Without one you're on AGPL, which reaches network services and would require open-sourcing everything that touches it. That constraint is why most hosted astrology products can't ship their calculation layer as an open package — this one can.

Credits

This is the calculation layer of deepnatal.com, extracted verbatim — the site runs the same code that ships here, so any chart it produces can be reproduced locally against this package.

Issues and PRs: github.com/breezefeng/deepnatal

Available Tools

4 tools

calculate_chart_without_birth_timeCalculate a chart without a birth timeA

For users who do not know their birth time. Returns only what is genuinely knowable without it, and explicitly lists what is not: ascendant, midheaven and all house positions are omitted with reasons rather than estimated. Also reports whether the Moon changed sign during that day — it does on nearly half of all dates, which means the moon sign itself is undetermined without a time. Never substitute noon and present the result as fact; that is exactly what this tool exists to prevent.

ParametersJSON Schema

Name	Required	Description
`date`	Yes	Local birth date at the birthplace, YYYY-MM-DD.
`latitude`	Yes	Birthplace latitude, decimal degrees.
`timezone`	Yes	IANA timezone of the BIRTHPLACE, e.g. Asia/Taipei. Never the user's current zone — people are routinely asked about a birth in another country.
`longitude`	Yes	Birthplace longitude, decimal degrees.

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the behavioral burden. It discloses that omitted chart points are not estimated, that only genuinely knowable data is returned, and that the Moon sign may be reported as undetermined when the Moon changed sign that day. This goes well beyond a generic 'calculate' description.

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?

Four sentences, with the target audience front-loaded and every sentence contributing a distinct, useful behavioral fact. There is no filler or repeated schema information, and the description remains readable despite covering nuanced caveats.

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?

Despite having no output schema, the description clearly communicates what the tool returns and what it deliberately omits, along with the Moon-sign uncertainty and the no-fabrication policy. Combined with the fully documented input schema, an agent has enough context 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.

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents all four parameters, including the important timezone caveat about birthplace versus user's current zone. The description adds context about date sensitivity for the Moon sign but does not need to repeat parameter-level syntax.

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 use case: calculating a chart when birth time is unknown. It distinguishes itself from a normal natal-chart calculation by explicitly naming what is omitted (ascendant, midheaven, houses) and by warning against the common noon-substitution shortcut.

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

Usage Guidelines4/5

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

It explicitly identifies the trigger condition: users who do not know their birth time. It also gives a clear exclusion by warning never to substitute noon and present the result as fact. It does not name sibling tools explicitly, but the intended usage is unambiguous from context.

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

calculate_natal_chartCalculate a natal chartA

Compute a full natal/birth chart: ten planets with sign, degree, house and retrograde status, plus ascendant, midheaven and twelve house cusps. Every result is cross-checked by two independent astronomy implementations and the call FAILS rather than returning a chart when they disagree. Use this whenever a user asks for a birth chart, rising sign, or planetary placements — do not attempt the arithmetic yourself. Requires an exact birth time; if the time is unknown use calculate_chart_without_birth_time instead.

ParametersJSON Schema

Name	Required	Description
`date`	Yes	Local birth date at the birthplace, YYYY-MM-DD.
`time`	Yes	Local clock time at the birthplace, HH:mm 24-hour, as written on the birth record.
`latitude`	Yes	Birthplace latitude, decimal degrees.
`timezone`	Yes	IANA timezone of the BIRTHPLACE, e.g. Asia/Taipei. Never the user's current zone — people are routinely asked about a birth in another country.
`longitude`	Yes	Birthplace longitude, decimal degrees.

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond basic functionality by explaining that results are cross-checked by two independent implementations and that the call FAILS rather than returning a chart on disagreement. It also states the exact-birth-time requirement, giving the agent a clear failure condition.

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 purposeful sentences: the first defines scope and output, the second explains the fail-safe behavior, and the third gives usage and routing guidance. No sentence is wasted and the critical usage guidance is front-loaded.

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?

Even without an output schema, the description enumerates the full set of returned chart components and the failure behavior when the two astronomy implementations disagree. Combined with fully documented parameters and an explicit alternative tool for missing birth time, an agent has enough context to invoke the tool 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 description coverage is 100%, so the schema already documents all five parameters in detail. The description adds some contextual meaning by emphasizing the exact birth time requirement, but does not add substantive meaning to any individual parameter 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?

The description states a specific verb ('Compute') and resource ('full natal/birth chart'), then enumerates exact output elements: ten planets with sign/degree/house/retrograde, ascendant, midheaven, and twelve house cusps. This clearly distinguishes the tool from siblings like verify_ascendant and calculate_chart_without_birth_time.

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 'Use this whenever a user asks for a birth chart, rising sign, or planetary placements' and warns not to do the arithmetic manually. It also provides a clear exclusion and alternative: if birth time is unknown, use calculate_chart_without_birth_time.

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

inspect_historical_timezoneInspect historical timezone and DSTA

Resolve a local birth date and time to UTC using historical timezone rules, and report whether daylight saving time was actually in effect on that date. This is the single most common source of wrong charts: many tools apply the PRESENT-DAY offset to a past date. Taiwan observed DST 1945-1961 and 1974-1979, mainland China 1986-1991, Japan 1948-1951 — a birth inside those windows is an hour off in tools that ignore them, which moves the ascendant about 15 degrees. Use this to explain WHY two charts differ.

ParametersJSON Schema

Name	Required	Description
`date`	Yes	Local birth date at the birthplace, YYYY-MM-DD.
`time`	Yes	Local clock time at the birthplace, HH:mm 24-hour, as written on the birth record.
`timezone`	Yes	IANA timezone of the BIRTHPLACE, e.g. Asia/Taipei. Never the user's current zone — people are routinely asked about a birth in another country.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the operation is a read/computation: resolving to UTC and reporting DST status. It also discloses a key behavioral nuance—it uses historical rules and avoids the present-day offset that causes wrong charts. It does not detail the exact return shape, but the 'report whether...' phrasing gives a solid implicit contract.

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 core purpose is front-loaded in the first sentence, and the additional historical examples are purposeful rather than filler. It is slightly verbose with the DST period list, but that content directly supports why the tool matters and when to use it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, the description covers what the tool does, why it is needed, and the common pitfall it avoids. It does not explicitly state the output format or edge cases like invalid dates during DST transitions, but it gives enough behavioral context for an agent to call it correctly and interpret its purpose.

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 baseline is 3. The description adds contextual value around the timezone parameter by explaining historical DST relevance and the birthplace-vs-user distinction, but it does not add parameter-level syntax or format details beyond what the schema already 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?

The description states a specific verb and resource: 'Resolve a local birth date and time to UTC using historical timezone rules' and 'report whether daylight saving time was actually in effect.' It distinguishes itself from chart-generation siblings by framing itself as the explanation for why charts differ, not as a chart calculator.

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 gives an explicit usage directive: 'Use this to explain WHY two charts differ.' It also provides concrete historical DST windows and warns against the common present-day-offset mistake, giving strong contextual cues for when this tool is appropriate. However, it does not explicitly contrast with sibling tools like calculate_natal_chart or verify_ascendant, so exclusions are implied rather than stated.

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

verify_ascendantIndependently verify an ascendantA

Recompute the ascendant along a third path that imports no astrology library at all — pure spherical geometry, the intersection of the ecliptic with the eastern horizon — and report how far it lands from the primary engine. Optionally pass a value produced ELSEWHERE (another website, an app, a printed chart) as claim and this will tell you whether it holds up and, when it does not, name the likely cause. Use this when a user says two sites disagree about their rising sign, doubts a result, or asks which one is correct. Accepts claims like "Virgo", "處女座", "12 Leo", "Leo 12°34'" or a bare ecliptic longitude.

ParametersJSON Schema

Name	Required	Description
`date`	Yes	Local birth date at the birthplace, YYYY-MM-DD.
`time`	Yes	Local clock time at the birthplace, HH:mm 24-hour, as written on the birth record.
`claim`	No	Optional ascendant produced by some other tool, to be checked against this engine.
`latitude`	Yes	Birthplace latitude, decimal degrees.
`timezone`	Yes	IANA timezone of the BIRTHPLACE, e.g. Asia/Taipei. Never the user's current zone — people are routinely asked about a birth in another country.
`longitude`	Yes	Birthplace longitude, decimal degrees.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the disclosure burden and does well: it reveals that the tool recomputes via a library-free spherical-geometry path, reports distance from the primary engine, and optionally validates an external claim, naming the likely cause when it fails. It does not cover failure modes or exact output details, but the core behavioral traits are transparent.

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 four sentences and every sentence earns its place: the independent method, verification behavior, usage trigger, and accepted claim formats. It is front-loaded with the core mechanism and contains no padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter tool with no annotations and no output schema, the description explains verification behavior, optional claim validation, when to invoke it, and accepted input formats. It does not specify the exact return structure or edge-case behavior, but the calling context is sufficiently complete for an agent to select and invoke the tool.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description adds meaningful examples for the `claim` parameter ('Virgo', '處女座', '12 Leo', 'Leo 12°34''), which the schema leaves abstract. It also reinforces that date, time, and timezone are local birthplace values, matching the schema's own definitions.

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 ('recompute'/'verify') and resource ('ascendant'), and clarifies that it uses a pure-spherical-geometry path independent of the primary engine. This clearly distinguishes it from sibling chart-calculuation tools and makes the tool's purpose unmistakable.

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 'Use this when a user says two sites disagree about their rising sign, doubts a result, or asks which one is correct,' providing concrete trigger conditions. It does not name alternatives among the siblings or state when not to use it, but the use cases are clear enough for an agent to route correctly.

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.5/5.0

Disambiguation5/5

Each tool has a distinct, clearly scoped job: full chart calculation, best-effort chart without a birth time, independent ascendant verification, and historical timezone resolution. The only potentially close pair is the two calculate_chart tools, but their exact-time vs unknown-time condition removes ambiguity.

Naming Consistency5/5

All tool names follow a predictable verb_object snake_case pattern: calculate_natal_chart, calculate_chart_without_birth_time, verify_ascendant, and inspect_historical_timezone. The names clearly communicate the action and target, with no mixed casing or vague verbs.

Tool Count5/5

Four tools is a tight, well-scoped set for a birth chart calculation service. Each tool earns its place by addressing a distinct user need or diagnosis path, and none feels redundant or missing.

Completeness5/5

The surface covers the full chart path, the no-birth-time fallback, external ascendant claim verification, and the most common hidden error source in chart calculation: historical timezone changes. There are no obvious dead ends for the stated purpose of computing and troubleshooting natal charts.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

FreeAstroAPI Astrology
io.github.GabrielRw
Western, Vedic, and Chinese astrology calculations, charts, forecasts, and geocoding.
Location Services Data Visualization Research & Data
1
Western Astrology MCP Server by RoxyAPI A
com.roxyapi
Western natal charts, horoscopes, transits and synastry for AI agents, verified vs NASA JPL.
Entertainment & Media
393
Location and Timezone MCP Server by RoxyAPI A
com.roxyapi
City geocoding and timezone resolution for birth data, for AI agents, one API key.
Location Services Open Data
32
Celestium: Cosmic Compass A
io.github.nacrissi
Real astrology for AI agents: cosmic weather, synastry, timing, astrocartography, and divination.
Entertainment & Media
12

Related MCP Servers

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
OpenFate Bazi MCPofficial
Art & Culture Research & Data
openfate-ai
A
license
A
quality
A
maintenance
Enables AI agents to calculate deterministic Bazi (Four Pillars) charts with True Solar Time and Earthly Branch interactions, avoiding LLM hallucination of calendrical math.
Updated 2 months ago (2026-07-02 06:06 UTC)
6
161
140
MIT
astro-mcp
Research & Data
DrewCyber
A
license
Not graded
quality
B
maintenance
High-precision astrology tools for LLM agents, including natal charts, transits, progressions, synastry, and more, backed by Swiss Ephemeris.
Updated 10 days ago (2026-08-24 11:40 UTC)
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/breezefeng/deepnatal'

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

deepnatal

Why this exists

How it verifies

Verify it yourself

Quick start

Checking somebody else's answer

MCP server

Tools

中文說明

What this does not prove

Licensing

Credits

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

OpenFate Bazi MCPofficial

Latest Blog Posts

MCP directory API