Skip to main content
Glama
Sign In

AstroCalc: Vedic astrology

by in.astrocalc
OverviewDiscussionsAdmin

Life chapters and phases over the years

life_timeline
Read-onlyIdempotent

Timeline of life chapters (Vimshottari Mahadashas) and phases (Antardashas, or the finer Pratyantardashas for spans up to 3 years) with start and end dates over a chosen span, marking the one running today. From birth details (free, no sign-in) or for a person saved on the user's AstroCalc account (profile; that needs a free sign-in). Use for timing questions: when a hard period ends, which coming years suit marriage or a career move, what the next decade looks like ("shaadi ka yog kab hai", "agle 10 saal"). Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "life_timeline"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNoBirth latitude in decimal degrees (north positive). Give together with lon.
lonNoBirth longitude in decimal degrees (east positive). Give together with lat.
dateNoDate of birth, YYYY-MM-DD (Gregorian calendar).
fromNoStart of the span, YYYY-MM-DD. Defaults to today.
langNoLanguage of the text fields: 'en' (English, default) or 'hi' (Hindi).
timeNoLocal clock time of birth, 24-hour HH:MM (e.g. '06:45', '21:10'); '6:45 am' / '9:10 PM' also work. Use 'unknown' (or omit) if not known: noon is used, the Moon sign stays reliable but the Lagna is approximate.
levelNoDepth: 'mahadasha', 'antardasha' (default) or 'pratyantardasha'.
placeNoBirth city or town, e.g. 'Lucknow' or 'Pune, Maharashtra, India'. The best match is used (Indian cities preferred); call search_place first if unsure. Not needed when lat and lon are given.
yearsNoLength of the span in years (default 10).
profileNoA saved kundli on the user's AstroCalc account: its name as listed by my_profiles (e.g. 'Mummy') or its id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / time / description
      Previous value: -"Local clock time of birth, 24-hour HH:MM (e.g. '06:45', '21:10'). Use 'unknown' (or omit) if not known: noon is used, the Moon sign stays reliable but the Lagna is approximate."New value: +"Local clock time of birth, 24-hour HH:MM (e.g. '06:45', '21:10'); '6:45 am' / '9:10 PM' also work. Use 'unknown' (or omit) if not known: noon is used, the Moon sign stays reliable but the Lagna is approximate."
    • changedInput schema / properties / time / pattern
      Previous value: -"^(([01]\\d|2[0-3]):[0-5]\\d|unknown)$"New value: +"^(([01]?\\d|2[0-3]):[0-5]\\d|(0?[1-9]|1[0-2]):[0-5]\\d ?[AaPp][Mm]|unknown)$"
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the bar is lower, but the description still adds real context: free access without sign-in, sign-in required for saved profiles, and the actively running period being marked. A minor redundancy is restating 'Read-only'. It could also say what happens if no profile or birth details are supplied, since nothing is required.

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 core output, then input routes, then use cases, so the most important information comes first. The single long opening sentence with nested parentheses is dense, and the trailing 'Read-only' duplicates the annotations, but no sentence is wasted.

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?

For a 10-parameter, no-output-schema tool this covers what an agent needs: both input modes, the depth tradeoff, span defaults, and that no periods are aggregated elsewhere. The remaining gap, exact return shape, is acceptable because the description names the periods and dates returned.

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 baseline is 3, but the description adds domain meaning the schema does not: that Pratyantardashas are the finer subdivision appropriate for spans up to 3 years, which directly informs the level choice. It also frames profile input as an alternative to birth details, softening an otherwise ambiguous either/or parameter set.

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 resource (Vimshottari mahadashas/antardashas/pratyantardashas) with start and end dates over a chosen span and marks the currently running period. The parenthetical glosses of the Sanskrit terms make the output identifiable, and the distinction from siblings like explain_dasha or my_family_phases is clear from the time-span framing.

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?

Gives concrete when-to-use context: timing questions such as when a hard period ends, which years suit marriage or a career move, with example queries in Hinglish. It also clarifies the two input routes (birth details, free; saved profile, needs sign-in). It stops short of naming which sibling to use instead for adjacent needs (e.g. explaining a single dasha vs listing a span).

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

All AstroCalc: Vedic astrology toolsInspect
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.

Resources