The VedAstro MCP Server provides Vedic astrology computation tools for birth chart analysis, relationship compatibility, and planetary data retrieval.
Get Horoscope (get_horoscope): Generate comprehensive Vedic horoscope predictions using birth date, time, location, and timezone. Covers career, health, relationships, wealth, challenges, rising sign (Lagna), and planetary positions.
Get Match Report (get_match_report): Calculate relationship compatibility between two individuals using the traditional Vedic Kuta matching system. Outputs a compatibility score (0–100) with analysis of emotional harmony, intellectual compatibility, and life goal alignment — useful for marriage or partnership assessment.
Get Planet Data (get_planet_data): Retrieve precise positions of all 9 Vedic planets (Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn, Rahu, Ketu), including zodiac sign, degree within sign (0–30), and absolute ecliptic angle (0–360). Serves as foundational raw data for deeper astrological analysis.
Website — easy & fast astrology data for normal users
AI Astrologer — 🤖 World's 1st open source Vedic AI astrologer
Life Predictor — accurate algorithmic prediction of a human life's past and future
Horoscope — full birth chart with 100+ Vedic predictions & divisional charts
Match Checker — marriage compatibility via 10 classical Kuta methods
Match Finder — find your most compatible partner from a list
Horary — ask a question, get an answer via Prashna astrology
Numerology — accurate Name Numerology using Mantra Shastra
Birth Time Finder — rectify unknown/uncertain birth times
Dream Interpreter — AI-powered dream analysis rooted in Vedic thought
Now Astrology / Panchang — live planetary positions & daily Panchang
Earthquake Predictor — experimental astrological seismic forecasts
Journal — log life events and see them mapped against your chart
MCP Server — plug VedAstro tools into Claude, Cursor, VS Code and any MCP client (docs)
REST API — 200+ astrology calculation endpoints (API Builder)
.NET Library — VedAstro.Library on NuGet
Python Library — pip install VedAstro
Docker Image — self-host the full API stack
WordPress Plugin — drop Vedic widgets into any WP site
Mobile App — Android & iOS clients
Learn Astro Computation — learn the exact math & logic via Free Open Source code
Build On Top — import VedAstro code directly into your existing projects
15,000 Famous People — Birth Data — curated birth date/time/location dataset
15,000 Famous People — Marriage Info — marriage & divorce dataset
The sage Parashara taught everybody the ways of astrology without asking money, as such VedAstro does the same.
Anybody who has studied Vedic Astrology knows well how accurate it can be. But also how complex it can get to make accurate predictions. It takes decades of experience to be able make accurate prediction. As such this knowledge only reaches a limited people. This project is an effort to change that. Read More
The first line of code for this project was written in late 2014 at Itä-Pasila. Started as a simple desktop software, with no UI and only text display. With continued support from users, this project has steadily grown to what it is today. Helping people from all over the world. 🌍
Thanks to B.V. Raman and his grandfather B. Suryanarain Rao for pioneering easy to read astrology books. Credit also goes to St. Jean-Baptiste de La Salle for proving the efficacy of free and open work for the benefit of all men...Read More.
This development style celebrates the methodology of chaotic development at the benefit of low cost and fast paced prototyping. Inspired by the concept of "Gonzo Journalism", pioneered by Hunter S. Thompson in the 1970s.
We favour this pattern for the development of VedAstro simply due to the volatile nature of this project. Other development styles like "Waterfall" and "Scrum" are equally good when the need is.
✅ We want to :
💓 try out novel ideas at a heartbeat
📬 we want the latest platform
💰 we want it cheap
Hence the "gonzo development" pattern is best suited for this needs.
We would like to introduce in this project a novel UX concept called "Drunk Proofing". The idea is simple. All UI is designed to be operated by an alcoholically intoxicated person aka drunk.
Why? Because this forces the team to make a simple and intuitive UI design. It is all too easy during development to make a complicated UI that only coders understand. But it is far more difficult and rewarding to make the UI intuitive & easy. A "no manuals" and "no brainer" approach to design.
The wisdom of ages, once passed down by word, Now stored in circuits, rarely heard.
Once this knowledge was held in minds so keen, Now it's coded in machines unseen.
The human touch, that once gave knowledge birth, Replaced by algorithms, shaping future's girth.
Just Like & Share our social pages and it'll be a big help already!
We discuss & share ideas on astrology and computation. And ways you can integrate VedAstro into your own project.
Philosophy's the scaffold we use when we build, Without it, a mud hut, not a structure fulfilled. For creating grand codes, like VedAstro's design, Philosophy's essential, its role is divine.
The purpose of VedAstro, we must understand, Born of joy, in development it must stand. This project thrives on happiness, pure and bright, Don't code till your heart feels the building's delight.
When your fingers can't keep up, joy fills the air, You'll know that your code is placed right with care. In the universe vast, it finds its own way, Your work shines with brilliance, come what may.
The main part of the program is the prediction/event generator. It works by combining logic on how to calculate a prediction with data about that prediction. This is done everytime a "Calculate" button is clicked. Below you will see a brief explanation of this process. This method was chosen to easily accommodate the thousands of astrological calculation possibilities.
Related MCP server: VedAstro MCP Server
CREATION OF AN EVENT/PREDICTION
STEP 1
Hard coded event data like name is stored in XML file.
A copy of the event name is stored as Enum to link
Calculator Methods with data from XML.
These static methods are the logic to check
if an event occurred. No astro calculation done at this stage.
This is the linking process of the logic and data.
-------+
|
+-----------------+ |
| Event Data (xml)| |
+-----------------+ |
+ |
+------------------+ |
|Event Names (Enum)| +-----> Event Data (Instance)
+------------------+ |
+ |
+------------------+ |
|Calculator Methods| |
+------------------+ |
|
------+
STEP 2
From the above step, list of Event Data is generated.
The occurrence logic of each Event Data is called with time slices,
generated from a start time & end time (entered at runtime).
An Event is created if IsOccuring is true.
This's a merger of Time and EventData to create an
Event at a specific time. This Event is then used
throughout the program.
Event Data + Time Range
List List
|
|
|
v
Event List
+--------+ +------------------------+ +------------------+
| User | <------+ | Website | -------------> | API |
| | +------> | - Blazor WebAssembly | <------------- | -Azure Functions |
+--------+ GUI | - Azure Static WebApp | XML | |
| | | |
+------------------------+ +------------------+all 3 independent, only linked in VS for easy access don't commit local referenced .csproj to Git as it'll be used by CI/CD
Create a method in EventCalculatorMethods.cs
Add the name in EventNames.cs
Add the prediction/event details HoroscopeDataList.xml
Edit in Genso.Astrology.Library EventTag enum. Change here reflects even in GUI
These are randomly ordered notes on why a feature was implemented in a certain way. Will prove usefull when debugging & upgrading code.
Shows only clean & nice html index for bots from best known SEs
for direct access Blazor page via static storage without 404 error since no page actually exists at page url, blazor takes url and runs the page as app using rule engine this is possible rules also make sure not to redirect file & api access only page access
not begins with "/api/"
has a path
Sec-Fetch-Mode = navigate
Sec-Fetch-Dest = document
web : vedastro.org -> domain registra -> azure DNS -> azure cdn -> web blob storage api stable : api.vedastro.org -> domain registra -> azure DNS -> azure cdn -> stable api server (render) api beta : beta.api.vedastro.org -> domain registra -> azure DNS -> azure cdn -> beta api server (azure) domain cert managed by Let's Encrypt ACME bot Azure Function
via Azure CDN Rules Engine, this allows the use of api.vedastro.org/... & api.vedastro.org/nlp/...
Since not documented by BV. Raman, code here is created through experimentation by repeating relationship between Dasa planet & Bhukti planet.
Not all data regarding an event is hardwired. Generating gochara, antaram, sukshma and others is more efficient if the description was created by the astronomical calculator. At the moment EventDataList.xml is the source of truth, meaning if an event exists in xml file, then it must exist in code.
Accessing events chart directly via API generated html
CORS in Azure Website Storage needs to be disabled for this to work, outside of vedastro.org
The default timezone generated for all svg charts will be based on client timezone. Timezone does not matter when full life charts are made, but will matter a lot when short term muhurtha charts are generated. Since most users are not living where they were born, it is only logical to default it client browser's timezone. This timezone must be visible/changeable to users who need to use otherwise.
This feature is to store notes on the dasa report
The notes are actually Events converted to XML and stored inside each person's record
When rendering these events are placed on top dasa report view
The calculations tested on Intel Xeon with parallel processing take about 1GB RAM & 30% CPU. With these loads browsers with mobile CPU's are going to be probelmatic for sure. So as not to waste time, the API route has been decided since it has been proven to work.
There are places where all Astronomical computation is done in client, exp. Planet Info Box
Built on reference to, Hindu Predictive Astrology pg. 254
Asthavarga bindus are different from shadbala and it is to be implemented soon.
Asthavarga bindus are not yet account for, asthavarga good or bad nature of the planet. It is assumed that Shadbala system can compensate for it.
This passage on page 255 needs to be clarified "It must be noted that when passing through the first 10 degrees of a sign, Mars and the Sun produce results."
It's interpreted that Vendha is an obstruction and not a reversal of the Gochara results So as for now the design is that if a vedha is present than the result is simply nullified.
In Horoscope predictions methods have "time" & "person" arguments available, obvioulsy "time" is not needed, but for sake of semantic similarity with Muhurtha methods this is maintained.
Option 1 : generate a high res image (svg/html) and zoom horitontally into it - very fast - image gets blurry
Option 2 : Regenerate whole component in Blazor - very slow - hard to implement with touch screen
Option 3 : Generate multiple preset zooms, than place them on top of each other, and only make visible what is needed via selector - complicated, needs documentation - easy touch screen implimentation - very fast
Thus Option 3 was chosen.
Structs are used to reduce overhead from large collections, exp. List<>
When structs are part of a class, they are stored in the heap. An additional benefit is that structs need less memory than a class because they have no ObjectHeader or MethodTable. You should consider using a struct when the size of the struct will be minimal (say around 16 bytes), the struct will be short-lived, or the struct will be immutable.
default hashing is inconsistent, MD5 is used
many class's get hash overrides still use default hashing (in cache mechanism), could result in errors, needs to be updated
NOTE : all default hashing is instance specific (FOR STRINGS ONLY so far), works as id in 1 environment, but with Client + Server config, hashes become different, needs changing to MD5
In class/struct that only represent data and not computation, use direct property naming without modifiers like "Get" or "Set". Example: Person struct should be "Person.BirthTime" and not "Person.GetBirthTime()"
3 files exist now, azure storage, desktop, wwwroot (TODO delete all but wwwroot)
2 of these files exist, 1 local in MuhurthaCore for desktop version. The other online in VedAstro Azure storage for use by API. Both files need to be in sync, if forgot to sync. Use file with latest update.
Future todo simplify into 1 file. Local MuhurthaCore can be deprecated.
Generally 1 tag for 1 event, add only when needed.
Multiple tags can be used by 1 event, separated by "," in in the Tag element
Done so that event can be accessed for multiple uses. Example, Tarabala Events is tagged for Personal & Tarabala.
Needs to be added with care and where absolutely needed, else could get very confusing.
To all those who say we need money todo good. Jesus said not.
"It is easier for a camel to go through the eye of a needle, than for a rich man to enter the kingdom of God"
Oh so bright, On a Tuesday morning, I'm pondering life, and what's in sight. Is it fear, fate, justice, or a test of might?
From my father's voice rings a resounding insight. Joy of my love, it's your guiding light! All men that have joy, have God, just right, Making love to their sweet wife, there, God's in sight!
When men love their wives, with all their heart, They see a glimpse of God, a work of art. In those precious moments, they see God's might. Yet, swiftly it fades, like a star in the night
When fleeting moments pass, and cries are heard, And we're left to wonder, if joy's been blurred. Chasing worldly delights, may bring us cheer But joy is what lasts, and banishes all fear.
To pursue worldly pleasures, is not quite right, It's short-sighted, like a bat in the daylight. They seek joy, in their ceaseless flight, Forgetting it's joy that makes their wings ignite.
Get comprehensive Vedic horoscope predictions for a birth chart.
Use this tool when an agent needs to analyze a person life path, personality traits, or future predictions based on their birth details. This tool analyzes planetary positions at birth to generate insights across career, health, relationships, wealth, and spiritual growth.
Input: Birth location (latitude/longitude), birth time (HH:MM), birth date (DD/MM/YYYY), and timezone (+HH:MM). Output: A JSON object containing horoscope predictions with career guidance, health insights, relationship compatibility notes, wealth prospects, and challenge areas. Also includes the rising sign (lagna) and planet positions.
Example use case: "Generate a horoscope for someone born on December 31, 2010 at 11:40 PM in Singapore (+08:00).
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Geographic latitude of the birth location in decimal degrees. Positive for North, negative for South. Range: -90 to 90. Example: 1.35 for Singapore, 40.71 for New York. | |
| timezone | Yes | UTC timezone offset in +HH:MM or -HH:MM format. Example: +05:30 for India, +08:00 for Singapore, -05:00 for Eastern US. | |
| longitude | Yes | Geographic longitude of the birth location in decimal degrees. Positive for East, negative for West. Range: -180 to 180. Example: 103.82 for Singapore, -74.00 for New York. | |
| birth_date | Yes | Date of birth in DD/MM/YYYY format. Example: 31/12/2010 for December 31, 2010. | |
| birth_time | Yes | Time of birth in 24-hour HH:MM format. Example: 23:40 for 11:40 PM, 06:30 for 6:30 AM. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description describes the output structure (JSON with career, health, etc.) but lacks information on side effects, authorization needs, or that it is a read-only operation. This is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose, usage context, input format, and output details. It is slightly verbose but efficient, front-loading key information. A minor trim could improve conciseness.
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 lack of output schema, the description fully explains the return values (JSON with career, health, relationships, etc.) and provides an example. It covers all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions. The description lists the inputs in text but adds little beyond the schema, such as the example. Baseline 3 is appropriate as the schema already provides strong semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get comprehensive Vedic horoscope predictions for a birth chart' and differentiates from sibling tools 'get_match_report' and 'get_planet_data' by specifying its scope (life path, personality, future predictions).
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?
It explicitly says 'Use this tool when an agent needs to analyze a person life path...' and provides an example. However, it does not mention when not to use it or offer explicit alternatives, which would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Vedic astrology compatibility report for two people.
Use this tool when an agent needs to assess relationship compatibility, find auspicious times for marriage, or evaluate partnership potential between two individuals based on their birth charts. The tool applies traditional Kuta matching system used in Vedic astrology.
Input: Birth details for both persons (latitude, longitude, birth time, birth date, timezone). Output: A JSON object with a compatibility score (0-100), individual planetary positions for both persons, and a summary of compatibility factors including emotional harmony, intellectual compatibility, and life goals alignment.
Example use case: "Calculate compatibility between two people for marriage planning.
| Name | Required | Description | Default |
|---|---|---|---|
| tz1 | Yes | Person 1 timezone offset in +HH:MM or -HH:MM format. | |
| tz2 | Yes | Person 2 timezone offset in +HH:MM or -HH:MM format. | |
| lat1 | Yes | Latitude of Person 1 birth location in decimal degrees. | |
| lat2 | Yes | Latitude of Person 2 birth location in decimal degrees. | |
| lon1 | Yes | Longitude of Person 1 birth location in decimal degrees. | |
| lon2 | Yes | Longitude of Person 2 birth location in decimal degrees. | |
| date1 | Yes | Person 1 birth date in DD/MM/YYYY format. | |
| date2 | Yes | Person 2 birth date in DD/MM/YYYY format. | |
| time1 | Yes | Person 1 birth time in HH:MM format (24-hour). | |
| time2 | Yes | Person 2 birth time in HH:MM format (24-hour). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses the underlying system (Kuta matching), input requirements, and output structure including compatibility score and factors. Adequate for a non-destructive tool.
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?
Description is well-structured with separate sections for purpose, usage, input, output, and example. Not overly verbose, though could be slightly more concise.
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 no output schema and no annotations, the description fully covers what the tool does, when to use it, required inputs, and expected output fields (score, planetary positions, summary factors). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description lists input categories but adds no additional meaning beyond schema descriptions (e.g., date format, time format already in schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Generate a Vedic astrology compatibility report for two people,' specifying verb, resource, and purpose. Distinguishes from siblings (get_horoscope, get_planet_data) by focusing on relationship compatibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this tool when an agent needs to assess relationship compatibility...' and lists use cases. Does not provide when-not-to-use or compare directly with siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve precise planetary positions for a Vedic birth chart.
Use this tool when an agent needs raw astrological data for a birth chart, such as which zodiac sign each planet occupies, the exact degree within that sign, and the planetary angle from the vernal equinox. This is the foundational data used in detailed chart analysis.
Input: Birth location (latitude/longitude), birth time (HH:MM), birth date (DD/MM/YYYY), and timezone (+HH:MM). Output: A JSON object mapping each of the 9 Vedic planets (Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn, Rahu, Ketu) to their zodiac sign, degree within the sign (0-30), and absolute angle (0-360).
Example use case: "Get planet positions to determine if Mars is in Scorpio for a given birth date.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Geographic latitude of birth location in decimal degrees. Positive for North, negative for South. | |
| timezone | Yes | UTC timezone offset in +HH:MM or -HH:MM format. | |
| longitude | Yes | Geographic longitude of birth location in decimal degrees. Positive for East, negative for West. | |
| birth_date | Yes | Date of birth in DD/MM/YYYY format. | |
| birth_time | Yes | Time of birth in 24-hour HH:MM format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses the read-only nature ('Retrieve'), input format, and output structure. Lacks details on error handling or rate limits, but adequately covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with paragraphs for purpose, usage, input, output, and example. Slightly verbose but front-loaded. 'Retrieve' is a strong verb. Could be tightened, but overall effective.
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?
Explains output format in detail (9 planets, zodiac sign, degree, angle) despite no output schema. All required input parameters covered. Sibling tools sufficiently differentiated. Complete for the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. Description adds value by specifying input formats (e.g., '+HH:MM' for timezone, 'DD/MM/YYYY' for date). This goes beyond schema descriptions, earning above baseline.
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 retrieves planetary positions for Vedic birth charts, listing specific outputs (zodiac sign, degree, angle). It distinguishes from siblings get_horoscope and get_match_report by focusing on raw astrological data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: when raw astrological data is needed. Provides an example use case. Not explicitly saying when not to use, but context from sibling tools implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.3get_horoscopeget_match_reportget_planet_dataScored across 3 tools
Each tool has a clearly distinct purpose: horoscope predictions, compatibility report, and raw planetary data. There is no overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case: get_horoscope, get_match_report, get_planet_data. No deviations.
Three tools cover the core functionalities of Vedic astrology: individual chart analysis, pair compatibility, and raw planetary data. The count feels balanced and well-scoped.
The tool set covers essential Vedic astrology operations. Missing advanced features like transit or Dasha period calculations, but these can be derived from planet data. Minor gap.
Free MCP server: 36 security & dev API tools -- WHOIS, DNS, CVE, IP reputation, Cosmos SDK.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Crypto market intelligence, token rug-checks, and wallet verification in one MCP server.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
