Skip to main content
Glama
arthiqlabs

Vedaksha

by arthiqlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Hybrid

search_muhurta

Read-only

Find auspicious muhurta windows within a 30-day period for any location, ranked by quality scores based on 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) — the per-candidate vara and tithi/nakshatra refinement make this tool far more expensive per day of range than a transit search, so a wider span would make a single call take minutes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_jdYesEnd 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.
latitudeYesGeographic latitude in degrees [-90, +90]
start_jdYesStart 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.
longitudeYesGeographic longitude in degrees [-180, +180], east positive
elevation_mNoObserver 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_qualityNoMinimum quality score [0.0, 1.0] for muhurta inclusion (default 0.5)
tz_offset_minutesNoOffset 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

TableJSON Schema
NameRequiredDescriptionDefault
end_jdYesEnd of the searched window, echoed back.
resultsYes
latitudeNoLatitude used, in degrees.
start_jdYesStart of the searched window, echoed back.
longitudeNoLongitude used, in degrees.
elevation_mNoElevation used, in metres.
min_qualityNoQuality floor the search applied.
result_countYesNumber of entries in results.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv8.0.0
    • 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"
+}
  2. First observedv7.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses significant behavioral traits: the computational cost and why the range is capped, the internal refinement steps (per-candidate vara and tithi/nakshatra refinement), and the existence of a specific error code (MUHURTA_SEARCH_RANGE_TOO_LARGE). It also mentions time-scale consistency (UT1 vs TT) and cross-tool consistency expectations (elevation value matching compute_panchanga) in the schema. This is rich behavioral context that helps agents anticipate performance and failure modes.

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 with no wasted words. The first sentence front-loads purpose and output; the second delivers the critical constraint and cost warning. Every part earns its place, and the error code reference is compact.

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 7-parameter tool with a full output schema and read-only annotations, the description covers the essential usage context: what it searches, what it returns, and the key operational constraint (30-day cap, cost). The schema covers parameter details. It falls slightly short of 5 because it never explicitly positions the tool against siblings like search_transits or compute_panchanga beyond the generic 'transit search' cost comparison, and an agent might still be unsure about selection criteria among these similar astronomical tools.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining why the start_jd/end_jd span is capped at 30 days and the cost implications of the per-candidate refinement. This rationale is genuinely useful for parameter understanding and invocation, lifting the score above baseline. However, individual parameter meanings are almost entirely left to the schema, which is already thorough.

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 ('Search') and resource ('auspicious time windows (muhurta)') with explicit context: within a period for a geographic location. It also lists what the tool returns (ranked candidates with quality scores based on tithi, nakshatra, yoga, karana, and planetary positions). It further distinguishes itself from 'a transit search' by cost, which both identifies the sibling category and clarifies its unique role.

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 gives clear context for when to use the tool (searching muhurta windows) and provides a strong cost-based constraint: the 30-day cap and the warning that wider spans make calls take minutes. It implicitly differentiates from the sibling search_transits by calling out the per-day expense relative to a transit search, but it does not explicitly say 'use this for muhurta, use search_transits for transit positions' or name alternatives such as compute_panchanga.

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