Astrology Forecast MCP Server by RoxyAPI

by com.roxyapi

Overview Discussions Admin

Server Details

Astrology transit forecasts, timelines and significant-date feeds for AI agents.

Ownership verified

Status: Healthy
Uptime: 100.0% over 41 days
Last Tested: 2026-09-27 15:35
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored 2026-09-20 07:55 across 5 tools

Disambiguation3/5

The tools share a common forecast domain, and three of them (post_forecast_digest, post_forecast_significant_dates, post_forecast_timeline) all return merged cross-domain forecast data with different granularity or filtering. While descriptions differentiate them (windows vs. high-significance only vs. full timeline), an agent could easily misselect when seeking a general forecast summary. Solar return and transits are more distinct.

Naming Consistency5/5

All tools follow a perfectly consistent 'post_forecast_<noun>' pattern. The prefix clearly indicates the action and the noun indicates the output type, making the naming predictable and uniform across the entire set.

Tool Count5/5

Five tools is an ideal size for a focused astrology forecast server. Each tool covers a distinct forecast need (quick digest, significant dates, annual chart, full timeline, transits) without redundancy or bloat, giving the server a lean, purposeful surface.

Completeness4/5

For a forecast-focused server, the coverage is solid: it handles upcoming windows, highlights, annual solar returns, and detailed transit timelines. A minor gap is the lack of a direct natal chart tool or progressed forecast, but these are arguably outside the stated forecast scope and can be worked around via solar return and transits.

Available Tools

5 tools

post_forecast_digestForecast digest - Pre-summarized next 24h, 7d, 30d, and 90d rollupsA

Read-only

Inspect

Roll the cross-domain forecast for a single birth subject into four pre-summarized windows: the next 24 hours, 7 days, 30 days, and 90 days from the start date. Each window returns its event count, a per-domain count breakdown, a per-type count breakdown, and the top highest-significance events. Built for a glanceable what-is-coming strip so a caller can render the upcoming highlights without scanning the full event list.

ParametersJSON Schema

Name	Required	Description	Default
`top`	No	Number of highest-significance events to surface per window. Defaults to 3, capped at 20.
`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 before rolling up the windows. Defaults to all three.
`birthData`	Yes	The single birth subject this digest is built for. One object only, never an array.
`startDate`	No	Start anchor for every window in YYYY-MM-DD format. The next 24h, 7d, 30d, and 90d windows are measured forward from this date at 00:00:00 UTC. 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 before the rollup. Defaults to 0.

Output Schema

ParametersJSON Schema

Name	Required	Description
`endDate`	Yes
`windows`	Yes
`birthData`	Yes
`startDate`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so an agent knows this is a safe read operation. The description adds the behavioral nuance that the result is pre-aggregated into four windows with per-domain and per-type counts, plus top events, which is useful context beyond the safety flags. It does not discuss error cases or rate limits, but for a read-only digest with a rich schema and output schema, the added context is sufficient; no contradiction with 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: the core verb+resource and window structure, then the output contents, then the use case. Each sentence is information-dense, the purpose is front-loaded, and there is no filler or repetition of schema fields. This is an exemplary structure.

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?

Despite having 8 parameters, one required and nested, plus an output schema, the description gives a complete mental model: the single birth subject, the four windows anchored at the start date, the breakdown dimensions, and the intended glanceable use. Since an output schema exists, it need not spell out return values; the description covers the conceptual and usage context needed to invoke it correctly.

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, including nested fields like timezone and domainWeights, has a detailed schema description. The tool description itself only refers to 'top highest-significance events' and the window anchor, which mirrors schema text rather than adding new parameter semantics. Baseline 3 is correct.

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 the specific verb 'Roll' and identifies both the resource ('the cross-domain forecast for a single birth subject') and the exact output ('four pre-summarized windows... event count, per-domain count breakdown, per-type count breakdown, and the top highest-significance events'). It distinguishes the digest from the sibling timeline/transits tools by emphasizing the pre-summarized, glanceable nature. This is a clear, differentiated purpose.

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?

It states the intended use case: 'Built for a glanceable what-is-coming strip so a caller can render the upcoming highlights without scanning the full event list.' This gives clear context for when to select it. It does not, however, explicitly name alternatives or state when not to use it (e.g., 'for the full event list, use post_forecast_timeline'), so it stops short of the explicit when/when-not guidance that would earn a 5.

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

post_forecast_significant_datesSignificant dates - High-significance cross-domain forecast highlightsA

Read-only

Inspect

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.

ParametersJSON 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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`events`	Yes
`endDate`	Yes
`birthData`	Yes
`startDate`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false; the description adds that the tool filters to a significance floor, merges multiple domains, and returns only a single birth subject's dates. It accurately reflects a read-only, non-destructive operation and adds event-category context beyond the schema.

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?

Three sentences, front-loaded with the core purpose, followed by default behavior and target use cases. No filler and no repetition of schema internals beyond the significance floor, which is one meaningful behavioral default.

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 the 8-parameter schema, nested birthData object, and present output schema, the description's high-level summary plus the schema's detailed parameter docs are sufficient for invocation. It could have named the sibling tools explicitly, but the use-case sentence provides enough orientation.

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 schema carries the parameter documentation. The description adds some semantic glue by naming minSignificance's default of 70 and tying 'high-significance' to the event categories, but it does not add per-parameter detail beyond the schema.

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 begins with a concrete verb and object ('Return only the high-significance dates...') and enumerates exactly what event types count (outer-planet exact aspects, sign ingresses, retrograde stations, dasha changes), so an agent knows precisely what the tool produces. The 'Built for...' clause also positions it among the forecast siblings as the highlight/strip view rather than the full timeline or digest.

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?

'Built for what-is-coming highlights, timing alerts, and at-a-glance forecast strips' gives an explicit intended use context, and 'short list' plus the significance floor makes the output shape clear. It does not name sibling alternatives or state when not to use it, but the purpose is distinctive enough that an agent can choose it over digest/timeline/transits.

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

post_forecast_solar_returnSolar return chart - Annual birthday forecast chart for a single subjectA

Read-only

Inspect

Cast the solar return chart for one subject and year: the chart erected for the exact moment the transiting Sun returns to its natal ecliptic longitude, the foundational technique for annual astrological forecasting. Returns the full tropical chart with planetary positions, house cusps, aspects, Ascendant, and Midheaven. Location-sensitive: pass the birthplace to anchor the chart to natal geography, or the current city for a relocated solar return where the houses and Ascendant shift to where you are on your birthday. Built for year-ahead forecast tools, birthday charts, and annual horoscope features.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	Birth date in YYYY-MM-DD format. Anchors the natal Sun longitude the transiting Sun returns to each year.
`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
`time`	Yes	Birth time in 24-hour HH:MM:SS format. Pins the exact natal Sun position that defines the solar return moment.
`year`	Yes	Year to cast the solar return for. The chart is erected for the moment in this year when the transiting Sun returns to the natal Sun longitude, on or within a day of the birthday.
`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.
`latitude`	Yes	Latitude of the solar return location in decimal degrees. The solar return is location-sensitive: use the birthplace to anchor the chart to natal geography, or the current city for a relocated solar return.
`timezone`	Yes	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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error.
`longitude`	Yes	Longitude of the solar return location in decimal degrees. Sets the local sidereal time, so it drives the Ascendant, Midheaven, and house cusps of the return chart.
`houseSystem`	No	House system for the return chart. placidus is the Western default. whole-sign, equal, and koch are also supported.	placidus

Output Schema

ParametersJSON Schema

Name	Required	Description
`chart`	Yes
`location`	Yes
`birthDate`	Yes
`solarReturnDate`	Yes
`solarReturnYear`	Yes
`natalSunPosition`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: reveals location-sensitivity, explains what the return chart includes, and notes that houses/Ascendant shift for relocated returns. Nothing contradicts 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?

Four dense sentences, front-loaded with the core definition. Every sentence adds distinct value: chart definition, output components, location sensitivity, and intended use cases. No redundancy or 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?

Given the tool's moderate complexity and the presence of an output schema (which covers return values), the description covers the essential invocation context: astronomical definition, location sensitivity, and industry use cases. It lacks explicit guidance on how to select this tool over sibling forecast tools, but that is partially addressed by purpose clarity.

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 beyond schema by tying latitude/longitude to the 'relocated vs. natal' concept and by explaining how date/time determine the Sun return moment, adding conceptual meaning not explicitly in the property descriptions.

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?

Description uses a specific verb ('Cast') and resource ('solar return chart for one subject and year'), and precisely defines the chart's astronomical basis (moment transiting Sun returns to natal longitude). It clearly differentiates this tool from siblings like post_forecast_transits or post_forecast_timeline by naming the annual birthday chart technique and its output components.

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 gives clear use contexts ('Built for year-ahead forecast tools, birthday charts, and annual horoscope features') and operational guidance about choosing birthplace vs. current city for relocated returns. It does not explicitly contrast with sibling tools by name or state when not to use this tool, so it stops short of a full 5.

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

post_forecast_timelineCross-domain forecast timeline - Transits, ingresses, stations, dasha changes, critical daysA

Read-only

Inspect

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.

ParametersJSON 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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`events`	Yes
`endDate`	Yes
`birthData`	Yes
`startDate`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral constraints beyond the schema: the window is clamped to 90 days, events are capped and scored by significance, and the tool merges events across domains into one timeline. It does not detail the exact cap or scoring formula, but the schema's minSignificance/domainWeights parameters already hint at that mechanism.

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?

Three sentences with no filler. The first sentence states the core action and scope, the second adds the key constraints (90-day clamp, cap, scoring), and the third names the target use cases. Every sentence earns its place and the most important information is front-loaded.

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?

The tool has a rich output schema (not shown but present), 100% schema coverage, and read-only annotations, so the description does not need to explain return values or safety. It covers the merging behavior, window clamp, event cap/scoring, and intended use cases. A minor gap is not explicitly stating that domains defaults to all three, but the schema already documents that default.

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 schema already documents all 8 parameters thoroughly. The description adds the high-level merging and clamping behavior but does not add per-parameter meaning beyond what the schema provides. Baseline 3 is appropriate when the schema carries the full parameter documentation burden.

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 a specific verb ('Build') and a precise resource ('one time-ordered forecast for a single birth subject'), then enumerates the three merged domains (western transits/ingresses/stations/eclipses/lunations, biorhythm critical days, vedic dasha boundaries). This clearly distinguishes it from sibling forecast tools like post_forecast_transits (single-domain) or post_forecast_digest (likely a summary), and the title reinforces the cross-domain scope.

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 states the intended use cases ('Built for what-is-coming dashboards, daily and weekly forecast feeds, and timing tools') and the domain-merging behavior, which implies when to choose this over single-domain siblings. It does not explicitly name alternatives or say 'use post_forecast_transits for western-only', but the cross-domain framing plus sibling names gives an agent enough context to route correctly.

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

post_forecast_transitsWestern astrology forecast - aspects, ingresses, stations, eclipses, moon phasesA

Read-only

Inspect

Forecast the western astrology events for a single birth chart over a window up to 90 days: every transit-to-natal major aspect refined to its exact instant, every transiting planet sign ingress, every retrograde or direct station, every solar and lunar eclipse, and every New and Full Moon. Returns a time-ordered, significance-scored timeline. Built for astrology forecast feeds, transit alerts, and timing tools.

ParametersJSON 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.
`endDate`	No	Last day of the transit 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 transit forecast is built for. One object only, never an array.
`startDate`	No	First day of the transit window in YYYY-MM-DD format. Defaults to today in UTC.
`minSignificance`	No	Drop transit events scoring below this significance threshold from 0 to 100. Defaults to 0.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`events`	Yes
`endDate`	Yes
`birthData`	Yes
`startDate`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds behavioral detail: the window limit 'up to 90 days', events 'refined to its exact instant', and the return shape 'time-ordered, significance-scored timeline'. No contradiction with 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?

Three sentences, each earning its place: scope/event list, output shape, and use cases. Front-loaded with the core action and resource, with no redundant phrasing.

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?

With a full output schema present and 100% schema parameter coverage, the description covers the remaining contextual essentials: single chart, up-to-90-day window, event taxonomy, and timeline ordering. Nothing an agent needs to invoke it correctly is missing.

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 input schema already documents all 6 parameters in detail. The description adds only general context (single chart, 90-day window), not parameter-specific meaning, which is consistent with the baseline of 3.

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 uses a specific verb ('Forecast') and resource ('western astrology events for a single birth chart over a window up to 90 days'), then enumerates the event types (transit-to-natal aspects, ingresses, stations, eclipses, New/Full Moons). This level of detail clearly differentiates it from sibling tools like post_forecast_timeline or post_forecast_solar_return.

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 final sentence states the intended use cases: 'Built for astrology forecast feeds, transit alerts, and timing tools.' That provides clear context for when to choose this tool, though it does not explicitly name alternatives or state when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesSep 20, 2026

Changedpost_forecast_digest1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "birthData": {
+      "properties": {
+        "date": {
+          "format": "date",
+          "type": "string"
+        },
+        "latitude": {
+          "default": 0,
+          "maximum": 90,
+          "minimum": -90,
+          "type": "number"
+        },
+        "longitude": {
+          "default": 0,
+          "maximum": 180,
+          "minimum": -180,
+          "type": "number"
+        },
+        "time": {
+          "format": "time",
+          "type": "string"
+        },
+        "timezone": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "date",
+        "time",
+        "timezone"
+      ],
+      "type": "object"
+    },
+    "endDate": {
+      "type": "string"
+    },
+    "startDate": {
+      "type": "string"
+    },
+    "windows": {
+      "items": {
+        "properties": {
+          "byDomain": {
+            "properties": {
+              "biorhythm": {
+                "type": "number"
+              },
+              "vedic": {
+                "type": "number"
+              },
+              "western": {
+                "type": "number"
+              }
+            },
+            "type": "object"
+          },
+          "byType": {
+            "properties": {
+              "critical-day": {
+                "type": "number"
+              },
+              "dasha-change": {
+                "type": "number"
+              },
+              "eclipse": {
+                "type": "number"
+              },
+              "lunar-phase": {
+                "type": "number"
+              },
+              "retrograde-station": {
+                "type": "number"
+              },
+              "sign-ingress": {
+                "type": "number"
+              },
+              "transit-aspect": {
+                "type": "number"
+              }
+            },
+            "type": "object"
+          },
+          "count": {
+            "type": "number"
+          },
+          "days": {
+            "type": "number"
+          },
+          "from": {
+            "type": "string"
+          },
+          "to": {
+            "type": "string"
+          },
+          "top": {
+            "items": {
+              "properties": {
+                "aspect": {
+                  "type": "string"
+                },
+                "body": {
+                  "type": "string"
+                },
+                "date": {
+                  "type": "string"
+                },
+                "datetime": {
+                  "type": "string"
+                },
+                "description": {
+                  "type": "string"
+                },
+                "domain": {
+                  "enum": [
+                    "western",
+                    "vedic",
+                    "biorhythm"
+                  ],
+                  "type": "string"
+                },
+                "kind": {
+                  "enum": [
+                    "penumbral",
+                    "partial",
+                    "annular",
+                    "total"
+                  ],
+                  "type": "string"
+                },
+                "obscuration": {
+                  "type": "number"
+                },
+                "orb": {
+                  "type": "number"
+                },
+                "phase": {
+                  "enum": [
+                    "new-moon",
+                    "full-moon"
+                  ],
+                  "type": "string"
+                },
+                "significance": {
+                  "type": "number"
+                },
+                "station": {
+                  "enum": [
+                    "retrograde",
+                    "direct"
+                  ],
+                  "type": "string"
+                },
+                "target": {
+                  "type": "string"
+                },
+                "type": {
+                  "enum": [
+                    "transit-aspect",
+                    "sign-ingress",
+                    "retrograde-station",
+                    "eclipse",
+                    "lunar-phase",
+                    "dasha-change",
+                    "critical-day"
+                  ],
+                  "type": "string"
+                }
+              },
+              "required": [
+                "date",
+                "datetime",
+                "domain",
+                "type",
+                "body",
+                "description",
+                "significance"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "days",
+          "from",
+          "to",
+          "count",
+          "byDomain",
+          "byType",
+          "top"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "birthData",
+    "startDate",
+    "endDate",
+    "windows"
+  ],
+  "type": "object"
+}

Changedpost_forecast_significant_dates1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "birthData": {
+      "properties": {
+        "date": {
+          "format": "date",
+          "type": "string"
+        },
+        "latitude": {
+          "default": 0,
+          "maximum": 90,
+          "minimum": -90,
+          "type": "number"
+        },
+        "longitude": {
+          "default": 0,
+          "maximum": 180,
+          "minimum": -180,
+          "type": "number"
+        },
+        "time": {
+          "format": "time",
+          "type": "string"
+        },
+        "timezone": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "date",
+        "time",
+        "timezone"
+      ],
+      "type": "object"
+    },
+    "count": {
+      "type": "number"
+    },
+    "endDate": {
+      "type": "string"
+    },
+    "events": {
+      "items": {
+        "properties": {
+          "aspect": {
+            "type": "string"
+          },
+          "body": {
+            "type": "string"
+          },
+          "date": {
+            "type": "string"
+          },
+          "datetime": {
+            "type": "string"
+          },
+          "description": {
+            "type": "string"
+          },
+          "domain": {
+            "enum": [
+              "western",
+              "vedic",
+              "biorhythm"
+            ],
+            "type": "string"
+          },
+          "kind": {
+            "enum": [
+              "penumbral",
+              "partial",
+              "annular",
+              "total"
+            ],
+            "type": "string"
+          },
+          "obscuration": {
+            "type": "number"
+          },
+          "orb": {
+            "type": "number"
+          },
+          "phase": {
+            "enum": [
+              "new-moon",
+              "full-moon"
+            ],
+            "type": "string"
+          },
+          "significance": {
+            "type": "number"
+          },
+          "station": {
+            "enum": [
+              "retrograde",
+              "direct"
+            ],
+            "type": "string"
+          },
+          "target": {
+            "type": "string"
+          },
+          "type": {
+            "enum": [
+              "transit-aspect",
+              "sign-ingress",
+              "retrograde-station",
+              "eclipse",
+              "lunar-phase",
+              "dasha-change",
+              "critical-day"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "date",
+          "datetime",
+          "domain",
+          "type",
+          "body",
+          "description",
+          "significance"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "startDate": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "birthData",
+    "startDate",
+    "endDate",
+    "count",
+    "events"
+  ],
+  "type": "object"
+}

Changedpost_forecast_solar_return1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "birthDate": {
+      "type": "string"
+    },
+    "chart": {
+      "properties": {
+        "aspects": {
+          "items": {
+            "properties": {
+              "angle": {
+                "type": "number"
+              },
+              "interpretation": {
+                "enum": [
+                  "harmonious",
+                  "challenging",
+                  "neutral"
+                ],
+                "type": "string"
+              },
+              "isApplying": {
+                "type": "boolean"
+              },
+              "orb": {
+                "type": "number"
+              },
+              "planet1": {
+                "enum": [
+                  "Sun",
+                  "Moon",
+                  "Mercury",
+                  "Venus",
+                  "Mars",
+                  "Jupiter",
+                  "Saturn",
+                  "Uranus",
+                  "Neptune",
+                  "Pluto",
+                  "North Node",
+                  "South Node",
+                  "Chiron",
+                  "Black Moon Lilith"
+                ],
+                "type": "string"
+              },
+              "planet2": {
+                "enum": [
+                  "Sun",
+                  "Moon",
+                  "Mercury",
+                  "Venus",
+                  "Mars",
+                  "Jupiter",
+                  "Saturn",
+                  "Uranus",
+                  "Neptune",
+                  "Pluto",
+                  "North Node",
+                  "South Node",
+                  "Chiron",
+                  "Black Moon Lilith"
+                ],
+                "type": "string"
+              },
+              "strength": {
+                "maximum": 100,
+                "minimum": 0,
+                "type": "number"
+              },
+              "type": {
+                "enum": [
+                  "CONJUNCTION",
+                  "OPPOSITION",
+                  "TRINE",
+                  "SQUARE",
+                  "SEXTILE",
+                  "SEMI_SEXTILE",
+                  "QUINCUNX",
+                  "SEMI_SQUARE",
+                  "SESQUIQUADRATE"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "planet1",
+              "planet2",
+              "type",
+              "angle",
+              "orb",
+              "isApplying",
+              "strength",
+              "interpretation"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "birthDetails": {
+          "properties": {
+            "date": {
+              "format": "date",
+              "type": "string"
+            },
+            "latitude": {
+              "maximum": 90,
+              "minimum": -90,
+              "type": "number"
+            },
+            "longitude": {
+              "maximum": 180,
+              "minimum": -180,
+              "type": "number"
+            },
+            "time": {
+              "format": "time",
+              "type": "string"
+            },
+            "timezone": {
+              "maximum": 14,
+              "minimum": -12,
+              "type": "number"
+            }
+          },
+          "required": [
+            "date",
+            "time",
+            "latitude",
+            "longitude",
+            "timezone"
+          ],
+          "type": "object"
+        },
+        "houseSystem": {
+          "enum": [
+            "placidus",
+            "whole-sign",
+            "equal",
+            "koch"
+          ],
+          "type": "string"
+        },
+        "houses": {
+          "items": {
+            "properties": {
+              "degree": {
+                "maximum": 30,
+                "minimum": 0,
+                "type": "number"
+              },
+              "longitude": {
+                "maximum": 360,
+                "minimum": 0,
+                "type": "number"
+              },
+              "number": {
+                "maximum": 12,
+                "minimum": 1,
+                "type": "integer"
+              },
+              "sign": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "number",
+              "longitude",
+              "sign",
+              "degree"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "partOfFortune": {
+          "properties": {
+            "degree": {
+              "maximum": 30,
+              "minimum": 0,
+              "type": "number"
+            },
+            "house": {
+              "maximum": 12,
+              "minimum": 1,
+              "type": "integer"
+            },
+            "longitude": {
+              "maximum": 360,
+              "minimum": 0,
+              "type": "number"
+            },
+            "sect": {
+              "enum": [
+                "day",
+                "night"
+              ],
+              "type": "string"
+            },
+            "sign": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "sign",
+            "degree",
+            "longitude",
+            "house",
+            "sect"
+          ],
+          "type": "object"
+        },
+        "planets": {
+          "items": {
+            "properties": {
+              "degree": {
+                "maximum": 30,
+                "minimum": 0,
+                "type": "number"
+              },
+              "house": {
+                "maximum": 12,
+                "minimum": 1,
+                "type": "integer"
+              },
+              "isRetrograde": {
+                "type": "boolean"
+              },
+              "latitude": {
+                "type": "number"
+              },
+              "longitude": {
+                "maximum": 360,
+                "minimum": 0,
+                "type": "number"
+              },
+              "name": {
+                "enum": [
+                  "Sun",
+                  "Moon",
+                  "Mercury",
+                  "Venus",
+                  "Mars",
+                  "Jupiter",
+                  "Saturn",
+                  "Uranus",
+                  "Neptune",
+                  "Pluto",
+                  "North Node",
+                  "South Node",
+                  "Chiron",
+                  "Black Moon Lilith"
+                ],
+                "type": "string"
+              },
+              "sign": {
+                "type": "string"
+              },
+              "speed": {
+                "type": "number"
+              }
+            },
+            "required": [
+              "name",
+              "longitude",
+              "latitude",
+              "sign",
+              "degree",
+              "house",
+              "speed",
+              "isRetrograde"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "vertex": {
+          "properties": {
+            "degree": {
+              "maximum": 30,
+              "minimum": 0,
+              "type": "number"
+            },
+            "house": {
+              "maximum": 12,
+              "minimum": 1,
+              "type": "integer"
+            },
+            "longitude": {
+              "maximum": 360,
+              "minimum": 0,
+              "type": "number"
+            },
+            "sign": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "sign",
+            "degree",
+            "longitude",
+            "house"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "birthDetails",
+        "planets",
+        "houses",
+        "houseSystem",
+        "aspects",
+        "partOfFortune",
+        "vertex"
+      ],
+      "type": "object"
+    },
+    "location": {
+      "properties": {
+        "latitude": {
+          "type": "number"
+        },
+        "longitude": {
+          "type": "number"
+        },
+        "timezone": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "latitude",
+        "longitude",
+        "timezone"
+      ],
+      "type": "object"
+    },
+    "natalSunPosition": {
+      "properties": {
+        "degree": {
+          "type": "number"
+        },
+        "longitude": {
+          "type": "number"
+        },
+        "sign": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "longitude",
+        "sign",
+        "degree"
+      ],
+      "type": "object"
+    },
+    "solarReturnDate": {
+      "type": "string"
+    },
+    "solarReturnYear": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "birthDate",
+    "solarReturnDate",
+    "solarReturnYear",
+    "location",
+    "natalSunPosition",
+    "chart"
+  ],
+  "type": "object"
+}

Changedpost_forecast_timeline1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "birthData": {
+      "properties": {
+        "date": {
+          "format": "date",
+          "type": "string"
+        },
+        "latitude": {
+          "default": 0,
+          "maximum": 90,
+          "minimum": -90,
+          "type": "number"
+        },
+        "longitude": {
+          "default": 0,
+          "maximum": 180,
+          "minimum": -180,
+          "type": "number"
+        },
+        "time": {
+          "format": "time",
+          "type": "string"
+        },
+        "timezone": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "date",
+        "time",
+        "timezone"
+      ],
+      "type": "object"
+    },
+    "count": {
+      "type": "number"
+    },
+    "endDate": {
+      "type": "string"
+    },
+    "events": {
+      "items": {
+        "properties": {
+          "aspect": {
+            "type": "string"
+          },
+          "body": {
+            "type": "string"
+          },
+          "date": {
+            "type": "string"
+          },
+          "datetime": {
+            "type": "string"
+          },
+          "description": {
+            "type": "string"
+          },
+          "domain": {
+            "enum": [
+              "western",
+              "vedic",
+              "biorhythm"
+            ],
+            "type": "string"
+          },
+          "kind": {
+            "enum": [
+              "penumbral",
+              "partial",
+              "annular",
+              "total"
+            ],
+            "type": "string"
+          },
+          "obscuration": {
+            "type": "number"
+          },
+          "orb": {
+            "type": "number"
+          },
+          "phase": {
+            "enum": [
+              "new-moon",
+              "full-moon"
+            ],
+            "type": "string"
+          },
+          "significance": {
+            "type": "number"
+          },
+          "station": {
+            "enum": [
+              "retrograde",
+              "direct"
+            ],
+            "type": "string"
+          },
+          "target": {
+            "type": "string"
+          },
+          "type": {
+            "enum": [
+              "transit-aspect",
+              "sign-ingress",
+              "retrograde-station",
+              "eclipse",
+              "lunar-phase",
+              "dasha-change",
+              "critical-day"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "date",
+          "datetime",
+          "domain",
+          "type",
+          "body",
+          "description",
+          "significance"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "startDate": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "birthData",
+    "startDate",
+    "endDate",
+    "count",
+    "events"
+  ],
+  "type": "object"
+}

Changedpost_forecast_transits1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "birthData": {
+      "properties": {
+        "date": {
+          "format": "date",
+          "type": "string"
+        },
+        "latitude": {
+          "default": 0,
+          "maximum": 90,
+          "minimum": -90,
+          "type": "number"
+        },
+        "longitude": {
+          "default": 0,
+          "maximum": 180,
+          "minimum": -180,
+          "type": "number"
+        },
+        "time": {
+          "format": "time",
+          "type": "string"
+        },
+        "timezone": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "date",
+        "time",
+        "timezone"
+      ],
+      "type": "object"
+    },
+    "count": {
+      "type": "number"
+    },
+    "endDate": {
+      "type": "string"
+    },
+    "events": {
+      "items": {
+        "properties": {
+          "aspect": {
+            "type": "string"
+          },
+          "body": {
+            "type": "string"
+          },
+          "date": {
+            "type": "string"
+          },
+          "datetime": {
+            "type": "string"
+          },
+          "description": {
+            "type": "string"
+          },
+          "domain": {
+            "enum": [
+              "western",
+              "vedic",
+              "biorhythm"
+            ],
+            "type": "string"
+          },
+          "kind": {
+            "enum": [
+              "penumbral",
+              "partial",
+              "annular",
+              "total"
+            ],
+            "type": "string"
+          },
+          "obscuration": {
+            "type": "number"
+          },
+          "orb": {
+            "type": "number"
+          },
+          "phase": {
+            "enum": [
+              "new-moon",
+              "full-moon"
+            ],
+            "type": "string"
+          },
+          "significance": {
+            "type": "number"
+          },
+          "station": {
+            "enum": [
+              "retrograde",
+              "direct"
+            ],
+            "type": "string"
+          },
+          "target": {
+            "type": "string"
+          },
+          "type": {
+            "enum": [
+              "transit-aspect",
+              "sign-ingress",
+              "retrograde-station",
+              "eclipse",
+              "lunar-phase",
+              "dasha-change",
+              "critical-day"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "date",
+          "datetime",
+          "domain",
+          "type",
+          "body",
+          "description",
+          "significance"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "startDate": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "birthData",
+    "startDate",
+    "endDate",
+    "count",
+    "events"
+  ],
+  "type": "object"
+}

5 tool updatesSep 16, 2026

Changedpost_forecast_digest1 field changed

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

Previous 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."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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."

Changedpost_forecast_significant_dates1 field changed

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

Previous 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."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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."

Changedpost_forecast_solar_return1 field changed

changedInput schema / properties / timezone / description

Previous 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."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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."

Changedpost_forecast_timeline1 field changed

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

Previous 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."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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."

Changedpost_forecast_transits1 field changed

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

Previous 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."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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."

5 tool updatesAug 25, 2026

Changedpost_forecast_digest2 fields changed

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"
+]

Changedpost_forecast_significant_dates2 fields changed

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"
+]

Changedpost_forecast_solar_return2 fields changed

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"
+]

Changedpost_forecast_timeline2 fields changed

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"
+]

Changedpost_forecast_transits2 fields changed

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"
+]

5 tool updatesAug 17, 2026

Changedpost_forecast_digest2 fields changed

addedInput schema / examples

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