VedAstro: a C# Vedic astrology engine with an API, MCP server and Python library

What VedAstro computes, and who the output is for

VedAstro is a non-profit, open source project whose stated goal is to make Vedic Astrology easily available to all. The repository is a C# solution, VedAstro.sln, and the README splits its surface into three audiences. The first is end users, who get browser tools: Horoscope for a full birth chart with 100+ Vedic predictions and divisional charts, Match Checker for marriage compatibility via 10 classical Kuta methods, Match Finder for ranking compatibility across a list of people, Horary for Prashna astrology, Numerology, Birth Time Finder for rectifying uncertain birth times, and Now Astrology / Panchang for live planetary positions and the daily Panchang. The second audience is developers, who get a REST API advertised at 200+ astrology calculation endpoints, a .NET library published as VedAstro.Library on NuGet, a Python package installed with pip install VedAstro, a Docker image at vedastro/api, and an MCP server for AI clients. The third is machine learning and research, served by two Hugging Face datasets of 15,000 famous people covering birth data and marriage or divorce information.

The API payload is the part worth reading closely, because it defines the vocabulary of everything else. A sample response for the Sun at a given time and place returns a flat key-value structure. Some entries come straight from the Swiss Ephemeris, such as Longitude, Latitude, DistanceAU and SpeedLongitude. Others are classical strength values: ShadbalaPinda, SthanaBala, KalaBala, DigBala, ChestaBala, NaisargikaBala, DrikBala, AyanaBala. A third group is categorical: Sign, Constellation, Navamsa, Drekkana, Saptamsa, Dwadasamsa, and booleans such as Exalted, Debilitated, Benefic, Malefic, InKendra. If you have read a Vedic astrology text, these names will be familiar; if you have not, the payload is effectively a glossary with numbers attached.

That mix is the project's real character. It is not a chart drawing library with a thin API on top. It is a calculation engine that emits the intermediate quantities an astrologer would reason with, and the website pages are one consumer of that engine rather than the product itself.

How the calculation stack is organised in the repository

The top-level layout tells you where the boundaries are. Library/ holds the reusable code, and the README points developers at Library/Logic/Calculate as the place to learn the exact math and logic, describing it as free open source code. That directory is the honest entry point for anyone who wants to check how a value is derived rather than trust the output. LibraryTests/ sits beside it for the test project. API/ is the service layer, APITester/ exercises it, and Console/ and Desktop/ are alternative front ends. Website/ and Website_Mobile/ are the public sites, and VedAstro.sln ties the C# projects together.

Several top-level directories are not part of the runtime stack at all. DocToEmbeddings/, LLMCoder/ and MatchMLPipeline/ point at machine learning work: document embedding, an LLM component and a match pipeline. WebScraper/ and MigrateGeoLocationData/ suggest the project has had to acquire and relocate geographic data, which matters because every calculation needs a place as well as a time. StaticTableGenerator/ implies some lookup tables are generated rather than hand-written. HuggingFace/ is presumably the publishing side of the two datasets.

The dependency that shapes everything is Swiss Ephemeris, listed in the repository topics as swisseph and visible in the sample payload as the SwissEphemeris field. Planetary positions in Vedic astrology are sidereal, so the engine has to convert from the astronomical positions the ephemeris returns to the sidereal frame, and the payload exposes both: SayanaLongitude and SayanaLatitude alongside NirayanaLongitude. That pair is the clearest single piece of evidence about how the system works. The ephemeris produces tropical coordinates, and the library applies ayanamsa to reach the sidereal values that the rest of the calculations depend on.

Calling the VedAstro REST API from a script

The fastest way to see real output is the hosted REST API. The README's own example URL follows a path-style pattern with the entity, the location and the time embedded in the route rather than passed as query parameters. The README shows the call as:

https://vedastroapi.azurewebsites.net/api/Calculate/AllPlanetData/PlanetName/Sun/Location/Singapore/Time/00:00/24/04/2024/+08:00

Read the segments literally: Calculate selects the calculation family, AllPlanetData selects the result set, then PlanetName/Sun, Location/Singapore and Time/00:00/24/04/2024/+08:00 supply the inputs. The time segment carries a UTC offset, which is what you would expect from an engine that has to place a moment on a globe. The response is the flat JSON object described earlier, with a Payload key holding fields such as Sign, Constellation, ShadbalaPinda and NirayanaLongitude. If your request returns an error rather than that object, the first thing to check is the route shape, since every input is positional and a missing segment changes the meaning of the path.

The README also links an API Builder page and a video guide, and there is a JavaScript demo directory under Demo/JavaScript in the repository. Those are the places to look for the exact spelling of other endpoints. The project states there are 200+ calculation endpoints, but the README shows only this one example, so treat the builder as the reference rather than guessing at route names.

Using the VedAstro Python package and the MCP server

If you would rather not hand-roll HTTP calls, the Python package is the shortest path. The README gives the install line as:

pip install VedAstro

The README lists the package as VedAstro on PyPI and gives no further usage example, so the package's own documentation is where the call signature has to come from. The same gap applies to the .NET side: VedAstro.Library is published on NuGet, and the README's advice for that route is to import VedAstro code directly into an existing project by building on top of the Library/ directory. Neither the NuGet page nor the README section reproduced here shows a code sample, so a .NET developer should expect to read the source in Library/ before writing the first call.

The MCP server is the newest integration surface. The README gives its endpoint as https://mcp.vedastro.org/api/mcp and says it plugs VedAstro tools into Claude, Cursor, VS Code and any MCP client, with documentation in Docs/MCPServer.MD. For an AI client you configure that URL as a remote MCP server; the client then discovers the available tools and calls them. What the README does not say is which tools are exposed or whether the server requires authentication, so the document in Docs/MCPServer.MD is the thing to read before wiring it into an assistant that will be used by other people.

Where VedAstro gets thin: self-hosting and documentation

The Docker image at vedastro/api is offered as a way to self-host the full API stack, and that is the point where the README stops being useful. It does not give a docker run command, a compose file, a port, an environment variable or a volume. It does not say whether the image expects a Swiss Ephemeris data directory to be mounted, even though the ephemeris is central to every calculation. A reader who wants an offline or air-gapped deployment has to reconstruct the setup from the Docker Hub page and the repository, and the repository layout alone does not settle it: API/, Website/ and Library/ are separate projects in one solution, so which of them the image contains is not stated.

The second thin area is input handling. Every calculation needs a date, a time and a location, and the location in the sample route is a bare place name, Singapore. That is convenient, but the presence of MigrateGeoLocationData/ and WebScraper/ in the repository suggests the geographic dataset has been moved and rebuilt at least once, which is the kind of maintenance that shows up as a changed result rather than an error. Nothing in the README describes how coordinates are resolved, what happens with ambiguous names, or how historical time zone offsets are handled. If your application depends on birth times from before standardised time zones, that is a question for the source code, not the documentation.

A third limit is scope. The README describes an Earthquake Predictor as experimental astrological seismic forecasts. Whatever you think of that, it is labelled experimental in the project's own words, and it is not something to build a dependent service on.

VedAstro compared with the Swiss Ephemeris libraries underneath it

The obvious alternative is to use a Swiss Ephemeris binding directly, through the pyswisseph package in Python or the SwissEphNet port in .NET, and compute the Vedic layer yourself. The difference is where the work sits. A raw ephemeris gives you planetary longitudes, latitudes, distances and speeds, plus house cusps if you ask for them. It does not know what a Navamsa is, what Shadbala means, or which of the ten Kuta methods you want for a compatibility score. VedAstro's value is that whole second layer: the divisional charts, the strength calculations and the classical category flags are already implemented and named.

The cost of that convenience is control. With a raw ephemeris you choose the ayanamsa, the node type, the house system and the rounding, and you can reproduce a result years later because the inputs are explicit. With VedAstro those choices are made inside Library/Logic/Calculate, and the API exposes the output rather than the settings. The sample payload shows both SayanaLongitude and NirayanaLongitude, which is more transparency than many astrology APIs offer, but it does not show which ayanamsa produced the sidereal value. If your requirement is to match an existing astrologer's software to the arcsecond, a direct ephemeris binding plus your own layer is the more defensible path.

The second alternative is the hosted commercial astrology API. Those typically sell a fixed set of endpoints with a support contract and rate limits. VedAstro is MIT-licensed and non-profit, which removes the licensing question and the bill, but it also means the API is a shared service with no stated SLA. For a hobby project or an internal tool that is a fine trade. For a product where an outage is a customer-visible incident, it is not.

Licence, maintenance and what an upgrade costs you

The repository is MIT-licensed, with the licence text in LICENSE.md. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice travel with it. That covers the Library/ code and the API if you self-host. It does not automatically cover the Swiss Ephemeris data files that the engine depends on, and the repository does not state how those are licensed or whether the Docker image bundles them. Anyone redistributing a self-hosted build should confirm the ephemeris terms separately rather than assume MIT covers the whole stack. This is a factual boundary, not legal advice.

The last push to the repository was on 2026-08-13, roughly five weeks before this writing, so the project is being changed. The absence of retrieved releases is worth noting: there are no tagged releases in the README, which means version pinning has to happen against commit hashes or against the published package versions on NuGet and PyPI rather than against repository tags. For the Python and .NET packages that is normal enough, since those registries carry their own version numbers, but it does mean the API and the libraries can drift apart without a release note to mark the change.

Upgrade cost is concentrated in one place: the payload. The sample response is a flat map of string values, and consumers that read it as a dictionary are insulated from added fields, while consumers that deserialise into a strict class are not. The API/, APITester/ and LibraryTests/ projects in the repository are where a breaking change would show up first, so a team that depends on a specific field should watch those directories rather than the README.

Editorial conclusion

Adopt VedAstro if you need Vedic chart data inside an application and are willing to consume it through the hosted REST API, the VedAstro.Library NuGet package or pip install VedAstro rather than building the whole solution. Do not adopt it if you need a fully documented, reproducible self-hosted deployment, because the README points at a Docker image without describing how the API, website and library components fit together at runtime. Before committing, verify three things: that the endpoint you need exists among the 200+ calculation routes, that the returned payload shape matches what your code expects, and that the MIT licence terms suit how you intend to redistribute the output.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. VedAstro/VedAstro on GitHub