Skip to main content
Glama
adityarya24

Astro Skill MCP Server

by adityarya24
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Generate JSON Report

generate_report_json

Assemble a structured astrology report draft (birth chart summary plus optional dasha/panchang/gochar sections) and write it to disk as JSON. Returns the report record: report_id, path of the written file, client_id, and created_at.

Instructions

Assemble a structured astrology report draft (birth chart summary plus optional dasha/panchang/gochar sections) and write it to disk as JSON. Returns the report record: report_id, path of the written file, client_id, and created_at.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dashaNoOptional dasha JSON from calculate_dasha; adds the dasha timeline section.
gocharNoOptional gochar JSON from calculate_gochar; adds the transit section.
db_pathNoSQLite 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.
kundaliYesKundali JSON exactly as returned by the calculate_kundali tool.
languageNoReport language: 'hin' or 'hi' for Hindi (Devanagari), 'en' for English.hin
panchangNoOptional panchang JSON from calculate_panchang; adds the panchang section.
client_idNoClient identifier the report is filed under.anonymous
output_dirNoDirectory 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_nameNoClient/native name shown on the PDF cover page
gochar_narrativeNoOptional gochar narrative JSON from build_antardasha_gochar_narrative. If missing, it will be computed automatically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.1
  2. Removedv1.1.0
  3. Changed9 schema fields changedv1.0.1
    • 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."
  4. First observedv1.0.0

TDQS

A4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=false; the description goes beyond them by disclosing the side effect (a JSON file is written to disk) and the returned record fields (report_id, path, client_id, created_at), which matters since no output schema exists. It does not explain non-idempotency, i.e. whether repeated calls create duplicate reports.

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, both load-bearing: the first covers the action and its output artifact, the second covers the return shape. Nothing is repeated from the title or schema.

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 10-parameter write tool with no output schema, the description supplies the return fields and the disk-write behavior, and the schema covers all parameters. Remaining gaps are behavioral edge cases (file naming/overwrite behavior, duplicate-report behavior on repeat invocation) rather than anything needed to call it.

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%, so the schema already documents path restrictions, enum values, defaults, and which inputs feed which report sections. The description adds only the high-level notion that dasha/panchang/gochar sections are optional; it introduces no syntax or format detail the schema lacks.

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 ('assemble ... and write it to disk as JSON') and resource ('structured astrology report draft'), and enumerates the sections it comprises. An agent can distinguish it from sibling generate_pdf_report purely from the text.

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?

Usage is implied ('Assemble a structured astrology report draft'), and the schema hints at ordering by pointing at calculate_kundali/calculate_dasha/calculate_gochar/calculate_panchang outputs. However, it never says when to choose this JSON variant over the sibling generate_pdf_report, nor when to persist via db_path versus writing to disk only.

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

Deploy Server

Other Tools