Astrology Forecast MCP Server by 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

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 consider before filtering by significance. Defaults to all three.
`endDate`	No	Last day of the window in YYYY-MM-DD format. Defaults to startDate plus 30 days. 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 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	Significance floor from 0 to 100 for what counts as a significant date. Defaults to 70.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedAug 25, 2026

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"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."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changed2 schema fields changedAug 17, 2026

addedInput schema / examples

Added value: +[
+  {
+    "birthData": {
+      "date": "1990-07-15",
+      "time": "13:30:00",
+      "timezone": "America/New_York"
+    }
+  }
+]

changedInput schema / properties / compact / description

Previous value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"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."

Changed1 schema field changedJul 22, 2026

changedInput schema / properties / compact / description

Previous value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."

Changed1 schema field changedJul 22, 2026

addedInput schema / properties / compact

Added value: +{
+  "default": false,
+  "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.",
+  "type": "boolean"
+}

Changed3 schema fields changedJul 12, 2026

changedInput schema / properties / birthData / properties / timezone / anyOf

Previous value: -[
-  {
-    "maximum": 14,
-    "minimum": -14,
-    "type": "number"
-  },
-  {
-    "pattern": "^[A-Za-z_]+(?:\\/[A-Za-z0-9_+-]+){0,2}$",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "maximum": 14,
+    "minimum": -14,
+    "type": "number"
+  },
+  {
+    "type": "string"
+  }
+]

changedInput schema / properties / birthData / properties / timezone / description

Previous value: -"Decimal hours (e.g. 5.5 for IST, -5 for EST) OR IANA name (e.g. \"America/New_York\", \"UTC\"). IANA is resolved to the DST-correct offset for the request date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error."

changedInput schema / properties / birthData / properties / timezone / example
```
Previous value: -5.5New value: +"America/New_York"
```

First observedJul 8, 2026

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