# io.github.arthiqlabs/vedaksha-vedic-astrology (oci · ghcr.io/arthiqlabs/vedaksha-mcp) Vedic astrology and astronomical ephemeris: kundali, panchanga, dashas, vargas, transits - Trust score: 37/100 (low) - Change this week: +4 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-11-05 ## Components - oci · `ghcr.io/arthiqlabs/vedaksha-mcp`: 37/100 (this document), [markdown](https://verifymcp.io/servers/arthiqlabs-vedaksha-vedic-astrology/ghcr-io-arthiqlabs-vedaksha-mcp.md), [page](https://verifymcp.io/servers/arthiqlabs-vedaksha-vedic-astrology/ghcr-io-arthiqlabs-vedaksha-mcp) ## Channel facts - Registry: `oci` - Package: `ghcr.io/arthiqlabs/vedaksha-mcp` - Version: `v10.2.0` - Transport: `stdio` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-11-05. - **Supply Chain Security**: 0/100 - No malware scan is available for this kind of package: the supply-chain vendors we use do not cover it. This is a permanent gap in our coverage, not a finding about the package. - Known CVEs could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read. - Install-script risk not yet assessed. - Dependency health could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read. - **Provenance & Transparency**: 35/100 - Source repository is publicly reachable at the declared URL. - Provenance check failed: no build-provenance attestation is published. - License check failed: no license is declared. - Actively maintained (last published 3 days ago). - Publishes a security disclosure policy (SECURITY.md). - **Schema Quality & AI Usability**: 57/100 - AI-judged instruction clarity (excellent). - Context-footprint check failed: tool/resource definitions use about 8119 tokens (~477/item across 17 items; 17 tools + 0 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 33/100 - Stability observed for 10 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 100/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 100% of tool parameters carry a description. - Structured output schemas are declared (94% of tools); any adoption earns full credit. - **Tool Safety**: 100/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - We read all 17 captured tool definition(s), and no name or description among them implies an irreversible operation. - An AI judge read all 17 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 20/100 - Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28. **Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm. ## Install ### How do I install the io.github.arthiqlabs/vedaksha-vedic-astrology MCP server? io.github.arthiqlabs/vedaksha-vedic-astrology runs locally as a container image, launched with docker run --rm -i ghcr.io/arthiqlabs/vedaksha-mcp:v10.2.0 --stdio. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation. ### Claude ```bash claude mcp add arthiqlabs-vedaksha-vedic-astrology -- docker run --rm -i ghcr.io/arthiqlabs/vedaksha-mcp:v10.2.0 --stdio ``` ### Cursor ```json { "mcpServers": { "arthiqlabs-vedaksha-vedic-astrology": { "command": "docker", "args": [ "run", "--rm", "-i", "ghcr.io/arthiqlabs/vedaksha-mcp:v10.2.0", "--stdio" ] } } } ``` ### VS Code ```json { "servers": { "arthiqlabs-vedaksha-vedic-astrology": { "command": "docker", "args": [ "run", "--rm", "-i", "ghcr.io/arthiqlabs/vedaksha-mcp:v10.2.0", "--stdio" ] } } } ``` ### Codex ```bash codex mcp add arthiqlabs-vedaksha-vedic-astrology -- docker run --rm -i ghcr.io/arthiqlabs/vedaksha-mcp:v10.2.0 --stdio ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "arthiqlabs-vedaksha-vedic-astrology": { "type": "local", "command": [ "docker", "run", "--rm", "-i", "ghcr.io/arthiqlabs/vedaksha-mcp:v10.2.0", "--stdio" ], "enabled": true } } } ``` ### Hermes ```yaml mcp_servers: arthiqlabs-vedaksha-vedic-astrology: command: "docker" args: ["run", "--rm", "-i", "ghcr.io/arthiqlabs/vedaksha-mcp:v10.2.0", "--stdio"] ``` ### Netclaw ```json { "McpServers": { "arthiqlabs-vedaksha-vedic-astrology": { "Transport": "stdio", "Command": "docker", "Arguments": [ "run", "--rm", "-i", "ghcr.io/arthiqlabs/vedaksha-mcp:v10.2.0", "--stdio" ] } } } ``` ### Other ```json { "mcpServers": { "arthiqlabs-vedaksha-vedic-astrology": { "command": "docker", "args": [ "run", "--rm", "-i", "ghcr.io/arthiqlabs/vedaksha-mcp:v10.2.0", "--stdio" ] } } } ``` ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-11-05 (score 37, +1) No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-11-03 (score 36, +1) No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-11-01 (score 35, +1) - [security regression] Tool safety: pass → unverified - [security regression] Stability: 0.17 → unverified - [functional regression] Capabilities: fail → unverified - [functional regression] Tool coverage: 100 → unverified - [functional] First check of Schema quality: unverified - [functional] Package version: v10.0.2 → v10.2.0 - [functional] Package version: v10.0.2 → v10.1.0 ### 2026-10-30 (score 34, +1) No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-28 (score 33, +1) No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-26 (score 32) First indexed and scored. ## MCP tools (17) ### `compute_natal_chart` (~715 tokens) Compute a natal astrological chart for a given time and location. Returns JSON with each body's longitude, latitude, speed, sign, house, dignity and retrograde flag, the house cusps with ascendant and MC, the aspects, and the ayanamsha applied. Pass a sidereal ayanamsha for a Vedic chart (kundali); the default is tropical. To get a property graph, pass this output to emit_graph. Input parameters: - `ayanamsha` (string): Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayana… - `house_system` (string): House system: Placidus, Koch, Equal, WholeSign, etc. - `julian_day` (number, required): Julian Day number in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms (planetary positions, nutation, obliquity) and evaluates the Earth-rotation t… - `latitude` (number, required): Geographic latitude in degrees [-90, +90] - `longitude` (number, required): Geographic longitude in degrees [-180, +180], east positive Output parameters: - `aspects` (array) - `config_summary` (string): One-line record of the ephemeris, house system and ayanamsha used. - `houses` (object) - `julian_day` (number): The Julian Day the chart was cast for, echoed back. - `planets` (array): One entry per computed body. - `true_ayanamsha_value` (number): True ayanamsha (mean plus nutation in longitude) applied, in degrees. Zero for a tropical chart. ### `compute_dasha` (~1291 tokens) Compute Vedic dasha (planetary period) sequences. Supports eight classical systems: Vimshottari, Ashtottari, Yogini (Moon-longitude based, require `moon_longitude`); Chara, Narayana (sign based, require BOTH `lagna_sign` AND `graha_signs`, since each sign's period length is counted to the sign its lord occupies in this chart); Sthira, NiryanaShoola (`niryana_shoola` is accepted too) and Maheshwara (Jaimini rashi dashas, require `lagna_sign` AND `graha_longitudes`, since the atmakaraka and the tie-breaks of the strength tests read degrees). `graha_signs` takes the eight `sign_index` values compute_natal_chart already returns, `graha_longitudes` the eight sidereal longitudes; Ketu is derived from Rahu and must not be supplied. Yogini takes `rounds` (1 to 10 whole 36-year rounds) or `until` (a horizon Julian Day); Chara takes `antardashas` (twelve per period, BPHS 51.5-51.9). Sthira, NiryanaShoola and Maheshwara use the defaults of the vedic crate's dasha functions (see their module docs) and always carry their antardashas. Sthira and Maheshwara start from the Brahma graha; a chart whose marks leave none returns `no_brahma: true` with a message, not an error. Returns a JSON dasha tree with start/end Julian Days. For Vimshottari, Ashtottari and Yogini the first maha opens at birth with `initial_balance` of its length, but its sub-periods keep their full shares from the maha's notional start before birth: those with end_jd <= birth_jd ended before birth, and the one running at birth starts at or before it. Input parameters: - `antardashas` (boolean): Chara only: when true each of the twelve periods carries its twelve antardashas in `antar` (BPHS 51.5-51.9: the stronger of the dasha rashi and its seventh starts, by modality, a twelfth of the perio… - `birth_jd` (number, required): Birth Julian Day used as the dasha epoch, in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day. This epoch is only added to, never converted: every retur… - `graha_longitudes` (object): Sidereal longitudes in degrees [0, 360) of the seven classical grahas plus Rahu, as compute_natal_chart serves them (Rahu from its MeanNode). Required, with lagna_sign, for Sthira, NiryanaShoola and… - `graha_signs` (object): Natal sign positions of the seven classical grahas plus Rahu, 0-11 each (0 = Aries), as served by compute_natal_chart's sign_index. Required for Chara, Narayana, whose period lengths are chart-depend… - `karaka_scheme` (string): Which chara karakas name the atmakaraka for Sthira and Maheshwara: "7" (Sun to Saturn) or "8" (adds Rahu), as compute_karakas takes it. Applies to those two systems only. - `lagna_sign` (integer): Lagna (ascendant) sign 0–11 (0 = Aries). Required for Chara, Narayana, Sthira, NiryanaShoola, Maheshwara. This is the same 0-indexed convention compute_natal_chart, compute_bhavas and compute_vargas… - `levels` (integer): Number of nested dasha levels (1–5). Ignored by the sign-based systems (Chara, Narayana, Sthira, NiryanaShoola, Maheshwara). - `moon_longitude` (number): Natal Moon sidereal longitude in degrees [0, 360). Required for Vimshottari, Ashtottari, Yogini. - `rounds` (integer): Yogini only: how many whole 36-year rounds of the cycle to produce. Round 1 is the round from birth, whose first maha is the birth yogini's unelapsed share; each later round runs all eight yoginis wh… - `system` (string): Dasha system selector - `until` (number): Yogini only: a horizon as a Julian Day (UT1). Whole rounds are produced until the tree reaches it, at least one and at most the maximum of `rounds`; compare the last maha's end_jd with it to see whet… ### `compute_karakas` (~262 tokens) Compute Jaimini Chara Karaka assignments from sidereal planet longitudes. Ranks planets by degrees within their current sign: highest = Atmakaraka (soul significator), lowest = Darakaraka (spouse significator). Supports 7-karaka (Sun–Saturn) and 8-karaka (adds Rahu) schemes. Input parameters: - `jupiter` (number, required): Sidereal longitude of Jupiter [0, 360) - `mars` (number, required): Sidereal longitude of Mars [0, 360) - `mercury` (number, required): Sidereal longitude of Mercury [0, 360) - `moon` (number, required): Sidereal longitude of Moon [0, 360) - `rahu` (number): Sidereal longitude of Rahu [0, 360). Required for scheme '8'. - `saturn` (number, required): Sidereal longitude of Saturn [0, 360) - `scheme` (string): Karaka scheme: '7' (default, Sun–Saturn) or '8' (adds Rahu + Pitrikaraka) - `sun` (number, required): Sidereal longitude of Sun [0, 360) - `venus` (number, required): Sidereal longitude of Venus [0, 360) Output parameters: - `karakas` (array): One entry per graha, ordered by rank. ### `compute_combustion` (~702 tokens) Compute combustion state for each planet relative to the Sun: principle per BPHS Ch.7 vv.28-29, orbs per Surya Siddhanta IX.6-8 and X.1 (Moon 12, Mars 17, Mercury 14 or 12 retrograde, Jupiter 11, Venus 10 or 8 retrograde, Saturn 15 deg). Returns Combust, DeeplyCombust, or None for Moon, Mars, Mercury, Jupiter, Venus, Saturn with degrees of separation. This is a low-level tool over already-known positions, not a natal-chart tool: call compute_natal_chart first and pass its planets[].longitude (matched by planets[].name) and planets[].retrograde values straight through as this tool's inputs — do not recompute or re-derive them. Input parameters: - `jupiter` (number, required): Sidereal longitude of Jupiter [0, 360). From compute_natal_chart's planets[] entry where name == "Jupiter", field longitude. - `jupiter_retrograde` (boolean): True if Jupiter is retrograde. Accepted for symmetry; Jupiter's orb is 11 deg either way, so this does not change the result. From compute_natal_chart's Jupiter entry, field retrograde. - `mars` (number, required): Sidereal longitude of Mars [0, 360). From compute_natal_chart's planets[] entry where name == "Mars", field longitude. - `mars_retrograde` (boolean): True if Mars is retrograde. Accepted for symmetry; Mars's orb is 17 deg either way (Surya Siddhanta IX.6 gives it no retrograde figure), so this does not change the result. From compute_natal_chart's… - `mercury` (number, required): Sidereal longitude of Mercury [0, 360). From compute_natal_chart's planets[] entry where name == "Mercury", field longitude. - `mercury_retrograde` (boolean): True if Mercury is retrograde, which narrows its combustion orb from 14 deg to 12 deg (Surya Siddhanta IX.8). From compute_natal_chart's Mercury entry, field retrograde. - `moon` (number, required): Sidereal longitude of Moon [0, 360). From compute_natal_chart's planets[] entry where name == "Moon", field longitude. - `saturn` (number, required): Sidereal longitude of Saturn [0, 360). From compute_natal_chart's planets[] entry where name == "Saturn", field longitude. - `saturn_retrograde` (boolean): True if Saturn is retrograde. Accepted for symmetry; Saturn's orb is 15 deg either way, so this does not change the result. From compute_natal_chart's Saturn entry, field retrograde. - `sun` (number, required): Sidereal longitude of Sun [0, 360). From compute_natal_chart's planets[] entry where name == "Sun", field longitude. - `venus` (number, required): Sidereal longitude of Venus [0, 360). From compute_natal_chart's planets[] entry where name == "Venus", field longitude. - `venus_retrograde` (boolean): True if Venus is retrograde, which narrows its combustion orb from 10 deg to 8 deg (Surya Siddhanta IX.7). From compute_natal_chart's Venus entry, field retrograde. Output parameters: - `states` (array): One entry per graha other than the Sun. ### `compute_shadbala` (~1141 tokens) Compute the complete six-fold Shadbala of the seven grahas (Sun to Saturn) for a birth moment and place, per BPHS Ch.27, with Ishta and Kashta Phala per Ch.28, in virupas. Pass the moment and the place; the tool casts the chart itself and reads sunrise, sunset and the next sunrise from the engine. Every part is in the output, each in its own field: Sthana (uccha, saptavargaja, ojhayugma, kendradi, drekkana), Dig (continuous, the arc from the weak cusp over 3, 27.7), Kala (nathonnata, paksha, tribhaga, abda, masa, vara, hora, ayana and yuddha, which is signed), Cheshta (the cheshta kendra for Mars to Saturn, the Sun's ayana and the Moon's paksha bala, 27.18 and 27.24-25), Naisargika and Drik (a quarter of the benefic sphuta drishti added, a quarter of the malefic taken away, the aspect of Mercury and Jupiter added whole, 27.19; it can be negative or pass 60). The Sun's ayana and the Moon's paksha bala are counted once in kala and once in cheshta, each undoubled. The rules are the verses' defaults; the benefic and malefic grahas are those of BPHS 3.11, with Rahu (the mean node) and Ketu counting only as malefic company for Mercury. Each graha also carries its motion state (vakra, anuvakra, ... atichara, 27.21-23) against the mean geocentric motion; it is reported beside the strengths and is not part of any total. The Sun must both rise and set at the place: in the polar day or night there is no Hindu day to divide into thirds and horas, and the call fails by name. Input parameters: - `ayanamsha` (string, required): Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayana… - `elevation_m` (number): Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise and sunset. - `house_system` (string): House system whose first, fourth, seventh and tenth cusps Dig Bala is measured from, and whose house placements give Kendradi Bala: Placidus, Koch, Equal, WholeSign, etc. The same names compute_natal… - `julian_day` (number, required): Julian Day number in UT1 (Universal Time) — not TT, not TDB, i.e. the same scale as compute_natal_chart's julian_day. - `latitude` (number, required): Geographic latitude in degrees, north positive. The Hindu day is reckoned from this place's sunrise. - `longitude` (number, required): Geographic longitude in degrees, east positive. - `tz_offset_minutes` (integer): Offset of the observer's civil clock from UT, in minutes, in [-720, 840] (UTC-12:00 to UTC+14:00). Names the calendar date of the sunrise that begins the Hindu day, from which the lords of the year,… Output parameters: - `cusps` (object): The four angular cusps Dig Bala is measured from, sidereal degrees. - `house_system` (string): The house system requested. When `polar_fallback` is true it was undefined at this latitude, and the cusps and house placements come from the fallback the natal chart uses. - `julian_day` (number): The Julian Day (UT1) the strengths were computed for, echoed back. - `moment` (object): The birth moment Kala Bala was reckoned from. Every instant is a Julian Day (UT1). - `planets` (array): The seven grahas, Sun to Saturn, in the order Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn. All strengths are in virupas. - `polar_fallback` (boolean): True when the requested house system was undefined at this latitude and a fallback was used, so Dig Bala and Kendradi Bala are read from the fallback's cusps and houses. - `true_ayanamsha_value` (number): True ayanamsha (mean plus nutation in longitude) applied, in degrees. ### `compute_vargas` (~925 tokens) Compute Vedic divisional charts (vargas). Given a time and place, returns one chart per requested division: the varga lagna, and for each of the ten bodies compute_natal_chart returns — the seven grahas plus the mean, true and osculating lunar node — its rashi longitude, the sign it occupies within that varga, its dignity in that sign, and its whole-sign bhava counted from the varga lagna. Ketu is not listed separately: it is the node's opposite point, 180 degrees away. The nodes carry no dignity, so that field is absent for them. Supply planet_longitude instead to divide a single longitude without an ephemeris lookup, in which case no graha name, dignity or bhava is returned because none is defined. Vargas are classically read on a sidereal zodiac: pass an ayanamsha, or accept the Tropical default this surface uses everywhere. Source: BPHS Ch. 6-7. Input parameters: - `ayanamsha` (string): Sidereal zodiac system. Eleven systems, each derived forward from a primary source and none tuned to match another implementation. The chart's true_ayanamsha_value output field reports the TRUE ayana… - `divisions` (array, required): Varga division codes to compute, e.g. ["D1", "D9", "D10"] - `julian_day` (number, required): Julian Day number in UT1 (Universal Time) — not TT, not TDB. Same scale as compute_natal_chart's julian_day: the engine converts to TT internally for the dynamical terms and uses UT1 directly for the… - `latitude` (number, required): Geographic latitude in degrees [-90, +90] - `longitude` (number, required): Geographic longitude in degrees [-180, +180], east positive - `planet_longitude` (number): Sidereal longitude of a single body in degrees [0, 360). When supplied, only this longitude is divided and no ephemeris is consulted; the result carries no graha name, dignity or bhava. - `tradition` (string): Which Parashari reading to use where the texts diverge. 'modality' (default) starts the division from a movable/fixed/dual sign; 'element' starts it from a fire/earth/air/water sign. This changes D16… Output parameters: - `julian_day` (number): The Julian Day the vargas were computed for, echoed back. - `tradition` (string): The tradition actually used: 'modality' or 'element'. - `true_ayanamsha_value` (number): True ayanamsha (mean plus nutation in longitude) applied before dividing, in degrees. Zero when Tropical. - `vargas` (array): One entry per requested division, in the order requested. ### `emit_graph` (~204 tokens) Turn a chart into a queryable property graph. Accepts the output of compute_natal_chart directly (pass latitude and longitude alongside it), or an existing ChartGraph. Emits Neo4j Cypher, SurrealDB SurrealQL, JSON-LD, plain JSON, or RAG embedding text. Input parameters: - `chart_json` (object, required): Either the output of compute_natal_chart ({planets, houses, aspects, ...}), which is converted to a graph here, or an existing ChartGraph ({nodes, edges, chart_id, classification}) - `classification` (string): Optional label or session ID attached to emitted nodes - `format` (string, required): Target output format - `latitude` (number): Observer latitude, degrees north. Required when chart_json is a computed chart; a chart result does not record where it was cast. Ignored for an existing ChartGraph. - `longitude` (number): Observer longitude, degrees east. Required when chart_json is a computed chart. ### `compute_transit` (~169 tokens) Compute transiting planet positions relative to a natal chart at a specific moment. Returns planet longitudes for the transit time alongside natal positions, enabling aspect calculation between transit and natal placements. Input parameters: - `natal_jd` (number, required): Julian Day of the natal chart in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms. - `natal_lat` (number, required): Natal geographic latitude in degrees [-90, +90] - `natal_lon` (number, required): Natal geographic longitude in degrees [-180, +180], east positive - `transit_jd` (number, required): Julian Day of the transit moment to compute, in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms. Output parameters: - `natal_jd` (number): Julian Day of the natal chart, echoed back. - `natal_positions` (array): Natal positions used for the comparison. - `transit_jd` (number): Julian Day of the transit moment, echoed back. - `transit_natal_aspects` (array) - `transit_positions` (array): Positions at the transit moment. ### `search_transits` (~224 tokens) Search for transiting planet–natal planet aspects within a time window. Supply natal positions and a Julian Day range; receive a list of exact transit moments with aspect type, orb, and applying/separating status. Input parameters: - `aspects` (array): Aspect types to filter (e.g. conjunction, opposition, trine). Defaults to major aspects. - `bodies` (array): Transiting bodies to include. Defaults to all planets. - `end_jd` (number, required): End of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. - `max_orb` (number): Maximum orb in degrees (default 1.0) - `natal_positions` (array, required): Array of natal planet positions to check transits against - `start_jd` (number, required): Start of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms; each event's exact_jd is returned on this same UT1… Output parameters: - `end_jd` (number): End of the searched window, echoed back. - `event_count` (integer): Number of entries in events. - `events` (array) - `max_orb` (number): Orb the search used, in degrees. - `start_jd` (number): Start of the searched window, echoed back. ### `search_muhurta` (~456 tokens) Search for auspicious time windows (muhurta) within a given period for a geographic location. Returns ranked muhurta candidates with quality scores based on tithi, nakshatra, yoga, karana, and planetary positions. The search window is capped at 30 days (see MUHURTA_SEARCH_RANGE_TOO_LARGE), a scope limit; for a longer horizon, issue several searches. Input parameters: - `elevation_m` (number): Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise, which is what each candidate's vara is reckoned from — at 3650 m (Lhasa) 9.2… - `end_jd` (number, required): End of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The span from start_jd to end_jd must not exceed 30 days. - `latitude` (number, required): Geographic latitude in degrees [-90, +90] - `longitude` (number, required): Geographic longitude in degrees [-180, +180], east positive - `min_quality` (number): Minimum quality score [0.0, 1.0] for muhurta inclusion (default 0.5) - `start_jd` (number, required): Start of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms and uses UT1 directly for sunrise, which each candid… - `tz_offset_minutes` (integer): Offset of the observer's civil clock from UT, in minutes. Names the vara (weekday) reported for each candidate — it does not change which sunrise bounds the vara, only what that vara is called. Defau… Output parameters: - `elevation_m` (number): Elevation used, in metres. - `end_jd` (number): End of the searched window, echoed back. - `latitude` (number): Latitude used, in degrees. - `longitude` (number): Longitude used, in degrees. - `min_quality` (number): Quality floor the search applied. - `result_count` (integer): Number of entries in results. - `results` (array) - `start_jd` (number): Start of the searched window, echoed back. ### `compute_ashtakavarga` (~239 tokens) Compute Bhinna Ashtakavarga (raw bindu tables) and Sarvashtakavarga for all 7 planets from sign positions. Source: BPHS Ch.66 vv.13-68. Trikona/Ekadhipatya Shodhana and Pinda Sadhana are not included. Input parameters: - `jupiter` (integer, required): Sign index of Jupiter (0=Aries…11=Pisces) - `lagna` (integer, required): Sign index of Lagna (Ascendant) - `mars` (integer, required): Sign index of Mars (0=Aries…11=Pisces) - `mercury` (integer, required): Sign index of Mercury (0=Aries…11=Pisces) - `moon` (integer, required): Sign index of Moon (0=Aries…11=Pisces) - `saturn` (integer, required): Sign index of Saturn (0=Aries…11=Pisces) - `sun` (integer, required): Sign index of Sun (0=Aries…11=Pisces) - `venus` (integer, required): Sign index of Venus (0=Aries…11=Pisces) Output parameters: - `sarvashtakavarga` (array): Twelve entries, Aries first. - `tables` (array): One Bhinna Ashtakavarga per graha. ### `compute_gochara` (~265 tokens) Compute Gochara (transit interpretation) for the seven grahas against a natal reference sign per BPHS Ch.29. Returns favourable/unfavourable verdict, house from natal, and raw vedha (obstruction) candidates per planet. The natal reference sign is the caller's choice — typically the natal Moon's sign (Chandra Gochara) or the natal Lagna's sign. Rahu and Ketu are not included. Input parameters: - `jupiter` (integer, required): Transit sign index of Jupiter - `mars` (integer, required): Transit sign index of Mars - `mercury` (integer, required): Transit sign index of Mercury - `moon` (integer, required): Transit sign index of Moon - `natal_reference_sign` (integer, required): Sign index of the natal reference point — natal Moon for Chandra Gochara, natal Lagna for Lagna-based Gochara - `saturn` (integer, required): Transit sign index of Saturn - `school` (string): Exemption profile applied to the raw vedha candidate list - `sun` (integer, required): Transit sign index of Sun (0=Aries … 11=Pisces) - `vedha_table` (string): Vedha pair table source - `venus` (integer, required): Transit sign index of Venus Output parameters: - `entries` (array) ### `compute_panchanga` (~553 tokens) Compute the panchanga — the five limbs of the Vedic almanac — for an instant: tithi (lunar day, with paksha and lord), vara (weekday reckoned from local sunrise, with its lord and the Rahu and Gulika Kalam windows as Julian Days), nakshatra (with pada), yoga (one of the 27 nithya yogas, with degrees remaining), and karana (half-tithi). Takes sidereal longitudes; all returned instants are Julian Days (UT). vara.from_sunrise reports HOW the weekday was reckoned: true means it was taken from an actual local sunrise (the Vedic definition); false means no sunrise exists to reckon from — the polar day or polar night, above about ±66.5° latitude — and the value is the observer's local CIVIL weekday as a documented fallback, which is a different quantity. Check it before presenting the vara at high latitude. vara.rahu_kalam being null is NOT the same signal: the Kalam windows can also be null while from_sunrise is true. Input parameters: - `elevation_m` (number): Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise — at 3650 m (Lhasa) 9.2 minutes earlier, enough to change the vara in that wi… - `jd` (number, required): Julian Day number in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms and uses UT1 directly for sunrise, which the vara is reckoned from; every ret… - `latitude` (number, required): Observer latitude in degrees. Required — the vara is reckoned from local sunrise, so it depends on the observer. - `longitude` (number, required): Observer longitude in degrees, east positive. Required. - `moon` (number, required): Sidereal longitude of Moon [0, 360) - `sun` (number, required): Sidereal longitude of Sun [0, 360) - `tz_offset_minutes` (integer): Offset of the observer's civil clock from UT, in minutes, in [-720, 840] (UTC-12:00 to UTC+14:00). Used only to name the vara's weekday. Output parameters: - `karana` (object) - `nakshatra` (object) - `tithi` (object) - `vara` (object) - `yoga` (object) ### `compute_drishti` (~270 tokens) Compute graha drishti — Vedic sign aspects — for all nine grahas. Unlike Western aspects, drishti is cast from sign to sign and is asymmetric: every graha aspects the 7th from itself, and Mars additionally aspects the 4th and 8th, Jupiter the 5th and 9th, Saturn the 3rd and 10th. Returns each aspect with its graded strength (Full, ThreeQuarter, Half, Quarter) and the house distance. Input parameters: - `jupiter` (number, required): Sidereal longitude of Jupiter [0, 360) - `ketu` (number, required): Sidereal longitude of Ketu [0, 360) - `mars` (number, required): Sidereal longitude of Mars [0, 360) - `mercury` (number, required): Sidereal longitude of Mercury [0, 360) - `moon` (number, required): Sidereal longitude of Moon [0, 360) - `rahu` (number, required): Sidereal longitude of Rahu [0, 360) - `saturn` (number, required): Sidereal longitude of Saturn [0, 360) - `sun` (number, required): Sidereal longitude of Sun [0, 360) - `venus` (number, required): Sidereal longitude of Venus [0, 360) Output parameters: - `aspects` (array) ### `compute_bhavas` (~161 tokens) Compute the whole-sign bhava (house) chart from an ascendant. In the Vedic whole-sign system the entire sign containing the ascendant is the 1st bhava, the next sign the 2nd, and so on — houses do not have cusps within signs. Returns the sign of each of the twelve bhavas with its kendra / trikona / dusthana / upachaya classification, and optionally places supplied grahas into their bhavas. Input parameters: - `ascendant` (number, required): Sidereal longitude of the ascendant [0, 360) - `planets` (object): Optional map of graha name to sidereal longitude, e.g. {"Mars": 200.4}. Each is placed into its bhava. Output parameters: - `houses` (array): Twelve entries in order. - `lagna_sign` (integer): Rashi of the ascendant, 0=Aries … 11=Pisces. - `planets` (array): Empty unless grahas were supplied. ### `compute_synastry` (~342 tokens) Compute synastry — the aspects each graha in one chart makes to each graha in another chart. Every graha in chart A is tested against every graha in chart B (the two charts do not need the same graha names), and each hit is returned with its aspect type, orb in degrees and strength (1.0 at exact, falling linearly to 0.0 at the orb boundary). Orbs are the traditional Lilly values — conjunction, trine and opposition 8°, square 7°, sextile 6°, minors 2° — scaled by orb_factor. Longitudes only: this tool needs no birth time, place or ephemeris. Input parameters: - `aspect_set` (string): 'major' (default) tests the five Ptolemaic aspects; 'all' adds semi-sextile, semi-square, quintile, sesquiquadrate, bi-quintile and quincunx. - `chart_a` (object, required): Map of graha name to sidereal longitude [0, 360) for the first chart, e.g. {"Sun": 10.0, "Moon": 130.0}. - `chart_b` (object, required): Map of graha name to sidereal longitude [0, 360) for the second chart. Need not use the same names as chart_a. - `orb_factor` (number): Multiplier on the default orbs. 1.0 (default) is standard, 0.5 is tight. Must be greater than 0 and at most 5.0, above which the major-aspect windows cover every separation. Output parameters: - `aspects` (array) ### `compute_composite` (~200 tokens) Compute the midpoint composite chart of two charts: for each graha, the shorter-arc midpoint of its longitude in the two charts, and the arithmetic mean of its two speeds. The two charts must carry the SAME graha names — each graha is paired with its namesake, not with whatever happens to sit at the same position in a list — and a name present in one chart but not the other is an error naming that graha. Longitudes only: this tool needs no birth time, place or ephemeris. Input parameters: - `chart_a` (object, required): Map of graha name to position for the first chart, e.g. {"Sun": {"longitude": 350.0, "speed": 1.0}}. `speed` is optional and defaults to 0. - `chart_b` (object, required): Map of graha name to position for the second chart. Must have exactly the same graha names as chart_a. Output parameters: - `planets` (array): One entry per graha present in both charts. ## Diagnostics Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/arthiqlabs-vedaksha-vedic-astrology/ghcr-io-arthiqlabs-vedaksha-mcp#diagnostics ## Score history - 2026-11-05: 37 - 2026-11-04: 36 - 2026-11-03: 36 - 2026-11-02: 35 - 2026-11-01: 35 - 2026-10-31: 34 - 2026-10-30: 34 - 2026-10-29: 33 - 2026-10-28: 33 - 2026-10-27: 32 - 2026-10-26: 32 ## Common questions ### What is the io.github.arthiqlabs/vedaksha-vedic-astrology MCP server? io.github.arthiqlabs/vedaksha-vedic-astrology is an MCP server listed in the public MCP registry as io.github.arthiqlabs/vedaksha-vedic-astrology. Vedic astrology and astronomical ephemeris: kundali, panchanga, dashas, vargas, transits. This page covers its container image (ghcr.io/arthiqlabs/vedaksha-mcp). ### Is the io.github.arthiqlabs/vedaksha-vedic-astrology MCP server safe to use? io.github.arthiqlabs/vedaksha-vedic-astrology scores 37 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm. ### What tools does the io.github.arthiqlabs/vedaksha-vedic-astrology MCP server expose? io.github.arthiqlabs/vedaksha-vedic-astrology exposes 17 tools: compute_natal_chart, compute_dasha, compute_karakas, compute_combustion, compute_shadbala, and 12 more. Their descriptions and schemas cost roughly 8,119 tokens of context every time the server is loaded. ### Is the io.github.arthiqlabs/vedaksha-vedic-astrology MCP server still maintained? io.github.arthiqlabs/vedaksha-vedic-astrology is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced. ### What did VerifyMCP test on the io.github.arthiqlabs/vedaksha-vedic-astrology MCP server? VerifyMCP ran 12 checks on io.github.arthiqlabs/vedaksha-vedic-astrology, covering Source repository, Provenance, License, Maintenance and 8 more. 4 items could not be completed, a gap on our side rather than a finding about io.github.arthiqlabs/vedaksha-vedic-astrology: Malware scan, Known CVEs, Install scripts and Dependency health. One category scores 0 for that reason, because we only credit what we can confirm. Endpoint Security and Transport & Reachability do not apply to a container image, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out. ## Links - GitHub Container Registry: https://ghcr.io/arthiqlabs/vedaksha-mcp - Repository: https://github.com/arthiqlabs/vedaksha - Website: https://vedaksha.net/ - Changelog RSS feed: https://verifymcp.io/servers/arthiqlabs-vedaksha-vedic-astrology/ghcr-io-arthiqlabs-vedaksha-mcp.xml - Changelog JSON feed: https://verifymcp.io/servers/arthiqlabs-vedaksha-vedic-astrology/ghcr-io-arthiqlabs-vedaksha-mcp/changelog.json - Trust report (JSON): https://verifymcp.io/servers/arthiqlabs-vedaksha-vedic-astrology/ghcr-io-arthiqlabs-vedaksha-mcp.json - HTML version of this page: https://verifymcp.io/servers/arthiqlabs-vedaksha-vedic-astrology/ghcr-io-arthiqlabs-vedaksha-mcp