Vedaksha

Overview Schema Source Related Servers Discussions Admin

search_muhurta

Read-only

Find auspicious time windows for a location within a 30-day range, ranked by quality scores from tithi, nakshatra, yoga, karana, and planetary positions.

Instructions

Search for auspicious time windows (muhurta) within a given period for a geographic location. Returns ranked muhurta candidates with quality scores based on tithi, nakshatra, yoga, karana, and planetary positions. The search window is capped at 30 days (see MUHURTA_SEARCH_RANGE_TOO_LARGE), a scope limit; for a longer horizon, issue several searches.

Input Schema

Name	Required	Description
`end_jd`	Yes	End of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The span from start_jd to end_jd must not exceed 30 days.
`latitude`	Yes	Geographic latitude in degrees [-90, +90]
`start_jd`	Yes	Start of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms and uses UT1 directly for sunrise, which each candidate's vara is reckoned from; every returned jd, tithi_end_jd and nakshatra_end_jd is on this same UT1 scale. The span from start_jd to end_jd must not exceed 30 days.
`longitude`	Yes	Geographic longitude in degrees [-180, +180], east positive
`elevation_m`	No	Observer elevation in metres above sea level [-500, 9000] (default 0). Lowers the horizon by the dip and so moves sunrise, which is what each candidate's vara is reckoned from — at 3650 m (Lhasa) 9.2 minutes earlier. Pass the same value as compute_panchanga for the same observer, or the two tools can report different weekdays for one instant.
`min_quality`	No	Minimum quality score [0.0, 1.0] for muhurta inclusion (default 0.5)
`tz_offset_minutes`	No	Offset of the observer's civil clock from UT, in minutes. Names the vara (weekday) reported for each candidate — it does not change which sunrise bounds the vara, only what that vara is called. Default 0 (UT).

Output Schema

Name	Required	Description
`end_jd`	Yes	End of the searched window, echoed back.
`results`	Yes
`latitude`	No	Latitude used, in degrees.
`start_jd`	Yes	Start of the searched window, echoed back.
`longitude`	No	Longitude used, in degrees.
`elevation_m`	No	Elevation used, in metres.
`min_quality`	No	Quality floor the search applied.
`result_count`	Yes	Number of entries in results.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv8.0.0Aug 29, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "elevation_m": {
+      "description": "Elevation used, in metres.",
+      "type": "number"
+    },
+    "end_jd": {
+      "description": "End of the searched window, echoed back.",
+      "type": "number"
+    },
+    "latitude": {
+      "description": "Latitude used, in degrees.",
+      "type": "number"
+    },
+    "longitude": {
+      "description": "Longitude used, in degrees.",
+      "type": "number"
+    },
+    "min_quality": {
+      "description": "Quality floor the search applied.",
+      "type": "number"
+    },
+    "result_count": {
+      "description": "Number of entries in results.",
+      "type": "integer"
+    },
+    "results": {
+      "items": {
+        "properties": {
+          "factors": {
+            "items": {
+              "description": "Named factor contributing to the score.",
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "jd": {
+            "description": "Julian Day of the candidate moment.",
+            "type": "number"
+          },
+          "nakshatra": {
+            "description": "Nakshatra name.",
+            "type": "string"
+          },
+          "nakshatra_end_jd": {
+            "description": "Julian Day at which the nakshatra ends.",
+            "type": "number"
+          },
+          "quality_score": {
+            "description": "Composite score; higher is better.",
+            "type": "number"
+          },
+          "tithi_end_jd": {
+            "description": "Julian Day at which the tithi ends.",
+            "type": "number"
+          },
+          "tithi_name": {
+            "description": "Tithi name.",
+            "type": "string"
+          },
+          "tithi_number": {
+            "description": "Tithi number, 1-30.",
+            "type": "integer"
+          },
+          "weekday": {
+            "description": "Vara at that moment.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "jd",
+          "quality_score",
+          "weekday",
+          "tithi_name",
+          "nakshatra"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "start_jd": {
+      "description": "Start of the searched window, echoed back.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "start_jd",
+    "end_jd",
+    "result_count",
+    "results"
+  ],
+  "type": "object"
+}

First observedv7.0.0Aug 22, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description is free to add operational traits — the ranked-with-scores return shape, the hard 30-day cap, and the named error MUHURTA_SEARCH_RANGE_TOO_LARGE. That error-code disclosure is genuinely useful for an agent to handle failure, though the cost/performance characteristics of a wide search are left implicit.

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?

Three sentences, front-loaded with purpose, then return shape, then the constraint and its remedy. The error code and the 'issue several searches' fallback both earn their place; nothing is padded.

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 need not explain return values in detail, yet it still signals that results are ranked and scored. Combined with the disclosed window cap, its error code, and the multi-search workaround, an agent has everything needed to call this correctly and recover from the range failure.

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 every parameter — including the UT1-vs-TT nuance on start_jd, the tz_offset_minutes vara naming, and the elevation sunrise dip — is already fully documented in structured fields. The description only restates the 30-day span limit on start_jd/end_jd and adds no parameter semantics of its own, so the baseline 3 applies.

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?

States a concrete verb and resource — search for auspicious muhurta windows for a geographic location — and adds what comes back (ranked candidates scored on tithi, nakshatra, yoga, karana, planetary positions). The resource is distinctive enough that no listed sibling (search_transits, compute_panchanga, etc.) could be confused with it, though no sibling is named to confirm the boundary.

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 a clear operating context plus an explicit workaround: the window is capped at 30 days, and for a longer horizon you issue several searches. What is missing is routing guidance against the compute_* siblings — e.g. when to search for a window versus when to use compute_panchanga for a specific instant — which the schema hints at but the description never states.

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

Deploy Server