AstroNest — Vedic Astrology & Ephemeris

Classical techniques for a chart

get_techniques

Read-onlyIdempotent

Use this when the user or an astrologer asks for a specific classical computation — Ṣaḍbala, Aṣṭakavarga, Yoginī/Chara/Nārāyaṇa daśā, Varṣaphal, KP cusps, a named yoga, the birth pañcāṅga, Kuja doṣa, 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: Ṣaḍbala and bhāva bala (BPHS 27), Aṣṭakavarga with trikoṇa/ekādhipatya reduction and piṇḍas, the Aṣṭottarī, Kālacakra, Nārāyaṇa, Yoginī and Chara daśās with the periods running at referenceDate, the full Vimśottarī ladder, the Varṣaphal (Tājika annual chart) for the year running at referenceDate, KP cusps with sub-lords and ruling planets (labelled KP only when the KP frame was computed), classical and Nābhasa yogas, kārakāṁśa, argala, special lagnas, bhāva chalit, the natal pañcāṅga, house lords with graha dṛṣṭi, Kuja doṣa with its exceptions, and what would change under the Raman or KP 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 Schema

Name	Required	Description
`sections`	No	Return only these sections. Default: all.
`birthData`	Yes	The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude.
`residence`	No	Where the person lives; the Varṣaphal is cast for this place. Defaults to the birthplace.
`referenceDate`	No	ISO date or datetime for the running periods and the Varṣaphal year. Defaults to now.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds substantial context beyond them: 3 credits per call, only successful calls charged, free sandbox key returning a fixed sample, determinism, the per-section {computed:true/false, reason} failure contract, and the explicit absence of verdicts/scores/lifespan figures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the when-to-use trigger and then the return contract, with cost/determinism grouped at the end. The second paragraph is a dense run-on catalogue of every section and the example-arguments block repeats schema content, adding length without much marginal routing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return shapes, yet it still documents the computed/computed-false envelope, credit cost, determinism, and degraded behavior without a birth time. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description rises above baseline by explaining what each section name actually computes (e.g. Aṣṭakavarga reductions and piṇḍas, daśās running at referenceDate, Varṣaphal cast for residence), which gives the enum values meaning the bare schema strings do not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb+resource (classical computations for a chart) and enumerates the exact techniques returned. It explicitly distinguishes itself from reading-oriented siblings with 'rather than for a reading', so an agent can separate it from get_life_reading/get_relationship_reading/get_guidance without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States a clear trigger ('when the user or an astrologer asks for a specific classical computation') and an explicit exclusion (not for a reading). It does not, however, route the agent to overlapping siblings such as get_dasha or get_chart, which partially duplicate the daśā and chart sections here.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AstroNest — Vedic Astrology & Ephemeris tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.