Asterwise

Vedic Daily Factors

asterwise_get_vedic_daily_factors

Read-onlyIdempotent

Every classical factor for one person on one day, in one shape, with no weighting. Each factor carries its raw value and range, its frame (from the Moon, from the Lagna, a natal planet, none), the verdict its own rule gives or null, the rule's source, signification ids, the time it holds and whether it depends on the birth time.

WORKFLOW: BEFORE: asterwise_get_natal_chart. AFTER: asterwise_get_vedic_events — the same over a range, as a timeline.

INPUT CONTRACT: birth — BirthData. target_date (optional YYYY-MM-DD; defaults to today in the birth timezone). target_time (optional HH:MM; defaults to 12:00) — the local time in target_timezone the day's sky is read. target_timezone (optional IANA; defaults to the birth timezone).

DO NOT CONFUSE WITH: asterwise_get_gochar — the transit section only, with interpretations. asterwise_get_horoscope — AI-written text, not factors.

Full output and error contract: https://docs.asterwise.com/mcp/tools/get-vedic-daily-factors/

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": {
      "birth": "<birth>"
    },
    "name": "asterwise_get_vedic_daily_factors"
  }
}

Input Schema

Name	Required	Description	Default
`birth`	Yes	Birth data for a single person.
`target_date`	No	Day to read, YYYY-MM-DD. Defaults to today in the birth timezone.
`target_time`	No	Local time HH:MM (24-hour) in target_timezone on the day at which the sky is read. Defaults to 12:00. Pass the user's own time so the Moon is where the user sees it.
`response_format`	No	Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.	markdown
`target_timezone`	No	IANA timezone of the day. Defaults to the birth timezone.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026

changedInput schema / properties / target_time / anyOf

Previous value: -[
-  {
-    "pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^([01][0-9]|2[0-3]):[0-5][0-9]$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / target_time / description

Previous value: -"Local time HH:MM (24-hour) on the day at which the sky is read. Defaults to 12:00. Pass the user's own time so the Moon is where the user sees it."New value: +"Local time HH:MM (24-hour) in target_timezone on the day at which the sky is read. Defaults to 12:00. Pass the user's own time so the Moon is where the user sees it."

Changed1 schema field changedOct 27, 2026

addedInput schema / properties / target_time

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Local time HH:MM (24-hour) on the day at which the sky is read. Defaults to 12:00. Pass the user's own time so the Moon is where the user sees it."
+}

AddedOct 12, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds real behavioral content beyond them: results are unweighted raw factors, verdicts may be null, each factor is time-bound and may or may not depend on the birth time, and computation is anchored to a specific local time of day. Error contract is deferred to an external docs URL rather than described, which keeps this from a 5.

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?

Front-loaded with the core statement, then cleanly sectioned into WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE WITH. Slightly redundant since the INPUT CONTRACT largely duplicates schema descriptions already visible to the agent, but every section is labelled and scannable.

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 return values need no explanation, and the description still sketches factor shape usefully. With a prerequisite workflow, default resolution rules, sibling exclusions, and a pointer to the full error contract, an agent has everything needed to call this correctly on the first attempt.

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 baseline is 3. The INPUT CONTRACT restates what the schema already declares (birth required; target_date defaults to today in birth timezone; target_time defaults to 12:00; target_timezone defaults to the birth timezone) without adding meaning beyond it.

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 the resource and its scope precisely: 'every classical factor for one person on one day, in one shape, with no weighting', then enumerates what each factor carries (raw value, range, frame, verdict, source, signification ids, validity period, birth-time dependency). It is explicitly distinguished from the nearest siblings (gochar = transit section only with interpretations; horoscope = AI-written text).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit prerequisite (BEFORE: get_natal_chart), an explicit follow-on (AFTER: get_vedic_events for a range as a timeline), and a 'DO NOT CONFUSE WITH' block naming two alternatives with the reason each differs. Nothing about tool selection is left to inference.

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

All Asterwise tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?