What can you do with this server?

The Astro Skill MCP Server is a Vedic astrology engine that performs deterministic astrological calculations, manages client profiles, and generates JSON/PDF reports. * Parse Birth Details – Extract date, time, place, coordinates, and timezone from free-form text, flagging any missing fields. * Calculate Kundali – Compute a full sidereal birth chart with lagna, Moon rashi, nakshatra (with pada), planet positions, whole-sign houses, Navamsa (D9), ashtakavarga tables, and Vimshottari dasha seed. Supports multiple ayanamsas (Lahiri, Raman, KP, etc.). * Calculate Dasha – Generate the complete Vimshottari mahadasha/antardasha/pratyantardasha timeline and identify the currently running period for any given date. * Calculate Gochar – Compute planetary transits relative to natal Moon and Lagna, including Saturn Sade Sati/Dhaiya phase analysis. * Calculate Compatibility – Perform Ashtakoot (36-point) Guna Milan between two kundalis, with koota-wise breakdown and Nadi, Bhakoot, and Manglik dosha findings. * Calculate Panchang – Compute daily almanac elements (vara, tithi, nakshatra, yoga, karana, sunrise/sunset, muhurtas) for any date and location. * Generate JSON Report – Assemble and save a structured astrology report combining kundali, dasha, panchang, and gochar sections. * Generate PDF Report – Render a polished client-facing PDF with charts, planet table, and dasha timeline in Hindi or English, using an HTML/Chromium renderer or ReportLab fallback, with a premium pandit_v1 template option. * Save Client Profile – Create or update client profiles (with birth details and notes) in a SQLite store via upsert. * Find Client Profile – Look up a client by exact ID or case-insensitive display name substring. * List Client Reports – Retrieve previously generated reports for a client, sorted newest first, with type, file path, and timestamp.

How do I use Astro Skill MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Astro Skill MCP Server calculate kundali for John born 15 Mar 1990 10:30 AM New York" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Astro Skill MCP Server

by adityarya24

Overview Schema Related Servers Score Discussions

Python

Hybrid

🌌 Astro Skill

🎯 Overview

Astro Skill is a production-grade, deterministic Vedic astrology engine that converts birth details and celestial coordinates into structured mathematical charts, timelines, and factual reports.

🔬 Zero Hallucinations: 100% calculation-backed using bundled Swiss Ephemeris data (.se1 SWIEPH via pyswisseph) and Lahiri (Chitrapaksha) ayanamsa.
🔌 3 Plug-and-Play Surfaces:
1. Stdio MCP Server (astro-mcp): 11 stable tools for Claude Desktop, Cursor, Codex, OpenClaw, and any Model Context Protocol client.
2. Python Library & CLI: Import directly in Python or run standalone CLI calculator scripts with --json outputs.
3. Agent Skill: Portable SKILL.md ready to equip autonomous coding agents and orchestrators.
📄 In-Process PDF Generator: Generates bilingual (Hindi & English) Kundali and Panchang charts via ReportLab with bundled Noto Sans Devanagari font — zero headless browser or Chrome dependencies.
🔒 100% Offline & Private: Zero external API keys, zero rate-limits, and zero network calls required for astrological calculations.

Related MCP server: VedAstro MCP Server

🏛️ Architecture & Layering

                     [ Client / Agent Request ]
                                 │
                 ┌───────────────┼───────────────┐
                 ▼               ▼               ▼
          Stdio MCP Server   Python CLI     Agent Skill
          (11 Tools/JSON)   (Scripts/Lib)   (SKILL.md)
                 │               │               │
                 └───────────────┬───────────────┘
                                 │
                                 ▼
                     ┌───────────────────────┐
                     │   Astro Core Engine   │
                     │  (Swiss Ephemeris     │
                     │   + Lahiri Ayanamsa)  │
                     └───────────┬───────────┘
                                 │
                 ┌───────────────┴───────────────┐
                 ▼                               ▼
       [ Structured JSON ]            [ In-Process ReportLab PDF ]
       - 12 Bhavas, Grahas, Yogas     - Lagna & Navamsa (D1/D9)
       - Vimshottari Timeline         - Devanagari Hindi/English
       - Gochar & Guna Milan          - Dasha Strips & Panchang

✨ Core Capabilities

Category	Features & Astrological Foundations
Kundali (D1 & D9)	Lagna, Rashi, Nakshatra + Pada, 9 Grahas with true retrograde flags, whole-sign houses, and high-precision Navamsa (D9) divisional chart.
Planetary Strengths	Classical dignity, Digbala, Vargottama, Combustion (Asta), Graha Yuddha, and Lagna-specific functional benefic / malefic classifications.
Classical Yogas	Gajakesari, Budhaditya, Pancha Mahapurusha, Raja Yogas, Neechabhanga, Vipreet (Harsha/Sarala/Vimala), Kaal Sarp (full/partial), Parivartana (Maha/Khala/Dainya) — with classical cancellation checks.
12-House Bhava Analysis	House lords with placement & strength, occupants, Parashari planetary aspects (Drishti), and Bhava Karakas.
Vimshottari Dasha	Mahadasha, Antardasha, and Pratyantardasha timelines with true astronomical birth-balance handling.
Daily Panchang	Sunrise-anchored Tithi, Vara, Nakshatra, Yoga, Karana, Sunrise/Sunset, auspicious Muhurtas, and Anandadi/Amrit yogas.
Gochar (Transits)	Real-time planetary transits mapped against natal Moon and Lagna, with retrograde indicators and Saturn Sade Sati tracking.
Guna Milan (Matchmaking)	Complete 36-point Ashtakoot compatibility scoring with Nadi, Bhakoot, Gana, and Mangalik Dosha analysis.
Classical Remedies	Prioritized mantras, gemstones, fasting days, daan (charity), and rituals in bilingual Hindi/English.

🚀 Quick Start

1. Install from PyPI

pip install astro-skill

Requires Python 3.11+.

2. Run the Stdio MCP Server

astro-mcp
# or: python -m services.astro_mcp

3. CLI Command Examples

# Calculate Birth Kundali (JSON output)
python -m astro.scripts.kundali_calculator --dob 26/12/2019 --tob 09:15 \
  --place Delhi --lat 28.6139 --lon 77.2090 --timezone Asia/Kolkata --json

# Calculate Vimshottari Dasha Timeline
python -m astro.scripts.dasha_calculator --kundali-json chart.json --json

# Daily Panchang
python -m astro.scripts.panchang_calculator --date 2026-05-21 \
  --place Delhi --lat 28.6139 --lon 77.209 --timezone Asia/Kolkata --json

# Ashtakoot Guna Milan (Compatibility)
python -m astro.scripts.guna_milan --kundali-a-json person_a.json --kundali-b-json person_b.json --json

# Generate Factual Bilingual PDF Report
python -m astro.scripts.pdf_report --kundali-json chart.json --dasha-json dasha.json \
  --panchang-json panchang.json --output report.pdf --language hi

4. Python Library Usage

from astro.scripts.kundali_calculator import calculate_kundali

kundali = calculate_kundali(
    dob="15/08/1990",
    tob="14:30",
    place="Mumbai",
    lat=19.0760,
    lon=72.8777,
    tz_str="Asia/Kolkata"
)

print(f"Lagna: {kundali['lagna']['sign_name']}, Nakshatra: {kundali['nakshatra']['name']}")

🤖 MCP Server Setup

The built-in MCP server exposes 11 tools over stdio. It includes SQLite client profile management and report generation out of the box.

📋 Available MCP Tools (11)

Tool Name	Description
`parse_birth_details`	Parse conversational birth-detail strings into structured ISO date/time and coordinates.
`save_client_profile`	Upsert client profile and birth parameters into local SQLite database.
`find_client_profile`	Search client by `client_id` or name substring.
`list_client_reports`	Retrieve previously generated reports for a client.
`calculate_kundali`	Compute complete Lahiri/whole-sign Kundali, Navamsa (D9), yogas, and bhava data.
`calculate_dasha`	Compute Vimshottari Mahadasha + Antardasha timeline with exact birth balance.
`calculate_gochar`	Compute transit chart and Sade Sati status for any target date.
`calculate_compatibility`	36-point Ashtakoot Guna Milan compatibility score between two charts.
`calculate_panchang`	Daily sunrise-anchored Panchang (Tithi, Vara, Nakshatra, Yoga, Karana).
`generate_report_json`	Compile an all-in-one structured astrology draft JSON.
`generate_pdf_report`	Render a clean, printable PDF report using in-process ReportLab.

⚙️ Client Configurations

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "astro": {
      "command": "astro-mcp"
    }
  }
}

Cursor (`settings.json` / MCP Config)

{
  "mcpServers": {
    "astro": {
      "command": "python",
      "args": ["-m", "services.astro_mcp"],
      "cwd": "C:/path/to/astro-skill"
    }
  }
}

👑 Pro Report Tier

This repository contains the open-core deterministic engine — mathematical calculations, structured JSON schemas, and factual ReportLab PDFs.

For astrologers, consultancies, and consumer apps seeking client-ready, beautifully designed Janma Patrikas, a Pro Report Tier is available:

📖 Pandit-Grade LLM Synthesis: Deep house-by-house, dasha-by-dasha, and transit narrative analysis in Hindi, English, or Hinglish.
🎨 Premium Print-Ready Layout: Multi-page styled Janma Patrika with rich cover pages, divisional charts, and branded styling.
⚡ Prioritized Actionable Remedies: Context-aware Gemstone, Mantra, Yantra, and Daan suggestions tailored to running dasha periods.

📩 Interested in licensing the Pro Tier or API? Contact: adityaryawork@gmail.com

🛠️ Development & Testing

git clone https://github.com/adityarya24/astro-skill.git
cd astro-skill
python -m venv .venv
source .venv/bin/activate  # Windows: .\.venv\Scripts\Activate.ps1
pip install -e ".[dev]"

# Run full test suite (154 tests)
pytest -q

# Linter & format check
ruff check astro services scripts

🛡️ Safety Boundaries

Calculation-Backed Drafts: Reports are mathematical baselines intended for review by an astrologer or operator before sharing.
Missing Birth Details: Never guess or synthesize birth times or locations; prompt the user if inputs are missing.
Ethical Guardrails: Strictly prohibits generating fatalistic claims, death timing, medical diagnoses, or unavoidable harm predictions.

📜 License

Available Tools

10 tools

calculate_compatibilityGuna Milan CompatibilityA

Read-only

Guna Milan (Ashtakoot, 36-point) marriage compatibility between two kundali JSONs (kundali_a = bride, kundali_b = groom). Returns the koota-wise point breakdown, the total out of 36, and Nadi, Bhakoot, and Manglik dosha findings.

ParametersJSON Schema

Name	Required	Description	Default
`kundali_a`	Yes	Bride's kundali JSON from calculate_kundali.
`kundali_b`	Yes	Groom's kundali JSON from calculate_kundali.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, and the description confirms it returns computed results without side effects. It adds behavioral detail beyond annotations (e.g., expects specific kundali JSONs, returns dosha findings). No contradictions.

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

Conciseness5/5

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

Two sentences: first states the primary function and expected inputs, second lists the outputs. Every word is informative, no filler, front-loaded with the core purpose.

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?

Despite no output schema, the description enumerates the key outputs (koota-wise breakdown, total, dosha findings). Combined with good annotations and schema coverage, the description fully conveys what the tool does and returns.

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 already describes both parameters (kundali_a and kundali_b) with 100% coverage. The description adds value by explicitly labeling the roles (bride/groom) and specifying the source (calculate_kundali), which clarifies intended usage beyond the schema.

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 description clearly states that the tool calculates Guna Milan (Ashtakoot) marriage compatibility between two kundali JSONs, specifying the roles (bride and groom) and the output (koota-wise breakdown, total out of 36, and dosha findings). It distinguishes from sibling tools like calculate_kundali, calculate_dasha, etc., which serve different purposes.

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 description implies usage after calculate_kundali by referencing 'kundali JSON from calculate_kundali'. It provides clear context for when to use (marriage compatibility), but does not explicitly mention when to avoid or name alternatives, though it is self-evident among siblings.

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

calculate_dashaCalculate Vimshottari DashaA

Read-only

Compute the Vimshottari dasha timeline from a kundali: mahadasha and antardasha periods with start/end dates, plus the running mahadasha/antardasha/pratyantardasha for on_date. Returns dasha JSON accepted by the report tools.

ParametersJSON Schema

Name	Required	Description	Default
`kundali`	Yes	Kundali JSON exactly as returned by the calculate_kundali tool.
`on_date`	No	YYYY-MM-DD date to report the running period for (default: today).

TDQS

A4.2/5.0

Behavior4/5

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

Adds context beyond readOnlyHint by stating output is accepted by report tools, aiding chaining. No contradictions with annotations.

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

Conciseness5/5

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

Two sentences, front-loads purpose and output usage, no wasted words.

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

Completeness4/5

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

Covers main purpose, output acceptance, optional parameter. No output schema, but references report tools to imply structure. Sufficient for chaining.

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 covers 100% of parameters with good descriptions. Description only briefly mentions on_date and output format, adding minimal value beyond schema.

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?

Description specifies the tool computes Vimshottari dasha timeline from a kundali, listing outputs (mahadasha/antardasha periods with dates, running periods for on_date). Distinguishes from siblings like calculate_kundali, calculate_gochar, calculate_panchang.

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?

Indicates tool is used after calculate_kundali and its output feeds report tools. Provides clear context for use but does not explicitly exclude alternative use cases.

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

calculate_gocharCalculate Gochar (Transits)A

Read-only

Compute gochar — planetary transits relative to the natal Moon and Lagna — plus the Saturn Sade Sati / Dhaiya phase for a date. Returns gochar JSON accepted by the report tools.

ParametersJSON Schema

Name	Required	Description	Default
`kundali`	Yes	Kundali JSON exactly as returned by the calculate_kundali tool.
`on_date`	No	YYYY-MM-DD date to compute transits for (default: today).

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true. The description adds that it computes transits and returns JSON for reports, which aligns with annotations. No additional behavioral traits disclosed beyond the schema and annotations.

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

Conciseness5/5

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

Two sentences, no fluff, directly stating purpose and output format. Every sentence earns its place.

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

Completeness4/5

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

Given no output schema, the description specifies the output is gochar JSON for report tools. It explains what is computed (transits and Sade Sati/Dhaiya). For a calculator tool, this is largely complete.

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 coverage is 100%, so baseline is 3. The description notes that kundali should be from calculate_kundali and on_date defaults to today, marginally adding context already present in schema.

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 description clearly specifies the tool computes gochar (planetary transits) relative to natal Moon and Lagna, plus Saturn Sade Sati/Dhaiya. It distinguishes from sibling tools like calculate_kundali and calculate_dasha by focusing on transits.

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 description mentions the output is accepted by report tools, implying a use case for report generation, but does not explicitly state when to use this tool versus alternatives like calculate_panchang.

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

calculate_kundaliCalculate Kundali (Birth Chart)A

Read-only

Compute a sidereal Vedic kundali (birth chart) from birth details: lagna, Moon rashi, nakshatra with pada, planet positions with sign and whole-sign house placements, navamsa (D9) and further divisional charts, ashtakavarga tables, and the Vimshottari dasha seed. Returns the kundali JSON that the dasha, gochar, compatibility, and report tools consume.

ParametersJSON Schema

Name	Required	Description	Default
`dob`	Yes	Date of birth, DD/MM/YYYY or YYYY-MM-DD.
`lat`	Yes	Latitude of the birth place in decimal degrees (north positive).
`lon`	Yes	Longitude of the birth place in decimal degrees (east positive).
`tob`	Yes	Time of birth, HH:MM (24-hour clock), local time at the birth place.
`place`	Yes	Birth place name; a label for output, not geocoded.
`ayanamsa`	No	Sidereal ayanamsa to calculate with. Default is Lahiri (Chitrapaksha).	lahiri
`timezone_name`	Yes	IANA timezone of the birth place, e.g. Asia/Kolkata.

TDQS

A4.5/5.0

Behavior5/5

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

The description discloses detailed output (lagna, Moon rashi, navamsa, etc.) and states the return format is JSON consumed by other tools. The annotations already indicate readOnlyHint=true, and the description adds significant behavioral context beyond that.

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

Conciseness5/5

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

The description is two sentences, front-loaded with purpose, and every sentence adds value. No wasted words.

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?

The description fully explains the outputs and their consumption by other tools, compensating for the lack of output schema. It gives a complete picture of the tool's role in the workflow.

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 coverage is 100%, so the description does not need to elaborate on parameters. The description adds overall context but no per-parameter extra meaning beyond what the schema provides, meeting the baseline for high coverage.

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 description clearly states the tool computes a sidereal Vedic kundali from birth details, enumerates specific outputs (lagna, Moon rashi, etc.), and mentions the output is consumed by other tools. It distinguishes itself from siblings by specifying the relationships with dasha, gochar, compatibility, and report tools.

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 description implies the tool is used to compute the initial birth chart for downstream tools, and the sibling tool list provides context. However, it does not explicitly state when to use this vs alternatives or when not to use it, lacking explicit guidance.

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

calculate_panchangCalculate PanchangA

Read-only

Compute the daily Panchang for a place and date: vara, tithi, nakshatra, yoga, karana, and sunrise/sunset times. Returns panchang JSON accepted by the report tools.

ParametersJSON Schema

Name	Required	Description	Default
`lat`	Yes	Latitude in decimal degrees.
`lon`	Yes	Longitude in decimal degrees.
`date`	Yes	YYYY-MM-DD date for the Panchang.
`place`	Yes	Place name; a label for output, not geocoded.
`ayanamsa`	No	Sidereal ayanamsa to calculate with. Default is Lahiri (Chitrapaksha).	lahiri
`timezone_name`	Yes	IANA timezone of the place, e.g. Asia/Kolkata.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true, so description's 'Compute' is consistent. The description adds no significant behavioral disclosure beyond what annotations provide, e.g., no mention of no side effects or required permissions.

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

Conciseness5/5

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

Two sentences, front-loaded with key purpose and output details, no redundant text. Every sentence adds value.

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

Completeness4/5

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

The tool has 6 parameters and no output schema. The description explains the return content (panchang JSON with specific fields) and its compatibility with report tools. However, it does not explicitly state that the output can be used as input to report tools, and the ayanamsa parameter is not elaborated beyond schema. Still fairly complete.

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 coverage is 100% with descriptions for all parameters. The description does not add meaning beyond the schema; it briefly mentions place and date but does not explain parameters like ayanamsa. Baseline score of 3 applies.

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 description clearly states the tool computes daily Panchang for a given place and date, listing specific components (vara, tithi, nakshatra, yoga, karana, sunrise/sunset) and noting the output format is compatible with report tools. This distinguishes it from siblings like calculate_kundali or calculate_dasha.

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

Usage Guidelines3/5

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

The description implies usage for daily Panchang calculation but does not explicitly state when to use or not use this tool vs siblings. It provides no guidance on alternatives or prerequisites.

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

find_client_profileFind Client ProfileA

Read-only

Look up a client profile by exact client_id, otherwise by case-insensitive display_name substring. Returns the profile, or null when nothing matches.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	client_id, or part of the display name.
`db_path`	No	Path of the SQLite client store (default: data/astro_mcp.sqlite3). Must resolve inside the server working directory, the system temp directory, or ASTRO_MCP_BASE_DIR; other paths are rejected.

TDQS

A4.4/5.0

Behavior4/5

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

The description is consistent with the readOnlyHint=true annotation, confirming it is a read-only operation. It discloses the matching logic (exact then substring) and the null return case. No contradictions with annotations.

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

Conciseness5/5

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

The description is extremely concise with two sentences that front-load the core action 'Look up'. Every word serves a purpose, with no redundancy or filler.

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

Completeness4/5

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

The description adequately explains the tool's purpose and behavior for a lookup without an output schema. It mentions the return type (profile or null), which is sufficient. However, it could optionally hint at the profile structure, but that is not critical.

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?

Although the schema already describes the query parameter as 'client_id, or part of the display name', the description adds value by explicitly stating the exact match priority and case-insensitive substring fallback. This goes beyond the schema's minimal description.

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 description clearly states the tool's function: looking up a client profile by exact client_id or case-insensitive display_name substring. It specifies the return behavior (profile or null) and distinguishes it from sibling tools like save_client_profile (write) and list_client_reports (list).

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 description provides clear context on when to use this tool (lookup by client_id or display_name substring) but does not explicitly mention when not to use it or offer comparisons to alternative tools like search. However, the matching logic is well-explained.

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

generate_pdf_reportGenerate PDF ReportA

Render a client-facing PDF report (cover, Lagna/Navamsa charts, planet table, dasha timeline) from a kundali plus optional sections, using the in-process ReportLab renderer. Returns the report record with the path of the written PDF.

ParametersJSON Schema

Name	Required	Description	Default
`brand`	No	Optional white-label footer text. Empty keeps the report's neutral footer.
`dasha`	No	Optional dasha JSON from calculate_dasha; adds the dasha timeline section.
`gochar`	No	Optional gochar JSON from calculate_gochar; adds the transit section.
`db_path`	No	SQLite store to record the report in; when omitted the report is only written to disk. Must resolve inside the server working directory, the system temp directory, or ASTRO_MCP_BASE_DIR; other paths are rejected.
`kundali`	Yes	Kundali JSON exactly as returned by the calculate_kundali tool.
`language`	No	Report language: 'hin' or 'hi' for Hindi (Devanagari), 'en' for English.	hin
`panchang`	No	Optional panchang JSON from calculate_panchang; adds the panchang section.
`renderer`	No	PDF rendering backend. Only the pure-Python ReportLab renderer is supported.	reportlab
`template`	No	PDF layout. Only the standard factual report template is supported.	standard
`client_id`	No	Client identifier the report is filed under.	anonymous
`output_dir`	No	Directory the report file is written into (default: data/reports). Must resolve inside the server working directory, the system temp directory, or ASTRO_MCP_BASE_DIR; other paths are rejected.
`client_name`	No	Client/native name shown on the PDF cover page

TDQS

A4/5.0

Behavior4/5

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

The description discloses the action (writes PDF to disk, optionally records in SQLite) and the return value. Annotations show no destructive or read-only hints, and the description does not contradict them. However, it does not mention potential side effects like overwriting files or required permissions.

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?

The description is a single sentence that front-loads the tool's purpose and key output. It is concise, but could be better structured to separate required and optional parts.

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

Completeness3/5

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

Given the tool's complexity (12 parameters, nested objects, no output schema), the description is relatively brief. It mentions the return value but lacks detail on error conditions, prerequisites beyond having a kundali, or the behavior of the optional sections.

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?

The input schema has 100% description coverage for all parameters. The tool description adds context about the overall flow and mentions the renderer, but it does not significantly enhance understanding of individual parameters beyond the schema descriptions.

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 description states a specific action (render a PDF report), lists key sections (cover, charts, planet table, dasha timeline), and identifies the input (kundali) and optional additions. It clearly distinguishes from sibling tools which perform calculations or data management.

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 description implicitly indicates when to use this tool (to generate a PDF from a kundali) and mentions optional sections from other tools (dasha, gochar, panchang). However, it does not explicitly state when not to use it or provide alternatives beyond the implied prerequisite calculations.

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

list_client_reportsList Client ReportsA

Read-only

List report records previously generated for a client, newest first. Each record carries report_id, report_type, path, and created_at.

ParametersJSON Schema

Name	Required	Description	Default
`db_path`	No	Path of the SQLite client store (default: data/astro_mcp.sqlite3). Must resolve inside the server working directory, the system temp directory, or ASTRO_MCP_BASE_DIR; other paths are rejected.
`client_id`	Yes	Client identifier whose reports to list.

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the agent knows it is safe. The description adds valuable behavioral context (newest first ordering, fields returned), complementing annotations without contradiction.

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

Conciseness5/5

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

Two sentences, no wasted words, front-loaded with the core purpose.

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

Completeness4/5

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

Given the tool's simplicity (2 params, no output schema), the description adequately conveys the return fields and ordering. It is slightly lacking in edge-case behavior (e.g., empty result handling), but overall complete.

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?

The input schema covers 100% of parameters with descriptions. The tool description does not add further meaning beyond what the schema already provides.

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 description states a specific verb (List), resource (report records), and scope (for a client, ordered newest first). It clearly distinguishes from sibling tools like generate_pdf_report or parse_birth_details.

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

Usage Guidelines3/5

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

The description implies usage for listing existing reports for a client but does not explicitly state when to use or when not to use this tool, nor does it mention alternatives.

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

parse_birth_detailsParse Birth DetailsA

Read-only

Conservatively extract dob, tob, place, lat, lon, and timezone from a short operator note. Returns the recognised fields plus a 'missing' list naming everything that could not be parsed, so the agent can ask the operator for clarification instead of guessing.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Free-form note with birth details, e.g. 'born 26 Dec 2019, 9:15 am, Delhi'.

TDQS

A4.2/5.0

Behavior4/5

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

Beyond annotations (readOnlyHint: true), the description discloses conservative extraction and the return of a missing list. No contradictions with annotations. It adds context about handling unparseable fields.

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

Conciseness5/5

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

Two sentences, front-loaded with action and outcome. Every sentence adds value with no fluff.

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

Completeness4/5

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

For a single-parameter tool with no output schema, the description adequately explains the return value (recognized fields + missing list) and the conservative behavior. The context with sibling tools clarifies its role as a prerequisite for calculations.

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 coverage is 100% with a clear example for the 'text' parameter. The description does not add new parameter-specific meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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 description clearly states the tool extracts specific fields (dob, tob, place, lat, lon, timezone) from a short operator note. The verb 'extract' and resource 'birth details' are specific, and the tool is distinct from sibling calculation tools.

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 description implies use for parsing birth details before calculations, and emphasizes conservative parsing with a missing list to avoid guessing. However, it does not explicitly state when not to use or list alternatives.

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

save_client_profileSave Client ProfileA

DestructiveIdempotent

Create or update (upsert by client_id) a client profile in the SQLite store, optionally with birth details. Returns the saved profile.

ParametersJSON Schema

Name	Required	Description	Default
`db_path`	No	Path of the SQLite client store (default: data/astro_mcp.sqlite3). Must resolve inside the server working directory, the system temp directory, or ASTRO_MCP_BASE_DIR; other paths are rejected.
`profile`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations indicate destructiveHint=true and idempotentHint=true, and the description confirms upsert behavior and return of saved profile. However, it does not elaborate on what destructive actions occur (e.g., overwriting existing data) or any rate limits.

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

Conciseness5/5

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

The description is a single sentence that covers key aspects (upsert, storage, optional birth details, return value) without any redundant or vague language.

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

Completeness4/5

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

The description covers the essential behavior and return value, but lacks details on the format of the returned profile or handling of the db_path parameter. Given the absence of an output schema, a bit more detail on the return value would be helpful.

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 coverage is 50%, and the description adds little beyond the schema: it mentions 'optionally with birth details' and implies db_path usage but does not describe parameter formats or constraints not already in the schema.

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 description explicitly states it performs an upsert (create or update) on a client profile in the SQLite store, with optional birth details, and returns the saved profile. This clearly distinguishes it from sibling tools like parse_birth_details or calculation tools.

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

Usage Guidelines3/5

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

The description mentions the upsert behavior and optional birth details but provides no explicit guidance on when to use this tool versus siblings like parse_birth_details or when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv2.0.0Jul 26, 2026
- Addedfind_client_profile
- Addedgenerate_pdf_report
- Addedlist_client_reports
8 tool updatesv1.1.1Jul 23, 2026
- Addedcalculate_compatibility
- Addedcalculate_dasha
- Addedcalculate_gochar
- Addedcalculate_kundali
- Addedcalculate_panchang
- Removedlist_client_reports
- Addedparse_birth_details
- Addedsave_client_profile
3 tool updatesv1.1.0Jul 18, 2026
- Removedcalculate_gochar
- Addedlist_client_reports
- Removedsave_client_profile
10 tool updatesv1.1.0Jul 18, 2026
- Removedcalculate_compatibility
- Removedcalculate_dasha
- Removedcalculate_kundali
- Removedcalculate_panchang
- Removedfind_client_profile
- Removedgenerate_pdf_report
- Removedgenerate_report_json
- Removedlist_client_reports
- Removedparse_birth_details
- Changedsave_client_profile1 field changed
  - changedInput schema / properties / db_path / description
```
Previous value: -"Path of the SQLite client store (default: data/astro_mcp.sqlite3)."New value: +"Path of the SQLite client store (default: data/astro_mcp.sqlite3). Must resolve inside the server working directory, the system temp directory, or ASTRO_MCP_BASE_DIR; other paths are rejected."
```

11 tool updatesv1.0.1Jul 13, 2026

Changedcalculate_compatibility2 fields changed
- addedInput schema / properties / kundali_a / description
```
Added value: +"Bride's kundali JSON from calculate_kundali."
```
- addedInput schema / properties / kundali_b / description
```
Added value: +"Groom's kundali JSON from calculate_kundali."
```

Changedcalculate_dasha2 fields changed

addedInput schema / properties / kundali / description

Added value: +"Kundali JSON exactly as returned by the calculate_kundali tool."

changedInput schema / properties / on_date / description

Previous value: -"YYYY-MM-DD"New value: +"YYYY-MM-DD date to report the running period for (default: today)."

Changedcalculate_gochar2 fields changed

addedInput schema / properties / kundali / description

Added value: +"Kundali JSON exactly as returned by the calculate_kundali tool."

changedInput schema / properties / on_date / description

Previous value: -"YYYY-MM-DD (default: today)"New value: +"YYYY-MM-DD date to compute transits for (default: today)."

Changedcalculate_kundali8 fields changed

addedInput schema / properties / ayanamsa / description

Added value: +"Sidereal ayanamsa to calculate with. Default is Lahiri (Chitrapaksha)."

addedInput schema / properties / ayanamsa / enum

Added value: +[
+  "lahiri",
+  "chitrapaksha",
+  "raman",
+  "krishnamurti",
+  "kp",
+  "fagan_bradley",
+  "true_chitra",
+  "yukteshwar"
+]

addedInput schema / properties / dob / description

Added value: +"Date of birth, DD/MM/YYYY or YYYY-MM-DD."

addedInput schema / properties / lat / description

Added value: +"Latitude of the birth place in decimal degrees (north positive)."

addedInput schema / properties / lon / description

Added value: +"Longitude of the birth place in decimal degrees (east positive)."

addedInput schema / properties / place / description

Added value: +"Birth place name; a label for output, not geocoded."

addedInput schema / properties / timezone_name / description

Added value: +"IANA timezone of the birth place, e.g. Asia/Kolkata."

addedInput schema / properties / tob / description

Added value: +"Time of birth, HH:MM (24-hour clock), local time at the birth place."

Changedcalculate_panchang7 fields changed

addedInput schema / properties / ayanamsa / description

Added value: +"Sidereal ayanamsa to calculate with. Default is Lahiri (Chitrapaksha)."

addedInput schema / properties / ayanamsa / enum

Added value: +[
+  "lahiri",
+  "chitrapaksha",
+  "raman",
+  "krishnamurti",
+  "kp",
+  "fagan_bradley",
+  "true_chitra",
+  "yukteshwar"
+]

changedInput schema / properties / date / description

Previous value: -"YYYY-MM-DD"New value: +"YYYY-MM-DD date for the Panchang."

addedInput schema / properties / lat / description
```
Added value: +"Latitude in decimal degrees."
```
addedInput schema / properties / lon / description
```
Added value: +"Longitude in decimal degrees."
```

addedInput schema / properties / place / description

Added value: +"Place name; a label for output, not geocoded."

addedInput schema / properties / timezone_name / description

Added value: +"IANA timezone of the place, e.g. Asia/Kolkata."

Changedfind_client_profile2 fields changed
- addedInput schema / properties / db_path / description
```
Added value: +"Path of the SQLite client store (default: data/astro_mcp.sqlite3)."
```
- addedInput schema / properties / query / description
```
Added value: +"client_id, or part of the display name."
```

Changedgenerate_pdf_report12 fields changed

addedInput schema / properties / client_id / description

Added value: +"Client identifier the report is filed under."

addedInput schema / properties / client_name

Added value: +{
+  "description": "Client/native name shown on the PDF cover page",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / dasha / description

Added value: +"Optional dasha JSON from calculate_dasha; adds the dasha timeline section."

addedInput schema / properties / db_path / description

Added value: +"SQLite store to record the report in; when omitted the report is only written to disk."

addedInput schema / properties / gochar

Added value: +{
+  "description": "Optional gochar JSON from calculate_gochar; adds the transit section.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedInput schema / properties / kundali / description

Added value: +"Kundali JSON exactly as returned by the calculate_kundali tool."

addedInput schema / properties / language / description

Added value: +"Report language: 'hin' or 'hi' for Hindi (Devanagari), 'en' for English."

addedInput schema / properties / language / enum

Added value: +[
+  "hin",
+  "hi",
+  "en"
+]

addedInput schema / properties / output_dir / description

Added value: +"Directory the report file is written into (default: data/reports)."

addedInput schema / properties / panchang / description

Added value: +"Optional panchang JSON from calculate_panchang; adds the panchang section."

addedInput schema / properties / renderer / description

Added value: +"'html' renders via Chromium/Playwright (best Devanagari shaping); 'reportlab' needs no browser."

addedInput schema / properties / template / description

Added value: +"'standard' report, or 'pandit_v1' — the premium Hindi janma-patrika layout (requires renderer='html')."

Changedgenerate_report_json9 fields changed

addedInput schema / properties / client_id / description

Added value: +"Client identifier the report is filed under."

addedInput schema / properties / dasha / description

Added value: +"Optional dasha JSON from calculate_dasha; adds the dasha timeline section."

addedInput schema / properties / db_path / description

Added value: +"SQLite store to record the report in; when omitted the report is only written to disk."

addedInput schema / properties / gochar / description

Added value: +"Optional gochar JSON from calculate_gochar; adds the transit section."

addedInput schema / properties / kundali / description

Added value: +"Kundali JSON exactly as returned by the calculate_kundali tool."

addedInput schema / properties / language / description

Added value: +"Report language: 'hin' or 'hi' for Hindi (Devanagari), 'en' for English."

addedInput schema / properties / language / enum

Added value: +[
+  "hin",
+  "hi",
+  "en"
+]

addedInput schema / properties / output_dir / description

Added value: +"Directory the report file is written into (default: data/reports)."

addedInput schema / properties / panchang / description

Added value: +"Optional panchang JSON from calculate_panchang; adds the panchang section."

Changedlist_client_reports2 fields changed
- addedInput schema / properties / client_id / description
```
Added value: +"Client identifier whose reports to list."
```
- addedInput schema / properties / db_path / description
```
Added value: +"Path of the SQLite client store (default: data/astro_mcp.sqlite3)."
```

Changedparse_birth_details1 field changed

addedInput schema / properties / text / description

Added value: +"Free-form note with birth details, e.g. 'born 26 Dec 2019, 9:15 am, Delhi'."

Changedsave_client_profile6 fields changed

addedInput schema / properties / db_path / description

Added value: +"Path of the SQLite client store (default: data/astro_mcp.sqlite3)."

changedInput schema / properties / profile / properties / birth / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "dob": {
-        "description": "DD/MM/YYYY or YYYY-MM-DD",
-        "type": "string"
-      },
-      "lat": {
-        "type": "number"
-      },
-      "lon": {
-        "type": "number"
-      },
-      "place": {
-        "type": "string"
-      },
-      "timezone_name": {
-        "description": "IANA name, eg Asia/Kolkata",
-        "type": "string"
-      },
-      "tob": {
-        "description": "HH:MM (24h) local time",
-        "type": "string"
-      }
-    },
-    "required": [
-      "dob",
-      "tob",
-      "place",
-      "lat",
-      "lon",
-      "timezone_name"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "dob": {
+        "description": "Date of birth, DD/MM/YYYY or YYYY-MM-DD.",
+        "type": "string"
+      },
+      "lat": {
+        "description": "Latitude of the birth place in decimal degrees (north positive).",
+        "type": "number"
+      },
+      "lon": {
+        "description": "Longitude of the birth place in decimal degrees (east positive).",
+        "type": "number"
+      },
+      "place": {
+        "description": "Birth place name; a label for output, not geocoded.",
+        "type": "string"
+      },
+      "timezone_name": {
+        "description": "IANA timezone of the birth place, e.g. Asia/Kolkata.",
+        "type": "string"
+      },
+      "tob": {
+        "description": "Time of birth, HH:MM (24-hour clock), local time at the birth place.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "dob",
+      "tob",
+      "place",
+      "lat",
+      "lon",
+      "timezone_name"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / profile / properties / birth / description
```
Added value: +"Birth details to store with the profile."
```
addedInput schema / properties / profile / properties / client_id / description
```
Added value: +"Stable unique identifier for the client."
```
addedInput schema / properties / profile / properties / display_name / description
```
Added value: +"Human-readable client name."
```
addedInput schema / properties / profile / properties / notes / description
```
Added value: +"Free-form notes about the client."
```

11 tool updatesv1.0.0Jul 13, 2026
- First observedcalculate_compatibility
- First observedcalculate_dasha
- First observedcalculate_gochar
- First observedcalculate_kundali
- First observedcalculate_panchang
- First observedfind_client_profile
- First observedgenerate_pdf_report
- First observedgenerate_report_json
- First observedlist_client_reports
- First observedparse_birth_details
- First observedsave_client_profile

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool serves a unique and clearly distinct purpose: parsing birth details, calculating various astrological charts and their components, compatibility, daily panchang, and client profile management. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., 'parse_birth_details', 'calculate_kundali', 'save_client_profile'). The verbs vary appropriately for the action, and the naming is predictable and clear.

Tool Count5/5

With 7 tools, the set is well-scoped for an astrological server. It covers core workflows (birth detail parsing, chart calculation, dasha, transits, compatibility, daily panchang, and client profile) without being bloated or sparse.

Completeness5/5

The tool set provides a complete lifecycle for astrological analysis: parsing raw input, generating a kundali and its subdivisions, computing timelines and transits, assessing compatibility, and saving client profiles. No obvious gaps are present.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

VedaVisor Vedic Astrology MCP A
io.github.dchhill
Professional Vedic astrology tools for AI agents via MCP.
Entertainment & Media
3
Divine API - Indian / Vedic AstrologyOAuth
com.divineapi
Official Divine API MCP for Indian/Vedic Astrology: Panchang, Kundli, Dasha, KP, Lal Kitab.
Research & Data
2
Vedic Astrology and Kundli MCP Server by RoxyAPI A
com.roxyapi
Vedic kundli, panchang, dashas, nakshatras and KP charts for AI agents, one API key.
Art & Culture
552
Birthstar Vedic Astrology MCP A
io.github.amarpathak
30 Vedic Jyotish tools: natal charts, dashas, yogas, nakshatras. Swiss Ephemeris.
Art & Culture
301

Related MCP Servers

VedAstro MCP Server
AI & Machine Learning Search
VedAstro
F
license
Not graded
quality
D
maintenance
World's first Vedic Astrology MCP Server — connect Claude, ChatGPT, Cursor, or any AI to real Vedic astrology. Provides horoscope predictions, compatibility matching, numerology, planetary positions, yogas and house analysis via MCP.
Updated 5 months ago (2026-03-25 22:21 UTC)
8
-
VedAstro MCP Server
Research & Data
VedAstro
A
license
A
quality
C
maintenance
Vedic astrology MCP server providing 6 tools: horoscope predictions (200+ life aspects), compatibility match reports with Kuta scoring, Chaldean numerology, raw planet and house chart data, 24 general astro properties, and Ashtakvarga charts. Free tier included with no API key required, premium unlimited tier also available
Updated 25 days ago (2026-08-13 15:17 UTC)
3
627
MIT
kundali-mcp
Research & Data
mrishabh7
F
license
Not graded
quality
C
maintenance
A Vedic astrology MCP server that computes birth charts, dashas, transits, and yogas locally using Swiss Ephemeris, enabling an LLM to interpret horoscopes and provide personalized advice.
Updated 2 months ago (2026-06-26 15:57 UTC)
-
astromock-mcp
Research & Data
Anshiika123
A
license
Not graded
quality
C
maintenance
Exposes Vedic astrology tools for birth chart, dasha, transit calculations, and question context analysis.
Updated 2 months ago (2026-07-13 14:50 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adityarya24/astro-skill'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🌌 Astro Skill

🎯 Overview

🏛️ Architecture & Layering

✨ Core Capabilities

🚀 Quick Start

1. Install from PyPI

2. Run the Stdio MCP Server

3. CLI Command Examples

4. Python Library Usage

🤖 MCP Server Setup

📋 Available MCP Tools (11)

⚙️ Client Configurations

Claude Desktop (claude_desktop_config.json)

Cursor (settings.json / MCP Config)

👑 Pro Report Tier

🛠️ Development & Testing

🛡️ Safety Boundaries

📜 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Claude Desktop (`claude_desktop_config.json`)

Cursor (`settings.json` / MCP Config)