astrology-mcp
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., "@astrology-mcpcalculate natal chart for June 10 1985 10am London"
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
A Model Context Protocol (MCP) server that provides astrological natal chart calculations. Built with TypeScript and the MCP SDK, this server enables AI assistants to calculate and interpret astrological birth charts based on date, time, and location.
🌟 Now powered by @swisseph/node - Using the Swiss Ephemeris calculation engine for highly accurate astronomical calculations.
Features
Accurate Calculations - Powered by Swiss Ephemeris for high precision.
Complete Natal Charts - Detailed planet positions, houses, aspects, and chart angles.
Flexible Location - Support for coordinates or city names (free geocoding).
Multiple House Systems - Placidus, Koch, Whole Sign, and more.
Modern Stack - TypeScript, Zod validation, and latest MCP SDK.
Related MCP server: Swiss Ephemeris MCP Server
Quick Start
You can run the server directly using npx without installing anything:
npx -y @astrologer/astrology-mcpConfiguring with you MCP client
Standard config works in most tools.
{
"mcpServers": {
"astrology": {
"command": "npx",
"args": ["-y", "@astrologer/astrology-mcp"]
}
}
}Manual Installation (From Source)
If you want to modify the code or run from source:
git clone https://github.com/intellecat/astrology-mcp.git
cd astrology-mcp
npm install
npm run buildDependencies
Runtime
@modelcontextprotocol/sdk- Latest MCP SDK@swisseph/node- Swiss Ephemeris calculation engine (high precision)luxon- Timezone and date handlingnode-geocoder- Location to coordinate conversionzod- Schema validation
Development
typescript- TypeScript compiler@types/node- Node.js type definitions@types/node-geocoder- node-geocoder type definitions@types/luxon- Luxon type definitions
Usage
Building
npm run buildRunning the Server
npm startDevelopment Mode
npm run devTesting
Run the test script to verify the horoscope calculations:
npm testMCP Tools
1. astrology_calculate_natal_chart
Calculate a complete natal chart based on birth data.
Parameters:
datetime(object, required): Birth date and timeyear(number): Year (e.g., 1990)month(number): Month (1-12, where 1=January, 12=December)day(number): Day of month (1-31)hour(number): Hour in local time (0-23)minute(number): Minute (0-59)
location(object or string, required):As object:
{latitude: 40.7128, longitude: -74.0060}As string:
"New York, USA"
houseSystem(string, optional): House system to use (default: "Placidus")
Returns:
{
"planets": [
{
"name": "Sun",
"sign": "Taurus",
"degree": "24° 39' 24\"",
"longitude": 84.6567,
"house": 9,
"isRetrograde": false
}
],
"houses": [
{
"number": 1,
"sign": "Virgo",
"degree": "19° 27' 38\"",
"cuspDegree": 169.4606
}
],
"aspects": [
{
"point1": "Sun",
"point2": "Moon",
"aspect": "Trine",
"aspectLevel": "Major",
"orb": 5.85,
"orbUsed": 7
}
],
"chartAngles": {
"ascendant": {
"sign": "Virgo",
"degree": "19° 27' 38\"",
"longitude": 169.4606
},
"midheaven": {
"sign": "Gemini",
"degree": "17° 46' 33\"",
"longitude": 77.7759
},
"descendant": {
"sign": "Pisces",
"degree": "19° 27' 38\"",
"longitude": 349.4606
},
"imumCoeli": {
"sign": "Sagittarius",
"degree": "17° 46' 33\"",
"longitude": 257.7759
}
},
"sunSign": "Taurus",
"birthData": {
"datetime": {
"year": 1990,
"month": 5,
"day": 15,
"hour": 14,
"minute": 30
},
"location": "New York, NY, USA",
"latitude": 40.7128,
"longitude": -74.006,
"houseSystem": "Placidus"
}
}2. astrology_get_coordinates
Convert a location string to geographic coordinates.
Parameters:
location(string, required): Location in format "City, Country" (e.g., "London, UK")
Returns:
{
"latitude": 51.5074,
"longitude": -0.1278,
"formattedAddress": "London, Greater London, England, UK"
}Example Usage with MCP Client
Example 1: Calculate natal chart with coordinates
{
"tool": "astrology_calculate_natal_chart",
"arguments": {
"datetime": {
"year": 1990,
"month": 5,
"day": 15,
"hour": 14,
"minute": 30
},
"location": {
"latitude": 40.7128,
"longitude": -74.0060
}
}
}Example 2: Calculate natal chart with city name
{
"tool": "astrology_calculate_natal_chart",
"arguments": {
"datetime": {
"year": 1995,
"month": 12,
"day": 25,
"hour": 8,
"minute": 0
},
"location": "Paris, France",
"houseSystem": "Whole Sign"
}
}Example 3: Get coordinates for a location
{
"tool": "astrology_get_coordinates",
"arguments": {
"location": "Tokyo, Japan"
}
}House Systems Supported
The server supports various house systems including:
Placidus (default)
Koch
Equal
Whole Sign
Campanus
Regiomontanus
And more supported by the Swiss Ephemeris library
Technical Details
Date Format
Month is 1-12 (1 = January, 12 = December)
Hour is in 24-hour format (0-23)
All times are in local time for the birth location
Coordinate Format
Latitude: -90 to 90 (negative for South)
Longitude: -180 to 180 (negative for West)
Zodiac System
Uses tropical zodiac (aligned with seasons)
Degrees are measured from 0° Aries
Astrological Information Provided
Planets
Sun, Moon, Mercury, Venus, Mars, Jupiter, Saturn, Uranus, Neptune, Pluto, North Node (Mean Node), Chiron
Chart Points
Ascendant (AS) - Rising sign
Midheaven (MC) - Medium Coeli
Descendant (DS) - Opposite Ascendant
Imum Coeli (IC) - Opposite Midheaven
Aspects
Automatically calculates aspects between all planets with configurable orbs:
Major Aspects:
Conjunction (0°, orb: 10°)
Sextile (60°, orb: 6°)
Square (90°, orb: 8°)
Trine (120°, orb: 8°)
Opposition (180°, orb: 10°)
Minor Aspects:
Semi-Sextile (30°, orb: 3°)
Semi-Square (45°, orb: 3°)
Sesquiquadrate (135°, orb: 3°)
Quincunx (150°, orb: 3°)
License
AGPL-3.0
Migration to Swiss Ephemeris
This server has been migrated from circular-natal-horoscope-js to @swisseph/node for improved accuracy. The Swiss Ephemeris is the industry standard for astronomical calculations in astrology, providing:
Higher precision planetary positions (accurate to arcminutes)
Reliable retrograde detection
Extensive support for asteroids and minor bodies
Industry-standard calculations used by professional astrologers
See MIGRATION_NOTES.md and compare-libraries.ts for migration details and accuracy comparisons.
Credits
Built with:
Swiss Ephemeris (@swisseph/node) - High-precision astronomical calculations
Model Context Protocol SDK - MCP framework
node-geocoder - Geocoding service
Luxon - Date and timezone handling
Available Tools
2 toolsastrology_calculate_natal_chartARead-onlyIdempotent
Calculate a complete natal chart (birth chart) based on date, time, and location. Returns detailed astrological information including: planetary positions in zodiac signs and houses with exact degrees, all 12 houses with their cusps, chart angles (Ascendant/Rising, Midheaven, Descendant, Imum Coeli), and major aspects between planets with orbs. Supports multiple house systems.
| Name | Required | Description | Default |
|---|---|---|---|
| datetime | Yes | ||
| location | Yes | ||
| houseSystem | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and read-only behavior. The description adds no contradictory information but also does not elaborate on aspects like input validation, potential errors, or calculation caveats. It is adequate but minimal.
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 front-loads the main action and uses a bulleted list for return values. It is informative but slightly verbose; could be trimmed without losing 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 complexity of natal chart calculation and no output schema, the description provides a solid overview of what is returned. It covers planetary positions, houses, angles, and aspects, but could specify aspect types or degree precision.
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?
Despite 0% schema description coverage at the top level, the description adds meaning for the main parameters (datetime, location, house system). It clarifies location can be coordinates or city string, and house system is configurable. This compensates for missing 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?
The description clearly states the tool calculates a natal chart based on date, time, and location, and lists specific outputs (planetary positions, houses, angles, aspects). It distinguishes from the sibling tool astrology_get_coordinates, which is for coordinate lookup.
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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions support for multiple house systems but lacks context about when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
astrology_get_coordinatesARead-onlyIdempotent
Convert a location string (city, country) to geographic coordinates (latitude, longitude) using OpenStreetMap geocoding. Useful for obtaining coordinates before calculating a natal chart when only the city name is known.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Location in format 'City, Country' (e.g., 'London, UK') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds information beyond annotations (readOnlyHint, idempotentHint) by specifying the geocoding service (OpenStreetMap). It does not contradict annotations. A score of 4 reflects that while annotations already indicate safety, the description provides useful context about the external dependency.
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 two sentences with no wasted words. The first sentence states the core action, and the second provides the use case. It is front-loaded and gets straight to the point.
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 simplicity of this tool (1 parameter, no output schema), the description adequately covers what it does and why it is used. However, it could be slightly more explicit about the return format (e.g., 'returns latitude and longitude as numbers'). Still, the agent can infer from the name and use case.
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?
The input schema already provides 100% description coverage for the single parameter 'location', including the format 'City, Country'. The description restates the conversion purpose but does not add significant new parameter semantics beyond the schema. Baseline 3 is appropriate.
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 verb ('Convert'), resource ('location string'), and output ('geographic coordinates'). It also mentions the specific service (OpenStreetMap geocoding) and distinguishes from the sibling tool 'astrology_calculate_natal_chart' by describing the prerequisite use case.
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 explains when to use this tool ('before calculating a natal chart when only the city name is known'), which provides clear context. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tool is the only alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v1.0.8- First observed
astrology_calculate_natal_chart - First observed
astrology_get_coordinates
TDQS
Each tool has a clearly distinct purpose: one calculates a natal chart, the other converts a location to coordinates for input; no ambiguity.
Both tools follow the 'astrology_verb_noun' pattern consistently, making the naming predictable and clear.
Two tools is minimal for the domain of astrology; while the server may be scoped narrowly, a typical user might expect additional tools like transit or synastry calculations, making it borderline.
The server covers the essential steps for natal chart calculation (coordinates + chart), but lacks tools for interpretation, aspects analysis, or other astrological functions, leaving minor gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Western, Vedic, and Chinese astrology calculations, charts, forecasts, and geocoding.
30 Vedic Jyotish tools: natal charts, dashas, yogas, nakshatras. Swiss Ephemeris.
Sub-arcsecond ephemeris and astrology on NASA JPL DE440: natal, transits, eclipses, Human Design.
Western natal charts, horoscopes, transits and synastry for AI agents, verified vs NASA JPL.
Related MCP Servers
- FlicenseNot gradedqualityNot gradedmaintenanceCalculates Chinese BaZi (Four Pillars of Destiny) charts based on birth date, time, and location, including solar term information, decade luck cycles, and true solar time corrections.2-
- FlicenseAqualityDmaintenanceProvides astronomical calculations using the Swiss Ephemeris library, including planetary positions, houses, chart points, and asteroids for any date and location.48-
- AlicenseNot gradedqualityDmaintenanceCalculates astrological birth charts including planetary positions, house placements, and aspects based on birth date, time, and location.7141MIT
- AlicenseNot gradedqualityBmaintenanceHigh-precision astrology tools for LLM agents, including natal charts, transits, progressions, synastry, and more, backed by Swiss Ephemeris.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/intellecat/astrology-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server