AstroNest — Vedic Astrology & Ephemeris

Is this a good time? (decision timing)

resolve_timing

Read-only

Use this when the user asks whether now, or a particular date or range, is a good time for a decision such as changing jobs, marrying or investing. It takes tens of seconds. The interpret verdict for domain, voiced by a language model as an answer to a decision question, read at targetDate (or the start of dateRange, or today when neither is sent): the verdict, the running daśā and eventTiming are taken at that day. A malformed or pre-birth date is refused with 400 (invalid_target_date, invalid_date_range). Expect tens of seconds; set a client timeout of at least 90 s. Cost: 7 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample). Voiced by a language model: allow up to 90 seconds. Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career","question":"Should I accept the offer?","targetDate":"2026-11-15"}

Input Schema

Name	Required	Description
`domain`	Yes	Life area the decision is about, e.g. career, marriage, finance or health.
`question`	Yes	The decision question in plain language, e.g. "Is this a good time to change jobs?"
`birthData`	Yes	The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude.
`dateRange`	No	Optional period the decision is about: start and end dates, YYYY-MM-DD. The verdict is read at `start`; `end` must not precede it.
`targetDate`	No	Optional date the decision is about, YYYY-MM-DD. The verdict is read at this day. Takes precedence over `dateRange`.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 15, 2026

changedInput schema / properties / dateRange / description

Previous value: -"Optional period the decision is about: start and end dates, YYYY-MM-DD."New value: +"Optional period the decision is about: start and end dates, YYYY-MM-DD. The verdict is read at `start`; `end` must not precede it."

changedInput schema / properties / targetDate / description

Previous value: -"Optional date the decision is about, YYYY-MM-DD."New value: +"Optional date the decision is about, YYYY-MM-DD. The verdict is read at this day. Takes precedence over `dateRange`."

changedOutput schema / $defs / TimingResponse / allOf

Previous value: -[
-  {
-    "$ref": "#/$defs/ForecastResponse"
-  },
-  {
-    "properties": {
-      "decisionQuestion": {
-        "type": "string"
-      },
-      "exactDateAssessment": {
-        "type": [
-          "string",
-          "null"
-        ]
-      }
-    },
-    "type": "object"
-  }
-]New value: +[
+  {
+    "$ref": "#/$defs/ForecastResponse"
+  },
+  {
+    "properties": {
+      "decisionQuestion": {
+        "type": "string"
+      },
+      "exactDateAssessment": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "referenceDate": {
+        "description": "The day the verdict, the daśā reading and eventTiming are anchored to: `targetDate` when sent, else `dateRange.start`, else the day of the call.",
+        "format": "date",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  }
+]

First observedOct 7, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the readOnly annotations: credit cost (7 per call, sandbox free), latency and a 90 s client timeout, refusal behavior on malformed or pre-birth dates with specific 400 error codes, and what the verdict is read against. This is exactly the operational context annotations don't carry.

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

Conciseness3/5

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

The latency warning is repeated three times ('takes tens of seconds', 'Expect tens of seconds', 'allow up to 90 seconds'), which is redundant. Front-loading is decent but the wall-clock caution should appear once to earn 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?

For a nested-parameter, costly, slow tool with an output schema, the description covers the operational essentials: cost, timeout, error cases, and date precedence. Return-value detail is correctly left to the output schema.

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 coverage is 100% so the baseline is 3, but the description adds real semantics: targetDate takes precedence over dateRange, the verdict is read at dateRange.start, and 'today' is used when neither is sent. That precedence rule is only in the description, not the schema.

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 specific trigger and resource: deciding whether a date/range is auspicious for a decision like jobs, marriage, or investing, and names the parameterized domain/question. It reads clearly but does not explicitly differentiate itself from close siblings like find_muhurta or get_venture_timing, which also concern timing.

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?

Opens with an explicit 'Use this when...' trigger scoped to a user asking about timing for a decision, which is strong context. However, it gives no when-not-to-use guidance or alternatives among the many timing-adjacent siblings, leaving the agent to infer the boundary.

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

All AstroNest — Vedic Astrology & Ephemeris tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.