ERUX Astrology & Ephemeris Engine

get_horoscope

Read-only

Generate a personalized transit horoscope, real-world strategic forecast, and exact astronomical time-windows for a user based on their natal placements and active planetary transits. Corresponds to /horoscope and /daily commands. Supports cadences: 'daily' (today's transits and hourly Horas), 'weekly' (7-day Monday–Sunday transit arc), 'monthly' (30-day sign ingresses & lunations), and 'yearly' (12-month Solar Return to Solar Return Varshaphala journey). MANDATORY PARAMETERS: The user's natal birth date ('birth_date', YYYY-MM-DD) and natal birth city ('birth_city') are strictly required. NEVER pass today's date into 'birth_date' — today's transit date is calculated automatically by the server based on location coordinates. If the user asks for a future or target date (e.g. next week or 2027), pass that date into 'target_date', NOT 'birth_date'. Optionally accepts 'current_city' if the user has relocated, 'cadence' ('daily', 'weekly', 'monthly', 'yearly'), and 'user_prompt' containing the user's raw inquiry. For daily cadence, returns 'astronomical_time_windows' (exact topocentric sunrise/sunset, 24 planetary Horas, Rahu Kaal, Abhijit Muhurta, Brahma Muhurta) and 'panchang_timing' (exact Nakshatra and Tithi transitions). CRITICAL FOR AI: When suggesting times of day, you MUST quote the exact astronomical_time_windows provided. Never invent arbitrary hours.

Input Schema

Name	Required	Description	Default
`city`	No	Alias for natal birth city
`date`	No	Alias for natal birth date (YYYY-MM-DD)
`time`	No	Alias for natal birth time (HH:MM)
`cadence`	No	Forecast time window: 'daily' (Horas & Panchang), 'weekly' (7-day), 'monthly' (30-day), or 'yearly' (Varshaphala)	daily
`country`	No	Country of birth or current location
`birth_city`	No	REQUIRED: User's natal birth city (e.g. 'London', 'Austin', 'Mumbai').
`birth_date`	No	REQUIRED: User's natal birth date (YYYY-MM-DD, e.g. '1990-07-12'). Do NOT pass today's date here.
`birth_time`	No	Natal birth time in 24-hour HH:MM format (default '12:00' if unknown)	12:00
`target_city`	No	Alias for current relocated city
`target_date`	No	Target forecast date in YYYY-MM-DD format (must be today or future date)
`user_prompt`	No	User's original inquiry for intent grounding and conversational context
`current_city`	No	Current relocated city for topocentric horizon and local Horas (e.g. 'London')
`birth_country`	No	Natal country to disambiguate birth city
`include_image`	No	Set to true to render and attach a dynamic chart wheel PNG image buffer in MCP outputs (default false)
`current_country`	No	Current relocated country

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedOct 11, 2026

addedInput schema / properties / birth_city / description

Added value: +"REQUIRED: User's natal birth city (e.g. 'London', 'Austin', 'Mumbai')."

addedInput schema / properties / birth_country / description
```
Added value: +"Natal country to disambiguate birth city"
```

addedInput schema / properties / birth_date / description

Added value: +"REQUIRED: User's natal birth date (YYYY-MM-DD, e.g. '1990-07-12'). Do NOT pass today's date here."

addedInput schema / properties / birth_time / description

Added value: +"Natal birth time in 24-hour HH:MM format (default '12:00' if unknown)"

addedInput schema / properties / cadence / description

Added value: +"Forecast time window: 'daily' (Horas & Panchang), 'weekly' (7-day), 'monthly' (30-day), or 'yearly' (Varshaphala)"

addedInput schema / properties / city / description
```
Added value: +"Alias for natal birth city"
```

addedInput schema / properties / country / description

Added value: +"Country of birth or current location"

addedInput schema / properties / current_city / description

Added value: +"Current relocated city for topocentric horizon and local Horas (e.g. 'London')"

addedInput schema / properties / current_country / description
```
Added value: +"Current relocated country"
```

addedInput schema / properties / date / description

Added value: +"Alias for natal birth date (YYYY-MM-DD)"

addedInput schema / properties / include_image

Added value: +{
+  "default": false,
+  "description": "Set to true to render and attach a dynamic chart wheel PNG image buffer in MCP outputs (default false)",
+  "title": "Include Image",
+  "type": "boolean"
+}

addedInput schema / properties / target_city / description
```
Added value: +"Alias for current relocated city"
```

addedInput schema / properties / target_date / description

Added value: +"Target forecast date in YYYY-MM-DD format (must be today or future date)"

addedInput schema / properties / time / description

Added value: +"Alias for natal birth time (HH:MM)"

addedInput schema / properties / user_prompt / description

Added value: +"User's original inquiry for intent grounding and conversational context"

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "get_horoscopeOutput",
-  "type": "object"
-}New value: +null

First observedOct 4, 2026

TDQS

A4/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, destructiveHint=false, openWorldHint=true), and the description adds genuinely new behavior: the server auto-computes today's transit date from location coordinates, and the daily cadence returns 'astronomical_time_windows' and 'panchang_timing'. It does not disclose auth, rate limits, or cost.

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 purpose, then mandatory params, then cadence specifics — a sensible ordering. It is long and repeats the birth_date warning that already appears in the schema, but nearly every sentence carries operational information.

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 15-parameter tool with no output schema, the description covers the critical invocation path, the returned payload for daily cadence, and the anti-hallucination constraint on times. The alias parameters are only explained in the schema, which is acceptable given 100% schema coverage but leaves the description slightly short of fully self-contained.

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; the description goes further by disambiguating the two easily-confused date parameters and the birth-city vs current-city distinction, which is the highest-risk invocation error here. It omits any mention of the alias parameters (city/date/time/target_city) or include_image.

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 verb and resource ('Generate a personalized transit horoscope, real-world strategic forecast, and exact astronomical time-windows') and enumerates the cadence variants, so an agent knows exactly what the tool produces. It does not, however, differentiate itself from siblings such as ask_astrology_guidance or calculate_chart, leaving overlap for an agent to resolve.

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 clear conditional routing for cadence ('daily' vs 'weekly' vs 'monthly' vs 'yearly') and an explicit rule for the date trap: pass a future date into 'target_date', not 'birth_date'. It stops short of naming alternative sibling tools or when NOT to use this one.

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

All ERUX Astrology & Ephemeris Engine 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.

get_horoscope

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources