Astrology Forecast MCP Server by RoxyAPI

Cross-domain forecast timeline - Transits, ingresses, stations, dasha changes, critical days

post_forecast_timeline

Read-only

Build one time-ordered forecast for a single birth subject by merging upcoming events across three domains: western transit-to-natal aspects, sign ingresses, retrograde stations, eclipses, and new and full moons; biorhythm critical days; and vedic Vimshottari mahadasha, antardasha, and pratyantardasha boundaries. The window is clamped to 90 days and events are capped and scored by significance. Built for what-is-coming dashboards, daily and weekly forecast feeds, and timing tools.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`domains`	No	Which forecast domains to include. Defaults to all three. Pass a subset to scope the timeline to one or two engines.
`endDate`	No	Last day of the forecast window in YYYY-MM-DD format. Defaults to startDate plus 30 days. The window is clamped to a maximum of 90 days from startDate.
`birthData`	Yes	The single birth subject this forecast is built for. One object only, never an array.
`startDate`	No	First day of the forecast window in YYYY-MM-DD format. Defaults to today in UTC.
`domainWeights`	No	Per-domain significance multipliers applied before the significance floor and event cap. Bias which domains survive filtering and the cap. Omitted domains default to a weight of 1. Valid keys are western, vedic, and biorhythm.
`minSignificance`	No	Drop events scoring below this significance threshold from 0 to 100. Defaults to 0, keeping all events.

TDQS

A4.2/5.0

Behavior4/5

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

With readOnlyHint=true and destructiveHint=false already covering the safety profile, the description adds useful context: the window is 'clamped to 90 days' and events are 'capped and scored by significance.' These are meaningful behavioral constraints beyond the annotations.

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?

The description is three sentences with no wasted text: the first defines the core output and domain merge, the second states hard constraints (clamping, capping, significance), and the third names the intended use cases. Every sentence contributes essential 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?

Given no output schema, the description does a good job of conveying the overall behavior, constraints, and intended consumers. However, the exact response shape (e.g., an array of events with date and significance) is only implied by 'time-ordered forecast' and not explicitly stated.

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?

The input schema has 100% description coverage for all parameters, so the baseline is 3. The description only implies the overall merging of domains and scoring behavior, but it does not need to explain individual parameters because the schema already does so thoroughly.

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 opens with 'Build one time-ordered forecast for a single birth subject by merging upcoming events across three domains,' which states a specific verb, resource, and scope. It also names the concrete output (forecast timeline across western, vedic, and biorhythm) and distinguishes it from single-domain siblings like post_forecast_transits.

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 closes with 'Built for what-is-coming dashboards, daily and weekly forecast feeds, and timing tools,' giving clear use cases. It does not explicitly name sibling alternatives or when not to use this tool, but the use context is unambiguous enough.

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

All Astrology Forecast MCP Server by RoxyAPI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation3/5

The solar return tool is clearly distinct from the others, but the remaining forecast tools overlap: timeline and transits both produce time-ordered, significance-scored event feeds, while digest and significant_dates both emphasize the most important upcoming events. The descriptions provide enough detail to separate them, but selection is not always obvious.

Naming Consistency5/5

All tools follow the same post_forecast_<object> pattern with snake_case nouns. The naming is consistent and predictable across the entire server.

Tool Count4/5

Five tools is a reasonable size for an astrology forecast server, and each covers a distinct enough use case. Slightly redundant, however: post_forecast_transits appears to be a narrower western-only subset of post_forecast_timeline.

Completeness4/5

The tool surface covers the core forecasting workflow well: broad timelines, Western-only transits, high-significance dates, digest summaries, and solar returns. Missing is a more flexible custom-range event window beyond 90 days, but the coverage is not severely incomplete.

Resources

Need Help?