Skip to main content
Glama

Astro Agents - verifiable planetary timing data and astrology

Kundli with all 16 vargas

kundli_full
Read-onlyIdempotent

Vedic astrology full kundli: all 16 Shodashavarga divisional charts, D1 to D60 (navamsa, dasamsa...), by Parashara's rules. Everything in /vedic/kundli plus D1, D2, D3, D4, D7, D9, D10, D12, D16, D20, D24, D27, D30, D40, D45 and D60, each with its lagna, placements and house table. Deterministic (JPL DE440, no LLM); every result carries meta.result_sha256. Price $0.32 per call via REST POST https://astro-agent.dev/v1/vedic/kundli-full (x402 or MPP); always paid, never a free call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "latitude": "<latitude>",
      "longitude": "<longitude>"
    },
    "name": "kundli_full"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoYYYY-MM-DD (use with 'time' instead of 'datetime').
timeNoHH:MM or HH:MM:SS, 24 h. Omit if unknown (computed at 12:00 with a TIME_UNKNOWN warning).
optionsNoOptional calculation settings; every default is the common Parashari convention.
datetimeNoLocal birth date-time, ISO 8601: '1990-05-15T14:30' (local clock time at the place) or with an explicit offset '1990-05-15T14:30:00+02:00'. Alternative: 'date' + 'time'.
latitudeYesDecimal degrees, north positive.
timezoneNoIANA zone, e.g. 'Asia/Kolkata'. Optional: resolved from the coordinates, with the historical offset (DST, Local Mean Time) of that date.
longitudeYesDecimal degrees, east positive.
time_basisNoWhat the given clock time is: civil wall-clock (default), UTC, Local Mean Time, or true (apparent) solar time.civil
ambiguous_timeNoWhich occurrence to use when a local time happens twice (DST fall-back).earlier

Output Schema

NameRequiredDescriptionDefault
metaNoProvenance of the result.
errorNox402 offer only: why payment is required.
resultNoThe calculation result.
acceptsNox402 offer only: the payment options (scheme, network, amount, asset, payTo, ...).
endpointNoThe REST route that computed it, e.g. 'western/natal'.
resourceNox402 offer only: the resource being paid for.
extensionsNox402 offer only: protocol extensions (bazaar).
x402VersionNox402 offer only: protocol version (2).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "required": [
      +      "endpoint",
      +      "result",
      +      "meta"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "x402Version",
      +      "accepts"
      +    ]
      +  }
      +]
    • addedOutput schema / properties / accepts
      Added value: +{
      +  "description": "x402 offer only: the payment options (scheme, network, amount, asset, payTo, ...).",
      +  "items": {
      +    "type": "object"
      +  },
      +  "minItems": 1,
      +  "type": "array"
      +}
    • addedOutput schema / properties / error
      Added value: +{
      +  "description": "x402 offer only: why payment is required.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / extensions
      Added value: +{
      +  "description": "x402 offer only: protocol extensions (bazaar).",
      +  "type": "object"
      +}
    • addedOutput schema / properties / resource
      Added value: +{
      +  "description": "x402 offer only: the resource being paid for.",
      +  "type": "object"
      +}
    • addedOutput schema / properties / x402Version
      Added value: +{
      +  "description": "x402 offer only: protocol version (2).",
      +  "type": "integer"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "endpoint",
      -  "result",
      -  "meta"
      -]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "endpoint": {
      +      "description": "The REST route that computed it, e.g. 'western/natal'.",
      +      "type": "string"
      +    },
      +    "meta": {
      +      "description": "Provenance of the result.",
      +      "properties": {
      +        "astronomy_library": {
      +          "description": "Astronomy library and version.",
      +          "type": "string"
      +        },
      +        "compute_ms": {
      +          "description": "Computation time in milliseconds.",
      +          "type": "number"
      +        },
      +        "computed_at": {
      +          "description": "When it was computed (UTC, ISO 8601).",
      +          "type": "string"
      +        },
      +        "deterministic": {
      +          "description": "Always true: same input, same result.",
      +          "type": "boolean"
      +        },
      +        "engine": {
      +          "description": "Engine name and version.",
      +          "type": "string"
      +        },
      +        "ephemeris": {
      +          "description": "Ephemeris used (NASA/JPL DE440).",
      +          "type": "string"
      +        },
      +        "frame": {
      +          "description": "Reference frame of the positions.",
      +          "type": "string"
      +        },
      +        "input_sha256": {
      +          "description": "SHA-256 of the canonical input.",
      +          "type": "string"
      +        },
      +        "llm_used": {
      +          "description": "Always false: no language model is involved.",
      +          "type": "boolean"
      +        },
      +        "payment": {
      +          "description": "How this call was paid: protocol ('free' or 'none'), price and the free calls remaining.",
      +          "type": "object"
      +        },
      +        "reproducibility": {
      +          "description": "How to reproduce and check this result.",
      +          "type": "string"
      +        },
      +        "result_sha256": {
      +          "description": "SHA-256 of the canonical 'result'; check it with verify_result_hash.",
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "engine",
      +        "deterministic",
      +        "llm_used",
      +        "input_sha256",
      +        "result_sha256"
      +      ],
      +      "type": "object"
      +    },
      +    "result": {
      +      "description": "The calculation result.",
      +      "properties": {
      +        "bhavas": {
      +          "description": "The twelve houses (bhavas): sign, rashi, lord and the grahas occupying each one.",
      +          "type": "array"
      +        },
      +        "grahas": {
      +          "description": "The nine grahas (Sun to Ketu): sidereal longitude, rashi, sign lord, nakshatra, pada, nakshatra lord, deity, house, and dignity flags.",
      +          "type": "array"
      +        },
      +        "lagna": {
      +          "description": "The ascendant (lagna): sidereal longitude, rashi and sign, degree, sign lord, nakshatra, pada and nakshatra lord.",
      +          "type": "object"
      +        },
      +        "settings": {
      +          "description": "Settings applied: sidereal zodiac, ayanamsa (name and value in degrees), lunar node type, house system and divisional-chart rules.",
      +          "type": "object"
      +        },
      +        "subject": {
      +          "description": "The resolved input: 'time' (local input, time zone and historical UTC offset, UT, Julian days, Delta T) and, when given, 'location' (latitude, longitude).",
      +          "type": "object"
      +        },
      +        "summary": {
      +          "description": "Key facts: lagna sign and lord, Moon sign, sidereal Sun sign, janma nakshatra with pada and lord, and the exalted, debilitated, retrograde and combust grahas.",
      +          "type": "object"
      +        },
      +        "vargas": {
      +          "description": "All 16 Shodashavarga divisional charts, D1 to D60, keyed by name (D1, D2, D3, D4, D7, D9, D10, D12, D16, D20, D24, D27, D30, D40, D45, D60).",
      +          "type": "object"
      +        },
      +        "warnings": {
      +          "description": "Notes on the input or the calculation (for example an assumed noon for an unknown birth time). Present only when there is something to say.",
      +          "type": "array"
      +        }
      +      },
      +      "required": [
      +        "subject",
      +        "settings",
      +        "lagna",
      +        "grahas",
      +        "bhavas",
      +        "summary",
      +        "vargas"
      +      ],
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "endpoint",
      +    "result",
      +    "meta"
      +  ],
      +  "type": "object"
      +}
  3. Changed3 schema fields changed
    • addedInput schema / properties / options / description
      Added value: +"Optional calculation settings; every default is the common Parashari convention."
    • addedInput schema / properties / options / properties / ayanamsa / description
      Added value: +"Sidereal reference (ayanamsa). Default 'lahiri' (Chitrapaksha), the Indian standard."
    • addedInput schema / properties / options / properties / include_outer_planets / description
      Added value: +"Also return Uranus, Neptune and Pluto (not used in classical Jyotish)."
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description still adds substantive traits: deterministic JPL DE440 ephemeris with no LLM, a verifiable meta.result_sha256 on every result, a fixed $0.32 per-call price, and payment via x402 or MPP only. The 'always paid, never a free call' warning prevents a costly failed call attempt.

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 resource and its scope, then pricing and payment, which is the right order for an agent deciding whether to pay. Minor redundancy in listing all sixteen varga divisions after already saying 'all 16 Shodashavarga charts, D1 to D60', but the enumeration is informative rather than empty.

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?

An output schema exists, so the description needn't explain return values, yet it still names the per-chart contents (lagna, placements, house table) and the hash field. Pricing, transport, and determinism are all disclosed, leaving nothing an agent needs to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, with enums and defaults already documented for ayanamsa, node_type, house_system, time_basis, ambiguous_time, and datetime formats, so the baseline is 3. The description adds no parameter-level guidance of its own beyond noting Parashari defaults, and it never clarifies the latitude/longitude versus timezone interaction that the schema handles.

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?

States a specific verb and resource ('Vedic astrology full kundli') and immediately distinguishes scope from the sibling 'kundli' tool: 'Everything in /vedic/kundli plus D1...D60'. An agent can tell exactly what extra content this call buys without opening either schema.

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?

The 'Everything in /vedic/kundli plus...' phrasing implicitly routes an agent here when the full varga set is needed and to the lighter sibling otherwise, and the pricing note ('always paid, never a free call') gives a cost-based selection signal. It stops short of an explicit 'use kundli instead when you only need D1' exclusion.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.