Skip to main content
Glama

Astrology Forecast MCP Server by RoxyAPI

by com.roxyapi

Significant dates - High-significance cross-domain forecast highlights

post_forecast_significant_dates
Read-only

Return only the high-significance dates from the merged cross-domain forecast for a single birth subject: the rare outer-planet exact transit aspects, slow-planet sign ingresses, retrograde stations, and Vimshottari mahadasha and antardasha changes that mark genuine turning points. Defaults to a significance floor of 70 so the response is a short list of the most meaningful upcoming dates. Built for what-is-coming highlights, timing alerts, and at-a-glance forecast strips.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoResponse 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
compactNoSet 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.
domainsNoWhich forecast domains to consider before filtering by significance. Defaults to all three.
endDateNoLast day of the window in YYYY-MM-DD format. Defaults to startDate plus 30 days. Clamped to a maximum of 90 days from startDate.
birthDataYesThe single birth subject this forecast is built for. One object only, never an array.
startDateNoFirst day of the window in YYYY-MM-DD format. Defaults to today in UTC.
domainWeightsNoPer-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.
minSignificanceNoSignificance floor from 0 to 100 for what counts as a significant date. Defaults to 70.

TDQS

A4/5.0
Behavior4/5

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

The annotations already mark the tool as read-only, and the description adds useful behavioral context: it is a filtered, merged-domain view, with a significance floor of 70 and a deliberately short output. It does not describe the full response item shape, but this is a minor gap given the read-only safety profile and schema coverage.

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 compact and front-loaded; the first sentence gives the core behavior and scope, the second sets expectations about output length, and the last mentions the intended use cases. Every sentence carries content without filler.

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 an 8-parameter tool with a nested required object, the description gives enough high-level context to select and call it correctly, especially because the schema documents each parameter thoroughly and annotations mark it read-only. It could be more complete by describing the output item shape or ordering, since no output schema is provided.

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% and every parameter already has a detailed description. The tool description only restates the minSignificance default, so it adds little parameter-level meaning beyond 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?

The description states a specific verb and resource: 'Return only the high-significance dates from the merged cross-domain forecast' and enumerates the event classes included. It is clear enough to distinguish the tool's focus, though it does not explicitly contrast it with the sibling forecast tools.

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 provides clear intended use cases: 'what-is-coming highlights, timing alerts, and at-a-glance forecast strips' and explains that the significance floor yields a short result list. It implies when this tool is appropriate but does not name exclusions or direct agents toward alternatives.

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 toolsInspect
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