# AstroNest — Vedic Astrology Readings (remote · www.astronest.ai)

Vedic astrology readings for AI agents: life areas, compatibility, business timing, gems, ephemeris.

- Trust score: 91/100 (high trust)
- Change this week: +10
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `www.astronest.ai`: 91/100 (this document), [markdown](https://verifymcp.io/servers/onedotlinks-astronest/api-developer-mcp.md), [page](https://verifymcp.io/servers/onedotlinks-astronest/api-developer-mcp)

## Channel facts

- Endpoint: `https://www.astronest.ai/api/developer/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `1.2.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, 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.

- **Endpoint Security**: 97/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 60/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 7682 tokens (~365/item across 21 items; 21 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 93/100
  - Stability observed for 28 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 (100% 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 21 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 22 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the AstroNest — Vedic Astrology Readings MCP server?

AstroNest — Vedic Astrology Readings is a hosted endpoint at https://www.astronest.ai/api/developer/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http onedotlinks-astronest 'https://www.astronest.ai/api/developer/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "onedotlinks-astronest": {
      "url": "https://www.astronest.ai/api/developer/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "onedotlinks-astronest": {
      "type": "http",
      "url": "https://www.astronest.ai/api/developer/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.onedotlinks-astronest]
url = "https://www.astronest.ai/api/developer/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "onedotlinks-astronest": {
      "type": "remote",
      "url": "https://www.astronest.ai/api/developer/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add onedotlinks-astronest --url 'https://www.astronest.ai/api/developer/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  onedotlinks-astronest:
    url: "https://www.astronest.ai/api/developer/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "onedotlinks-astronest": {
      "Transport": "http",
      "Url": "https://www.astronest.ai/api/developer/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add onedotlinks-astronest -t streamable-http -u 'https://www.astronest.ai/api/developer/mcp'
```

### Other

```json
{
  "mcpServers": {
    "onedotlinks-astronest": {
      "type": "http",
      "url": "https://www.astronest.ai/api/developer/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## 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 91, +1)

No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-03 (score 90, +1)

- [security] The server rewrote its instructions, which are the text every model session reads

### 2026-11-02 (score 89, +7)

- [security improvement] Authorization: partial → pass
- [security] First check of Authorization: pass
- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “get_chart” rewrote its description, which is the text the model reads
- [security] Tool “get_ephemeris_ayanamsa” rewrote its description, which is the text the model reads
- [security] Tool “get_ephemeris_positions” rewrote its description, which is the text the model reads
- [security] Tool “get_prashna” rewrote its description, which is the text the model reads
- [security] Tool “get_techniques” rewrote its description, which is the text the model reads
- [security] Tool “interpret_domain” rewrote its description, which is the text the model reads
- [cosmetic] “get_chart” reworded the description of “divisionals”
- [cosmetic] “get_chart” reworded the description of “includeDasha”
- [cosmetic] “get_prashna” reworded the description of “domain”
- [cosmetic] “get_prashna” reworded the description of “horaryNumber”
- [cosmetic] “get_techniques” reworded the description of “referenceDate”
- [cosmetic] “get_techniques” reworded the description of “residence”
- [cosmetic] Tool “get_dasha” changed its title: Vimśottarī daśā timeline (planetary periods) → Life-period timeline (planetary periods)
- [cosmetic] Tool “get_prashna” changed its title: Praśna (horary): a question, a deal, or a KP number → Praśna (horary): a question, a deal, or a horary number

### 2026-10-31 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-29 (score 81, +1)

No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-27 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-25 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-23 (score 78, +1)

No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (21)

### `get_chart` (~353 tokens)

Natal chart (kundli)

Use this when the user wants their birth chart (kundli): ascendant, planets in signs and houses, yogas, the current planetary periods, or one of the classical sub-charts.
Sidereal chart: ascendant, the nine grahas, twelve houses, yogas and the life-period (daśā) timeline. A modern Western block is added unless `western` is false. With `location`, also astrocartography lines at that place and the chart's own frame relocated there. Includes two classical sub-charts by default; ask for any of the others with `divisionals`.
Cost: 1 credit per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}}

Input parameters:

- `birthData` (object, required): The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude.
- `divisionals` (array): Classical sub-charts to include, by value. Default `d9` and `d10`; send [] for none. Each returns its ascendant and every graha's sign, degree and house within that sub-chart.
- `includeDasha` (boolean): Include the life-period (daśā) timeline in the chart response. Default true.
- `location` (object): Both coordinates or neither: a half-filled location is refused, never defaulted.
- `western` (boolean): Set false to omit the modern Western block.

### `get_dasha` (~226 tokens)

Life-period timeline (planetary periods)

Use this when the user asks which planetary period (daśā) they are in, when it ends, or which periods are coming.
The current periods include the running pratyantardaśā; send depth 'pratyantardasha' for the full timeline at that level.
Cost: 1 credit per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}}

Input parameters:

- `birthData` (object, required): The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude.
- `depth` (string): Timeline depth. 'pratyantardasha' nests the pratyantardaśās under each antardaśā (about ten times larger). The current periods always include the running pratyantardaśā.

### `get_guidance` (~206 tokens)

Guidance for the running daśā periods

Use this when the user asks how to conduct themselves in the period they are in: what to do and what to take care with, each with its classical reason. Guidance, not prediction.
Plain-language guidance cards for each running daśā level (mahādaśā, antardaśā, …) at `referenceDate` (default: now).
Cost: 3 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}}

Input parameters:

- `birthData` (object, required): The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude.
- `referenceDate` (string): ISO date or datetime. Defaults to now.

### `get_techniques` (~459 tokens)

Classical techniques for a chart

Use this when the user or an astrologer asks for a specific classical computation — planetary strength, transit point tables, another life-period timeline, the annual chart, house cusps, a named yoga, the birth pañcāṅga, Manglik, house lords and aspects — rather than for a reading. Pass `sections` to fetch only what is needed.
The computed classical working for a chart, no model: strength scores for each planet and house, point tables for transit support, further life-period timelines with the periods running at `referenceDate`, the full planetary-period ladder, the annual chart for the year running at `referenceDate`, house-cusp and ruling-planet tables, classical yogas, special ascendants and aspects, the natal pañcāṅga, house lords with planetary aspects, Manglik (Kuja doṣa) with its exceptions, and what would change under another ayanāṁśa. Each section is `{computed: true, data}` or `{computed: false, reason}` — a technique that cannot be computed for this chart (for example without a birth time) says why and the rest still return. No verdicts, scores or lifespan figures.
Cost: 3 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"sections":["shadbala","dashas","panchanga"],"referenceDate":"2026-10-14T00:00:00Z"}

Input parameters:

- `birthData` (object, required): The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude.
- `referenceDate` (string): ISO date or datetime for the running periods and the annual chart's year. Defaults to now.
- `residence` (object): Where the person lives; the annual chart is cast for this place. Defaults to the birthplace.
- `sections` (array): Return only these sections. Default: all.

### `get_prashna` (~750 tokens)

Praśna (horary): a question, a deal, or a horary number

Use this when the user asks a specific question and wants it answered from the moment of asking rather than from a birth chart — "will this deal close?", "will I recover?", "will I find what I lost?" — or when an astrologer gives a horary number 1–249. Send where the user is as `place`; it is never defaulted.
The chart of the moment and place a question is asked, read on classical praśna rules, no model. Always: the praśna lagna and its lord, the Moon, the house of the matter asked about, the classical rules that apply (recovery from illness for a health question; recovery of a lost article when the question names one), and the further classical rules that held on this chart, each with its reference and the chart facts that made it hold. With `deal`: the deal praśna — significators (lagna lord = you, 7th = the other side, 10th = the undertaking, 11th = gain), their planetary contacts, the grounds for and against, and an ordered verdict (perfects, perfects after obstacles, contested, delayed, delayed and contested, not perfected); add `birthData` for the natal commitment calendar beside it, never blended with it. With `horaryNumber` (1–249): the horary table — house cusps for the moment that number rises, planets at the moment of judgment, their ruling lords, and the ruling planets; no judgment is asserted from it. Rules about caste, prenatal sex or death timing are withheld and counted.
Cost: 3 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"place":{"latitude":28.6139,"longitude":77.209,"timezone":"Asia/Kolkata","label":"New Delhi"},"askedAt":"2026-10-14T10:30:00+05:30","question":"Will the supply contract with Northwind be signed?","deal":{"label":"Northwind supply contract","kind":"contract","signingDate":"2026-11-02"},"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209…

Input parameters:

- `askedAt` (string): The instant the question was asked, ISO 8601 with Z or an offset. Default: now. Send this or askedAtLocal, not both.
- `askedAtLocal` (string): The wall clock at the place when the question was asked, YYYY-MM-DDTHH:mm, read in place.timezone.
- `birthData` (object): Only with `deal`, and with a birth time: the querent's natal commitment calendar is set beside the praśna for the signing date.
- `deal` (object): Read the question as one deal (the deal praśna).
- `domain` (string): What the question is about: picks the house of the matter and scopes the classical rules. With a deal and no domain, the deal's own.
- `horaryNumber` (integer): A horary number (1–249): adds the horary table.
- `place` (object, required): Where the question is asked. Required: a praśna cast at the wrong longitude is a different chart.
- `question` (string): The question in the user's words. Gates the lost-article dictum; it does not choose the domain.

### `interpret_domain` (~280 tokens)

Reading of one life area

Use this when the user asks what their chart says about one area of life (career, marriage, finance, health, property, children, education, travel, legal and others) and a reproducible verdict with its reasons and sources is wanted. Prefer it to get_forecast when no written narrative is needed.
Deterministic reading of one life area: the verdict, the factors for and against it, timing windows, a cross-check of the verdict, and the classical texts it is grounded in. Every layer is declared as present, computed_empty, not_covered or failed, so nothing is silently missing. No language model is called: the same chart always gets the same reading.
Cost: 5 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career"}

Input parameters:

- `birthData` (object, required): The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude.
- `domain` (string, required): Life area to read, e.g. career, marriage, finance or health.

### `get_life_reading` (~433 tokens)

Whole-life reading

Use this when the user wants their life as a whole: which life areas (marriage, children, career, business, money, property, family, travel, education, spirituality, health) are in focus when, across past and future, and where life stands now.
The life's chapters (each mahādaśā in plain words, with dates and ages) and eleven life areas, each with the planets that govern it on this chart, every governing period past and future with why that planet governs it — each marked `primary` (the area is in focus) or `also` (the period only touches it) — and what is in focus now and next. Past periods are included, so the reading can be tested against a life already lived; send `recorded` events to place them on the timeline. Health is read only as periods to give extra care, never as illness or lifespan. Deterministic: no language model is called. The birth time is required. The full reading is large; pass `areas` to return only the life areas you need.
Cost: 10 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"areas":["career","relationship"],"recorded":[{"type":"job_start","date":"2012-07-01","certainty":"exact"},{"type":"marriage","date":"2018-11-25","certainty":"exact"}]}

Input parameters:

- `areas` (array): Optional: only these life areas (default all eleven). The full reading is large, so an AI agent answering about one area should pass it here.
- `birthData` (object, required): The person's birth data. The time is required: every period depends on the rising sign.
- `recorded` (array): Optional dated life events to place on the timeline.

### `get_domain_timeline` (~359 tokens)

Life-area timeline

Use this when the user asks about one area of life — when marriage, children, career, money, property or another area is in focus, or what a given stretch of years holds for it.
One life area across the whole life: the planets that govern it on this chart, every period that bears on it (past and future, with dates, ages and why that planet governs it), each marked `primary` when the area is in focus or `also` when the period only touches it, and what is in focus now and next, in plain words. Pass `window` to get only the periods that overlap a date range. It is the same reading as the whole-life reading, cut to one area, so the two never disagree. Health is read only as periods to give extra care, never as illness or lifespan. Deterministic: no language model is called. The birth time is required.
Cost: 3 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"area":"relationship","window":{"from":"2026-01-01","to":"2031-12-31"}}

Input parameters:

- `area` (string, required): The life area.
- `birthData` (object, required): The person's birth data. The time is required: every period depends on the rising sign.
- `window` (object): Optional: only periods overlapping this date range (YYYY-MM-DD). Default: the whole life.

### `get_relationship_reading` (~360 tokens)

Relationship reading (non-marital)

Use this when the user asks how two people get on in a bond other than marriage — business partners, siblings, a parent and child, or friends.
Reads the bond the way the classical method reads it: the houses that govern this kind of bond and their lords in each chart, the natural significators, whose planets fall in whose governing houses, and whether that reach runs both ways, plus the running periods in each chart that engage the bond. A bond meter (strong tie, workable or strained) is computed by a stated convention and returned with every point it is built from; it is not a classical score, since the texts give no arithmetic for a business or sibling match. Deterministic: no language model is called. Both birth times are required. For marriage, use the compatibility tool.
Cost: 8 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"type":"business","a":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209,"name":"A"},"b":{"date":"1991-11-03","time":"06:10","timezone":"Asia/Kolkata","latitude":19.076,"longitude":72.8777,"name":"B"}}

Input parameters:

- `a` (object, required): First person: birth data (time required) plus optional name.
- `b` (object, required): Second person: birth data (time required) plus optional name.
- `type` (string, required): The bond. For marriage, call /v1/compatibility.

### `get_venture_timing` (~412 tokens)

Venture timing: when to commit, which business

Use this when the user asks when to start, launch, sign, borrow or expand a business, or which line of business their chart supports.
A calendar of the coming months in four labels — commit (sign, open, launch), build (keep building; commit only what can be undone), guarded (low fixed cost; no lease, no borrowing) and hold (no new fixed commitments) — each window with the daśā period running and the slow transits of Saturn and Jupiter over it, and the reasons. Describe the businesses being weighed in `ventures` and each is ranked on how strongly the chart supports it and whether the coming periods carry it, with the grounds, its best coming period, and a caution when it needs premises during a hold; name none and the full catalogue of business types is ranked. A ranking of chart support, never a probability of success. Deterministic: no language model is called. The birth time is required.
Cost: 10 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"ventures":["software and data platform for businesses","a restaurant in a leased storefront","OneDot"],"months":36}

Input parameters:

- `birthData` (object, required): The person's birth data. The time is required: every period depends on the rising sign.
- `months` (integer): How far ahead the calendar runs, and the horizon each venture's period support is averaged over.
- `ventures` (array): Optional: the businesses being weighed, each described by what it does ("software for accountants", "a café with a leased storefront"). A brand name alone cannot be placed and is returned as unclassi…

### `assess_gemstone` (~450 tokens)

Gemstone assessment

Use this when the user asks whether they should wear a particular gemstone (blue sapphire, emerald, pukhraj, a crystal), or whether a stone they wear suits their chart.
Answers the prescription, not the future: which planet the stone strengthens, what that planet owns from this ascendant, whether a classical rule (a dusthāna or kendrādhipati lordship, a māraka) argues against strengthening it, and whether the reason is permanent or lasts only as long as the running period. Returns a verdict — well_founded, period_bound, no_ground, contraindicated or unrecognised — with every ground for and against, the planet's capacity at its degree, when the chart puts the planet in scope, the stones the sources hold apart from it (checked against `alsoWearing`), and wearing detail (finger, metal, day, weight, with the book it comes from) only when the chart gives a reason to wear it. When the source states a caution about the stone, the response says so and names the book. A word that covers several stones ("sapphire") is answered with the candidates. Nothing here predicts what a stone does. Deterministic: no language model is called. The birth time is required.
Cost: 5 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"gem":"blue sapphire","alsoWearing":["ruby"]}

Input parameters:

- `alsoWearing` (array): Optional: stones already worn. When the chart puts the planet in scope, a pairing the sources hold apart is reported as a conflict.
- `birthData` (object, required): The person's birth data. The time is required: every period depends on the rising sign.
- `gem` (string, required): One stone, in English or by its Indian name: "yellow sapphire", "pukhraj", "emerald", "moonstone".

### `get_compatibility` (~360 tokens)

Marriage compatibility: the full reading

Use this when the user asks whether two people are a good match for marriage and wants the full reading, not only a score. For the fast 36-point score with Manglik alone, use get_guna_milan.
Both charts read together for marriage. The 36-point Aṣṭakūṭa (guna milan) is one input: the verdict names the governing factor and says when it outweighs the score. Also returned: each chart's marital promise, sustainability and happiness, progeny, Manglik reckoned from the lagna, the Moon and Venus with mutual cancellation, a joint marriage-timing window, synastry, and caveats where an uncertain birth time would change the reading. Deterministic: no language model is called. Each partner is a BirthData object plus optional `name` and `gender`.
Cost: 12 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"a":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209,"name":"A"},"b":{"date":"1991-11-03","time":"06:10","timezone":"Asia/Kolkata","latitude":19.076,"longitude":72.8777,"name":"B"}}

Input parameters:

- `a` (object, required): First partner: birth data plus optional name and gender.
- `b` (object, required): Second partner: birth data plus optional name and gender.
- `referenceDateIso` (string): ISO date the reading is anchored to. Defaults to now.

### `get_guna_milan` (~311 tokens)

Guna Milan (36-point Aṣṭakūṭa) and Manglik

Use this when the user asks for the guna milan / kundli matching score (out of 36), or whether either person is Manglik.
The classical Aṣṭakūṭa match for a pair (all eight kūṭas, with the Bhakoot and Nāḍī doṣas) and Manglik for both charts reckoned from the lagna, the Moon and Venus, with mutual cancellation. The same engine as /v1/compatibility, without the full reading: the score is one input, and /v1/compatibility reads each chart's marital promise, timing and doṣas on top of it. Deterministic, no language model.
Cost: 2 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"a":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209,"name":"A"},"b":{"date":"1991-11-03","time":"06:10","timezone":"Asia/Kolkata","latitude":19.076,"longitude":72.8777,"name":"B"}}

Input parameters:

- `a` (object, required): First partner: birth data plus optional name and gender.
- `b` (object, required): Second partner: birth data plus optional name and gender.

### `find_muhurta` (~412 tokens)

Auspicious windows (muhūrta) in a date range

Use this when the user asks for an auspicious date or time (muhūrta) to do something, such as a wedding, launch, move or purchase, within a date range at a given place.
Scans each day in the range and ranks windows for the subject. The pañcāṅga is computed for `eventPlace`, never defaulted to the birthplace.
Cost: 10 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"subject":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"eventPlace":{"latitude":19.076,"longitude":72.8777,"timezone":"Asia/Kolkata","label":"Mumbai"},"freeText":"signing a lease","rangeStart":"2026-11-01","rangeEnd":"2026-11-15"}

Input parameters:

- `eventId` (string): Event type identifier, if known.
- `eventPlace` (object, required): Where the event will happen: latitude, longitude and IANA timezone. The pañcāṅga is computed here, never at the birthplace.
- `freeText` (string): The event described in words, when there is no eventId.
- `rangeEnd` (string, required): Last date to search, YYYY-MM-DD.
- `rangeStart` (string, required): First date to search, YYYY-MM-DD.
- `subject` (object, required): Birth data of the person the event is for; windows are ranked against their chart.
- `subjectName` (string): Optional name of the subject, used only in the response text.
- `timeOfDay` (string): Local time (HH:MM) at which each day is evaluated. Default: local sunrise.
- `topN` (integer): How many ranked windows to return. Default 5.

### `get_forecast` (~271 tokens)

Written answer about what lies ahead

Use this when the user asks an open question about what lies ahead in one area of life and wants a written answer. It takes tens of seconds; for a fast, structured verdict use interpret_domain.
The interpret verdict for `domain`, voiced as a narrative answer to `question` by a language model grounded in the classical statements for the domain. Expect tens of seconds; set a client timeout of at least 90 s.
Cost: 8 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Voiced by a language model: allow up to 90 seconds.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career","question":"How will the next year unfold for my work?"}

Input parameters:

- `birthData` (object, required): The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude.
- `domain` (string, required): Life area the question is about, e.g. career, marriage, finance or health.
- `question` (string, required): The question in plain language, e.g. "What does the next year hold for my career?"

### `resolve_timing` (~401 tokens)

Is this a good time? (decision timing)

Use this when the user asks whether now, or a particular date or range, is a good time for a decision such as changing jobs, marrying or investing. It takes tens of seconds.
The interpret verdict for `domain`, voiced by a language model as an answer to a decision `question`, read at `targetDate` (or the start of `dateRange`, or today when neither is sent): the verdict, the running daśā and eventTiming are taken at that day. A malformed or pre-birth date is refused with 400 (`invalid_target_date`, `invalid_date_range`). Expect tens of seconds; set a client timeout of at least 90 s.
Cost: 7 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Voiced by a language model: allow up to 90 seconds.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career","question":"Should I accept the offer?","targetDate":"2026-11-15"}

Input parameters:

- `birthData` (object, required): The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude.
- `dateRange` (object): Optional period the decision is about: start and end dates, YYYY-MM-DD. The verdict is read at `start`; `end` must not precede it.
- `domain` (string, required): Life area the decision is about, e.g. career, marriage, finance or health.
- `question` (string, required): The decision question in plain language, e.g. "Is this a good time to change jobs?"
- `targetDate` (string): Optional date the decision is about, YYYY-MM-DD. The verdict is read at this day. Takes precedence over `dateRange`.

### `get_ephemeris_positions` (~302 tokens)

Positions at a moment

Use this when you need where the Sun, Moon and planets are at a moment (sidereal or tropical), not a reading.
Sun, Moon, planets and lunar nodes at one moment: longitude, latitude, distance, speed and retrograde flag, with sign, and nakṣatra and its quarter when sidereal. `equatorial: true` adds apparent right ascension and declination.
Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"datetime":"2026-10-06T06:00:00Z","bodies":["Sun","Moon","Mars","Jupiter","Saturn","TrueNode"],"zodiac":"sidereal","ayanamsa":"lahiri"}

Input parameters:

- `ayanamsa` (string): Sidereal only.
- `bodies` (array): Default: all twelve.
- `datetime` (string, required): ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime).
- `equatorial` (boolean): Also return apparent right ascension and declination. Default false.
- `zodiac` (string): sidereal (default) or tropical.

### `get_ephemeris_angles` (~294 tokens)

Ascendant, MC and house cusps

Use this when you need the ascendant, midheaven or house cusps for a moment and place.
Ascendant, midheaven and twelve cusps for a moment and place. Placidus is undefined beyond the polar circles at some moments; the call then returns 422 houses_undefined_at_latitude.
Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"datetime":"1990-05-12T14:35:00+05:30","latitude":28.6139,"longitude":77.209,"houseSystem":"placidus"}

Input parameters:

- `ayanamsa` (string): Sidereal only.
- `datetime` (string, required): ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime).
- `houseSystem` (string): House system for the cusps: whole_sign (default), equal or placidus.
- `latitude` (number, required): Geographic latitude in decimal degrees, north positive.
- `longitude` (number, required): East positive.
- `zodiac` (string): sidereal (default) or tropical.

### `get_ephemeris_ayanamsa` (~184 tokens)

Ayanamsa values

Use this when you need an ayanamsa value at a moment.
The ayanāṁśa (the sidereal offset) at a moment, for each supported ayanāṁśa (mean, without nutation).
Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"datetime":"2026-10-06T00:00:00Z"}

Input parameters:

- `datetime` (string, required): ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime).

### `get_ephemeris_sunrise` (~228 tokens)

Sunrise and sunset

Use this when you need sunrise and sunset for a date and place, or where the Vedic day begins.
Sunrise, sunset and the next sunrise for a local date and place: upper limb at the sea-level horizon with 36.6′ refraction. The Vedic day runs from sunrise to the next sunrise.
Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"date":"2026-10-06","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}

Input parameters:

- `date` (string, required): Local calendar date, YYYY-MM-DD.
- `latitude` (number, required): Geographic latitude in decimal degrees, north positive.
- `longitude` (number, required): East positive.
- `timezone` (string, required): IANA name, e.g. Asia/Kolkata. Defines the local day.

### `get_ephemeris_series` (~332 tokens)

Positions over a range

Use this when you need planetary positions across a range of dates, for a transit table or to find when a planet changes sign or stations.
Positions from start to end (inclusive) every stepMinutes, for transit tables and station finding. At most 1,000 points (too_many_points beyond). A 365-point daily table costs 4 credits.
Cost: 1 credit per started 100 points (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"start":"2026-10-01T00:00:00Z","end":"2026-10-10T00:00:00Z","stepMinutes":1440,"bodies":["Mercury","Venus"]}

Input parameters:

- `ayanamsa` (string): Sidereal only.
- `bodies` (array): Default: all twelve.
- `end` (string, required): ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime).
- `start` (string, required): ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime).
- `stepMinutes` (integer, required): Minutes between points (1 to 525,600). At most 1,000 points per call.
- `zodiac` (string): sidereal (default) or tropical.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/onedotlinks-astronest/api-developer-mcp#diagnostics

## Score history

- 2026-11-05: 91
- 2026-11-04: 90
- 2026-11-03: 90
- 2026-11-02: 89
- 2026-11-01: 82
- 2026-10-31: 82
- 2026-10-30: 81
- 2026-10-29: 81
- 2026-10-28: 80
- 2026-10-27: 80
- 2026-10-26: 79
- 2026-10-25: 79
- 2026-10-24: 78
- 2026-10-23: 78
- 2026-10-22: 77
- 2026-10-21: 77
- 2026-10-20: 76
- 2026-10-19: 76
- 2026-10-18: 75
- 2026-10-17: 75
- 2026-10-16: 75
- 2026-10-15: 74
- 2026-10-14: 74
- 2026-10-13: 73
- 2026-10-12: 73
- 2026-10-10: 72

## Common questions

### What is the AstroNest — Vedic Astrology Readings MCP server?

AstroNest — Vedic Astrology Readings is an MCP server listed in the public MCP registry as io.github.onedotlinks/astronest. Vedic astrology readings for AI agents: life areas, compatibility, business timing, gems, ephemeris. This page covers its hosted endpoint (https://www.astronest.ai/api/developer/mcp).

### Is the AstroNest — Vedic Astrology Readings MCP server safe to use?

AstroNest — Vedic Astrology Readings scores 91 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 AstroNest — Vedic Astrology Readings MCP server expose?

AstroNest — Vedic Astrology Readings exposes 21 tools: get_chart, get_dasha, get_guidance, get_techniques, get_prashna, and 16 more. Their descriptions and schemas cost roughly 7,383 tokens of context every time the server is loaded.

### Does the AstroNest — Vedic Astrology Readings MCP server require authentication?

Yes. AstroNest — Vedic Astrology Readings asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the AstroNest — Vedic Astrology Readings MCP server still maintained?

AstroNest — Vedic Astrology Readings 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 AstroNest — Vedic Astrology Readings MCP server?

VerifyMCP ran 13 checks on AstroNest — Vedic Astrology Readings, covering TLS certificate, Authorization, HTTPS, HSTS header and 9 more. Supply Chain Security and Provenance & Transparency do not apply to a hosted endpoint, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- Remote endpoint: https://www.astronest.ai/api/developer/mcp
- Repository: https://github.com/onedotlinks/astronest-quickstart
- Website: https://www.astronest.ai/developers/astrology-mcp-server
- Changelog RSS feed: https://verifymcp.io/servers/onedotlinks-astronest/api-developer-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/onedotlinks-astronest/api-developer-mcp/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/onedotlinks-astronest/api-developer-mcp.json
- HTML version of this page: https://verifymcp.io/servers/onedotlinks-astronest/api-developer-mcp