AstroNest — Vedic Astrology Readings
REMOTE · WWW.ASTRONEST.AI
Vedic astrology readings for AI agents: life areas, compatibility, business timing, gems, ephemeris.
Available components
Last scanned (14 hours ago)
Scores higher than 98% of remote servers
Reachable. Last reached 5 Nov 2026.
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. How we score → Why this is hard to score →
Endpoint Security97
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- 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. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability60
- AI-judged instruction clarity (excellent).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management93
- Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 21 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 22 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Checks we ran (13)
- TLS certificate
- Authorization
- HTTPS
- HSTS header
- DNSSEC
- Transport
- Schema quality
- Stability
- Tool coverage
- Injection markers
- Destructive annotations
- Judged manipulation
- MCP protocol
Does not apply to this hosted endpoint (2)
- Supply Chain SecurityScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.
- Provenance & TransparencyScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.
The score does not measure everything. What the score does not measure →
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 +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.
- 3 Nov 26 +1
- The server rewrote its instructions, which are the text every model session reads security
- 2 Nov 26 +7
- 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 security
- “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 cosmetic
- 31 Oct 26 +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.
- 29 Oct 26 +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.
- 27 Oct 26 +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.
- 25 Oct 26 +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.
- 23 Oct 26 +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.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://www.astronest.ai/api/developer/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=www.astronest.ai | CN=YR2,O=Let's Encrypt,C=US | 22 Sept 2026 | 21 Dec 2026 | RSA 2048 | SHA256-RSA | 6c1cc82dde5f78e8ac7f071192497c5bf45 |
| SANs: www.astronest.ai | ||||||
| CN=YR2,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | 4ebd24947e24d394802d84a52fd5b319 |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of www.astronest.ai. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | Trust anchor | 20326, 38696 | 8, 8 | Verified |
| ai. | DS published | 1814, 3799 | 8, 8 | Verified |
| astronest.ai. | No DS | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://www.astronest.ai/.well-known/oauth-protected-resource/api/developer/mcp", scope="tools"
Bearer resource_metadata="https://www.astronest.ai/.well-known/oauth-protected-resource/api/developer/mcp", scope="tools" | Header | Value |
|---|---|
| strict-transport-security | max-age=63072000 |
Protected resource metadata
| Document | https://www.astronest.ai/.well-known/oauth-protected-resource/api/developer/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://www.astronest.ai/api/developer/mcp |
| Authorisation server | https://www.astronest.ai |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://www.astronest.ai/api/developer/mcp | Verified | 200 | |
| http (plaintext) | http://www.astronest.ai/api/developer/mcp | HTTPS enforced | 308 | https://www.astronest.ai/api/developer/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
assess_gemstone Gemstone assessment ~450
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"]}
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | The person's birth data. The time is required: every period depends on the rising sign. |
| gem | string | yes | One stone, in English or by its Indian name: "yellow sapphire", "pukhraj", "emerald", "moonstone". |
Structured output declared, but exposes no named fields.
No examples provided.
find_muhurta Auspicious windows (muhūrta) in a date range ~412
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"}
| Name | Type | Req | Description |
|---|---|---|---|
| eventId | string | – | Event type identifier, if known. |
| eventPlace | object | yes | 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 | yes | Last date to search, YYYY-MM-DD. |
| rangeStart | string | yes | First date to search, YYYY-MM-DD. |
| subject | object | yes | 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. |
Structured output declared, but exposes no named fields.
No examples provided.
get_chart Natal chart (kundli) ~353
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}}
| Name | Type | Req | Description |
|---|---|---|---|
| birthData | object | yes | 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. |
Structured output declared, but exposes no named fields.
No examples provided.
get_compatibility Marriage compatibility: the full reading ~360
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"}}
| Name | Type | Req | Description |
|---|---|---|---|
| a | object | yes | First partner: birth data plus optional name and gender. |
| b | object | yes | Second partner: birth data plus optional name and gender. |
| referenceDateIso | string | – | ISO date the reading is anchored to. Defaults to now. |
Structured output declared, but exposes no named fields.
No examples provided.
get_dasha Life-period timeline (planetary periods) ~226
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}}
| Name | Type | Req | Description |
|---|---|---|---|
| birthData | object | yes | 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śā. |
Structured output declared, but exposes no named fields.
No examples provided.
get_domain_timeline Life-area timeline ~359
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"}}
| Name | Type | Req | Description |
|---|---|---|---|
| area | string | yes | The life area. |
| birthData | object | yes | 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. |
Structured output declared, but exposes no named fields.
No examples provided.
get_ephemeris_angles Ascendant, MC and house cusps ~294
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"}
| Name | Type | Req | Description |
|---|---|---|---|
| ayanamsa | string | – | Sidereal only. |
| datetime | string | yes | 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 | yes | Geographic latitude in decimal degrees, north positive. |
| longitude | number | yes | East positive. |
| zodiac | string | – | sidereal (default) or tropical. |
Structured output declared, but exposes no named fields.
No examples provided.
get_ephemeris_ayanamsa Ayanamsa values ~184
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"}
| Name | Type | Req | Description |
|---|---|---|---|
| datetime | string | yes | 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). |
Structured output declared, but exposes no named fields.
No examples provided.
get_ephemeris_positions Positions at a moment ~302
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"}
| Name | Type | Req | Description |
|---|---|---|---|
| ayanamsa | string | – | Sidereal only. |
| bodies | array | – | Default: all twelve. |
| datetime | string | yes | 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. |
Structured output declared, but exposes no named fields.
No examples provided.
get_ephemeris_series Positions over a range ~332
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"]}
| Name | Type | Req | Description |
|---|---|---|---|
| ayanamsa | string | – | Sidereal only. |
| bodies | array | – | Default: all twelve. |
| end | string | yes | 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 | yes | 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 | yes | Minutes between points (1 to 525,600). At most 1,000 points per call. |
| zodiac | string | – | sidereal (default) or tropical. |
Structured output declared, but exposes no named fields.
No examples provided.
get_ephemeris_sunrise Sunrise and sunset ~228
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}
| Name | Type | Req | Description |
|---|---|---|---|
| date | string | yes | Local calendar date, YYYY-MM-DD. |
| latitude | number | yes | Geographic latitude in decimal degrees, north positive. |
| longitude | number | yes | East positive. |
| timezone | string | yes | IANA name, e.g. Asia/Kolkata. Defines the local day. |
Structured output declared, but exposes no named fields.
No examples provided.
get_forecast Written answer about what lies ahead ~271
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?"}
| Name | Type | Req | Description |
|---|---|---|---|
| birthData | object | yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. |
| domain | string | yes | Life area the question is about, e.g. career, marriage, finance or health. |
| question | string | yes | The question in plain language, e.g. "What does the next year hold for my career?" |
Structured output declared, but exposes no named fields.
No examples provided.
get_guidance Guidance for the running daśā periods ~206
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}}
| Name | Type | Req | Description |
|---|---|---|---|
| birthData | object | yes | 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. |
Structured output declared, but exposes no named fields.
No examples provided.
get_guna_milan Guna Milan (36-point Aṣṭakūṭa) and Manglik ~311
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"}}
| Name | Type | Req | Description |
|---|---|---|---|
| a | object | yes | First partner: birth data plus optional name and gender. |
| b | object | yes | Second partner: birth data plus optional name and gender. |
Structured output declared, but exposes no named fields.
No examples provided.
get_life_reading Whole-life reading ~433
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"}]}
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
Structured output declared, but exposes no named fields.
No examples provided.
get_prashna Praśna (horary): a question, a deal, or a horary number ~750
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…
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
Structured output declared, but exposes no named fields.
No examples provided.
get_relationship_reading Relationship reading (non-marital) ~360
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"}}
| Name | Type | Req | Description |
|---|---|---|---|
| a | object | yes | First person: birth data (time required) plus optional name. |
| b | object | yes | Second person: birth data (time required) plus optional name. |
| type | string | yes | The bond. For marriage, call /v1/compatibility. |
Structured output declared, but exposes no named fields.
No examples provided.
get_techniques Classical techniques for a chart ~459
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"}
| Name | Type | Req | Description |
|---|---|---|---|
| birthData | object | yes | 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. |
Structured output declared, but exposes no named fields.
No examples provided.
get_venture_timing Venture timing: when to commit, which business ~412
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}
| Name | Type | Req | Description |
|---|---|---|---|
| birthData | object | yes | 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… |
Structured output declared, but exposes no named fields.
No examples provided.
interpret_domain Reading of one life area ~280
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"}
| Name | Type | Req | Description |
|---|---|---|---|
| birthData | object | yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. |
| domain | string | yes | Life area to read, e.g. career, marriage, finance or health. |
Structured output declared, but exposes no named fields.
No examples provided.
resolve_timing Is this a good time? (decision timing) ~401
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"}
| Name | Type | Req | Description |
|---|---|---|---|
| birthData | object | yes | 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 | yes | Life area the decision is about, e.g. career, marriage, finance or health. |
| question | string | yes | 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`. |
Structured output declared, but exposes no named fields.
No examples provided.
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.
remote · www.astronest.ai
claude mcp add --transport http onedotlinks-astronest 'https://www.astronest.ai/api/developer/mcp'
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.