astroway-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Generate Muhurta Report (PDF or HTML)

astroway_reports_muhurta

Generate a ranked A4 report of auspicious dates for a chosen activity across your search window, scored by sunrise Panchang and Abhijit Muhurat with rationale.

Instructions

Render a standard A4 report of the most auspicious dates for a chosen activity over a search window. Same window-scan engine as /vedic/muhurat/*: it scores each day by sunrise Panchang (Tithi/Vara/Nakshatra/Yoga/Karana) per Muhurta Chintamani + B.V.Raman, and lists ranked days with per-day Abhijit Muhurat and the scoring factors as the rationale. activity is one of the 12 from /muhurta/types. PDF default; ?format=html returns HTML.

[Group: Reports] [Endpoint: POST /v1/reports/muhurta] [Required: activity, search_window_start, latitude, longitude] [Cost: 5,000 credits (Tier 7)] ⚠️ Premium — ~50% of free monthly budget. Confirm with user before invoking.

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": {
      "activity": "<activity>",
      "search_window_start": "<search_window_start>",
      "latitude": "<latitude>",
      "longitude": "<longitude>"
    },
    "name": "astroway_reports_muhurta"
  }
}

Input Schema

Name	Required	Description
`topN`	No
`format`	No	`pdf` (default) stores a PDF and answers with its `url`. `html` returns one self-contained `text/html` document, `markdown` returns `text/markdown` with the same sections and tables; neither is stored. Same price in every format.
`activity`	Yes
`ayanamsa`	No	Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either.
`language`	No
`latitude`	Yes
`longitude`	Yes
`ayanamsaId`	No
`whitelabel`	No
`timezoneOffset`	No	Hours from UTC at the given moment, not minutes. Fractional zones are hours too: 5.5 for India, 5.75 for Nepal, -3.5 for Newfoundland. Defaults to 0, meaning UTC.
`search_window_end`	No
`search_window_start`	Yes

Output Schema

Name	Required	Description	Default
`url`	No
`expires_at`	No
`page_count`	No
`byte_length`	No
`duration_ms`	No
`storage_key`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.6.1Nov 9, 2026

addedInput schema / properties / format

Added value: +{
+  "description": "`pdf` (default) stores a PDF and answers with its `url`. `html` returns one self-contained `text/html` document, `markdown` returns `text/markdown` with the same sections and tables; neither is stored. Same price in every format.",
+  "enum": [
+    "pdf",
+    "html",
+    "markdown"
+  ],
+  "type": "string"
+}

Addedv1.6.0Oct 24, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare openWorld, non-idempotent, non-read-only, so the description's best additions are the cost/tier warning and the fact that this is a stored PDF artifact rather than a computed response. It explains how days are scored (sunrise Panchang per Muhurta Chintamani + B.V.Raman, ranked with Abhijit Muhurat rationale), which is genuinely informative about output shape. It does not mention window-size limits or failure modes for out-of-range dates.

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 purpose is front-loaded in the first sentence, methodology follows, and no sentence is pure filler. Dense parenthetical jargon (Tithi/Vara/Nakshatra/Yoga/Karana) is justified given the domain, though the endpoint/required/cost metadata block adds bulk.

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?

An output schema exists, so return values need not be explained, and the description is adequate about scoring and format. However, for a 12-parameter premium report tool, silence on timezoneOffset, search window semantics, and whitelabel customization leaves meaningful gaps an agent would hit in practice.

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

Parameters2/5

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

With 12 parameters and only 25% schema coverage, the description needs to carry more weight than it does. It clarifies `activity` (one of 12 from /muhurta/types) and repeats the PDF/HTML format default already documented in the schema, but says nothing about topN, ayanamsa/ayanamsaId, language, timezoneOffset, search_window_end, or the whitelabel branding object.

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

Purpose4/5

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

The description opens with a specific verb and resource: render an A4 report of auspicious dates for a chosen activity over a search window. It also ties itself to the muhurta scoring engine, which distinguishes it from natal/transit/love siblings. It does not name a sibling report or state a boundary explicitly, so it stops short of 5.

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?

There is a real precondition given – it is a premium 5,000-credit call that should be confirmed with the user first – plus a pointer to /muhurta/types for valid activities. But there is no guidance on when to pick this report versus the underlying /vedic/muhurat/* scan endpoints or sibling reports; the agent must infer that from the engine reference.

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

Deploy Server